superconductor
Skill451 starsChanged 7 months agoMITView on GitHub
Operates the super.engineering/Superconductor `sc` CLI for app-managed agents, teams, sessions, layouts, worktrees, and review threads. Use when a workflow explicitly calls for SC orchestration or app-managed UI/session behavior.
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 9 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 9
Use live sc instructions and capability output as authoritative.
- Distinctive: line 13
Use SC only for the requested orchestration or app-managed outcome.
- Distinctive: line 15
Never create a worktree merely for delegation or launch replacement agents for follow-ups.
- Very specific: line 16
Prefer stable labels or stable target IDs and --active keep.
- Distinctive: line 21
Before the first mutation, run the matching guide:
- Distinctive: line 40
Verify the launch shape, provider, UI mode, model, reasoning level, and structured-read support before specifying them.
- Distinctive: line 42
Read references/orchestration.md before launching or controlling sessions.
- Distinctive: line 65
Check reads for target/provider errors, incomplete output, and the evidence required by the prompt.
- Very specific: line 67
Use sc agent send for clarification in the existing session.
- Very specific: line 71
Use sc team run only for genuinely independent fan-out whose roles do not require per-role UI or model overrides:
- Distinctive: line 82
Every team prompt must include its task, absolute handover paths, read/write limits, and this completion contract:
- Distinctive: line 102
Do not create sidecar directories, repository run stores, membership records, coordination-state mirrors, or custom JSONL state.
- Very specific: line 112
Verify response.new_title.
- Distinctive: line 116
Do not stop agents, close tabs/views, delete groups, or remove other managed state unless the human requested cleanup.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Superconductor CLI
Use live sc instructions and capability output as authoritative. Keep SC syntax and lifecycle policy here; role skills should reference this skill rather than reproduce commands.
Boundaries
- Use SC only for the requested orchestration or app-managed outcome.
- Require explicit human intent for worktree/branch creation or deletion, target-branch changes, force termination, destructive cleanup, closing/rearranging existing sessions, and unrelated review-thread mutations.
- Never create a worktree merely for delegation or launch replacement agents for follow-ups.
- Prefer stable labels or stable target IDs and
--active keep. - Dispatch and idle state are not completion; always wait, read, and verify.
Live Preflight
Before the first mutation, run the matching guide:
| Area | Command |
| Agents, teams, delegation | sc instructions orchestration |
| Tabs, panes, views | sc instructions layout |
| Worktrees or branches | sc instructions worktree |
| In-app review threads | sc instructions review |
For orchestration, inspect current capabilities and targets:
command -v sc
sc layout capabilities --output json
sc layout views --worktree "$PWD" --output json
sc agents list --worktree "$PWD" --output json
sc chat providers --jsonVerify the launch shape, provider, UI mode, model, reasoning level, and structured-read support before specifying them. If unavailable, report the exact limitation instead of silently substituting another mechanism.
Read references/orchestration.md before launching or controlling sessions. Read references/worktrees-and-reviews.md before requested worktree or review-thread operations.
Individual Pi Worker
Delegated Pi sessions default to terminal mode. Long prompts should use a temporary JSONL launch input built with jq; it is command input, not durable workflow state, and must be removed after launch.
sc layout run tabs \
--provider pi --ui terminal \
--label worker-TODO-001 \
--prompt 'Complete prompt with task and absolute handover paths.' \
--worktree "$PWD" --active keep --output jsonCapture the returned label/stable target. Then collect that same target:
sc agent wait --to label:worker-TODO-001 --idle --timeout-ms 120000 \
--worktree "$PWD" --output json
sc agent read --to label:worker-TODO-001 --last 40 \
--worktree "$PWD" --output jsonCheck reads for target/provider errors, incomplete output, and the evidence required by the prompt. Verify source-writing results independently with Git and tests. Run shared-checkout source writers sequentially.
Use sc agent send for clarification in the existing session. If a turn must be redirected, interrupt then send. Do not infer success from launch, queue admission, or idle state.
Independent Teams
Use sc team run only for genuinely independent fan-out whose roles do not require per-role UI or model overrides:
sc team run \
--label correctness --provider pi --prompt 'Independent read-only review prompt.' \
--label regressions --provider pi --prompt 'Independent read-only review prompt.' \
--worktree "$PWD" --output jsonsc team run currently has no per-role --ui, --model, or --reasoning flags. When an ensemble requires distinct Pi models or Pi Chat UI, launch individually labeled sessions with sc layout run tabs, wait/read their stable targets, and fan their reports into the designated lead session. Do not claim those sessions are an SC team run or instruct them to call sc team report.
Every team prompt must include its task, absolute handover paths, read/write limits, and this completion contract:
sc team report --run RUN_ID --role ROLE --status done \
--summary 'Concise evidence-based report.' --worktree "$PWD" --output jsonUse --result-file only when a detailed report exceeds the summary limit; do not use it for the session-file workflow. In a synchronous workflow, capture the returned stable role targets, wait for them, then collect the durable reports with sc team status. Once every role is Reported, use those report summaries directly; call sc agent read only for a missing, failed, or malformed report.
Do not pass --notify self when the coordinator waits synchronously. That option inserts the team synthesis into the creator's editor as a follow-up prompt and may require the user to submit it. Use it only for an explicitly asynchronous workflow, end the coordinator turn after launch, and explain that behavior to the user. Never combine it with manual wait/status collection. Team launch provides parallelism, not sequencing.
Session-File Handover
For /plan, /todos, /execute, and /review:
- A coordinator session file is required:
PI_SESSION_FILEin Pi, or$HOME/.claude/projects/<project slug>/$CLAUDE_CODE_SESSION_ID.jsonlin Claude Code (slug = the project directory path with/and.mapped to-). - Durable handover files are exactly
${SESSION_FILE%.jsonl}.plan.md,${SESSION_FILE%.jsonl}.todos.md, and${SESSION_FILE%.jsonl}.review.md. /reviewmay use the session JSONL and Git state without plan or todos files; include either handover when it exists.- The coordinator alone writes these files.
- Delegated prompts receive the resolved absolute paths and read them directly.
- Do not create sidecar directories, repository run stores, membership records, coordination-state mirrors, or custom JSONL state.
Managed Terminal Title
In a managed Pi terminal:
sc tab title "$TITLE" --to "id:terminal:$SUPERCONDUCTOR_TERMINAL_ID" --jsonVerify response.new_title. Do not omit the stable target.
Cleanup
Do not stop agents, close tabs/views, delete groups, or remove other managed state unless the human requested cleanup. Inspect exact targets and current help before any such operation.
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- commitSkill
- frontend-designSkill
- githubSkill
- pi-extension-developmentSkill
- planSkill
- reviewSkill
- scoutSkill
- session-readerSkill
- setup-superconductor-projectSkill
- skill-creatorSkill
- visualize-planSkill
- workerSkill
- write-todosSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

