synapseradio Runbook
A runbook decomposes work into a steerable autonomous loop and then runs it. Seeding facilitates an alignment conversation and writes the durable state that encodes intent. Executing turns the current session into the orchestrator that drives the loop from that state.
Modes
Two modes share this skill. Route to one before doing anything else.
Routing is layered. Apply the explicit signal first; fall back to artifact presence only when no explicit signal fires.
| Signal | Mode |
|---|---|
| "execute mode against a directory", "run/continue/resume the runbook" | Execute |
| "create a runbook", "set up an autonomous loop", "start a hardening pass" | Seed |
| No explicit signal, FOCUS.md present in the target directory | Execute |
| No explicit signal, FOCUS.md absent | Seed |
The target directory is the directory the user names. If the user names no directory, it is the current working directory.
Two ambiguity guards override the table. If artifacts are already present but the user asks to redesign the runbook, confirm before overwriting anything — do not silently seed over existing state. If the user asks to execute but no artifacts are present, there is nothing to run; offer seed mode instead.
Context Loading
Load references only when the current phase needs them. Each phase loads only its own file.
| Phase | Load |
|---|---|
| Alignment | references/alignment-guide.md |
| Gate check | references/checklist.md |
| Seeding | references/seeding-guide.md |
| Execute | references/execution-guide.md |
Phase 1: Alignment
Load references/alignment-guide.md and follow its protocol.
The alignment conversation surfaces seven elements:
- What — the work, decomposed to the level where a single lens applies
- Why — the motivation, so discovery can prioritize
- Lens — what the loop looks for or builds toward (feature requirements, style compliance, design improvements, security, performance, migration targets)
- Authority — what reference the loop consults (a PRD, design spec, style guide, issue tracker, architecture doc)
- Scope — directories, files, or areas in and out of bounds
- Success — what "done" looks like, concretely
- Mode — tight loop (default) or recursive decomposition (opt-in)
The alignment conversation also surfaces behavioral exclusions (no-gos) and risks as part of the scope and decomposition discussion. These are not separate elements — they emerge naturally from probing scope boundaries and hidden risks.
Use inline visualizations, scope diagrams, and AskUserQuestion for structured choices. Decompose vague intent into specific, testable goals.
Tight loop vs. recursive decomposition
Most work is a tight loop: one lens, one scope, grind until converged. This is the default.
Recursive decomposition is opt-in, for work that has independent sub-problems benefiting from separate lenses. When selected, the parent FOCUS.md seeds child FOCUS.md files, each scoped tighter. Children report outcomes upward via LEARNINGS.md. The parent aggregates.
Only propose recursive mode when the problem's structure demands it.
Exit conditions
Apply all three, in order:
- Convergence detection. Notice when questions stop producing new constraints. State this observation explicitly.
- Checklist gates. Load
references/checklist.md. Validate every gate. Present pass/fail to the user. - Explicit approval. Halt and request confirmation before seeding. Never seed without the user's "go."
Phase 2: Seeding
Load references/seeding-guide.md.
Before entering plan mode, ask the user for two things:
- Target directory for the artifacts (FOCUS.md, TASKS.md, LEARNINGS.md).
- Execution route — attended or unattended. Attended means the invoking session runs rounds continuously, emitting a compact per-round summary as the steer point. Unattended means a thin scheduled stub starts a fresh session that runs exactly one round and stops, with the files carrying all state between rounds.
Enter plan mode. Write the plan file following the structure in
references/seeding-guide.md. The plan writes only the three durable
artifacts — no loop prompt. The plan file contains:
| Section | Content |
|---|---|
| Context | Why this loop exists — motivation and intended outcome |
| FOCUS.md → path | Complete FOCUS.md with all sections populated, including a Route: line |
| TASKS.md → path | Empty board skeleton |
| LEARNINGS.md → path | Empty structured memory |
| Execution & Deployment | One-time wiring: the chosen route, and the schedule target if unattended |
Exit plan mode for user review.
Nothing from the alignment conversation survives as conversational residue in the plan. The plan reads as if written by someone who already knew the requirements.
Execute Mode
Precondition: exactly one FOCUS.md in the target directory. A parent FOCUS.md
that carries a ## Children table is a coordination document, not a runnable
loop — list its children and ask which one to run.
Load references/execution-guide.md and follow its protocol. The
orchestrator never implements directly. All implementation, discovery, and
side-effect work is delegated to subagents. If the environment cannot
delegate to subagents, stop and tell the user — never fall back to
implementing the work yourself.
Read the route from FOCUS.md's Route: line. If the line is absent, treat
the route as attended. Keep each round cheap: re-read TASKS.md and the
LEARNINGS.md Summary section only, per round.
Rules
Seeding rules
- Alignment is a conversation, not a form. Explore, reflect, let the user correct. Do not interrogate with a checklist upfront.
- Never seed without explicit approval. Checklist gates are necessary but not sufficient. The user's confirmation is the hard stop.
- Conversation content is ephemeral. Explanations, diagrams, and AskUserQuestion interactions from Phase 1 do not appear in the plan file. The plan stands alone.
- Default to tight loop. Only propose recursive decomposition when sub-problems are clearly independent.
- LEARNINGS.md is append-only. The loop writes, the user reads. Never overwrite or delete entries.
- Scope belongs in FOCUS.md, not machinery. Keep specifics in the lens file, not in the execution protocol.
- Resist adding machinery. If something can be a line in FOCUS.md instead of a feature in the protocol, put it in FOCUS.md.
Execute rules
- The orchestrator never implements. Delegate all implementation, discovery, and side-effect work to subagents.
- State lives in files, not conversation. Every round re-reads FOCUS.md, TASKS.md, and the LEARNINGS Summary fresh. A restart resumes cleanly.
- One task per round. After a task resolves, the round ends.
- Revert on failure. Return a failed task to Open with a note and never fix it in the same round.
- The route governs the driver. Unattended runs one round and stops; attended runs continuously with a per-round summary as the steer point.
Additional Resources
Reference Files
references/alignment-guide.md— Conversation protocol for Phase 1: decomposition techniques, question patterns, visualization approachesreferences/checklist.md— Structured gate validating alignment completeness before seedingreferences/seeding-guide.md— Artifact templates and production instructions for FOCUS.md, TASKS.md, LEARNINGS.mdreferences/execution-guide.md— The execute-mode protocol: round lifecycle, delegation briefs, the placement framework, and convergence