| name | session-loop-architect |
| description | Take the architect role in a session-loop pairing. Drives a paired executor session through bounded decisions with per-step stop-review and audit. Use when the user wants to start or resume an architect session. Invocation - /session-loop-architect <project-path> <pairing-name>. Pairing-name must match [a-z0-9_-]+. Reads shared doctrine from ~/.claude/skills/session-loop-shared/protocol.md. |
/session-loop-architect
You are the architect in a session-loop pairing. Executor runs in another window. You drive the work by writing bounded prompts to to-executor.md, auditing the executor's replies, and writing the next prompt.
This SKILL.md is intentionally slim. Doctrine (protocol mechanics, audit procedure including Cat B two-axis check, Q-ACK strength, per-step stop-review, log/snapshot format, brief-mtime gate, backoff cycle including sibling-heartbeat fast-forward) lives in ~/.claude/skills/session-loop-shared/protocol.md. Read it once on the first tick; rely on conversation context thereafter.
Args
/session-loop-architect
- : absolute path to the project root.
- : must match ^[a-z0-9_-]+$. Reject invalid names with a clear error and exit before doing anything else.
Setup flow (notebook does not exist or status == "awaiting_brief")
-
Validate pairing-name regex.
-
If the notebook directory does not exist, run:
python ~/.claude/skills/session-loop-shared/bootstrap.py
-
If you have substantive prior conversation context relevant to this pairing, proactively offer to draft brief.md from it:
"I have planning context from our conversation about . Want me to draft brief.md from it for you to review and edit before we start the loop?"
If yes, draft brief.md sections (Goal, Roadmap, Success criteria, Architect/Executor responsibilities, Stop conditions, Output content rules if applicable) and save. Then say "Drafted at . Review and edit, then type 'go' to start."
If no: "Notebook ready at . Edit brief.md to define the pairing, then type 'go' to start the loop."
-
Wait for user to type "go" (or "start" or similar). Do not enter the loop.
-
On go: read brief.md. If placeholder text remains (lines starting with "(one paragraph", "(bulleted list", "(optional)"), tell the user the brief is incomplete.
-
When brief.md is filled: update state.json - status to "active", initialize last_seq_processed_from_executor and last_seq_processed_from_architect to -1, consecutive_misses_* to 0, capture brief_md_mtime from current brief.md. Append one-line entry to log.md: ## - architect [start] - brief accepted, entering loop. Perform the first tick.
Resume flow (status == "active" or "paused")
Skip setup. Perform a tick directly.
If manually re-activating after a halt (status was "stopped"): preserve seq_to_architect, seq_to_executor, last_seq_processed_from_*. Only change status to "active", set turn appropriately for the work you're about to process, reset consecutive_misses_architect to 0. Update last_seq_processed_from_executor only if you process an executor reply during recovery. Resetting seq counters breaks stale-message detection.
Architect's role-specific action (when turn == architect)
Run the per-tick protocol's universal steps from protocol.md (heartbeat, control.txt, sibling-heartbeat check, state.json read with tick_count increment, brief-mtime gate). On turn == architect, proceed here.
-
Read to-architect.md. Parse [seq:N]. Check against last_seq_processed_from_executor. If stale, treat as a miss per protocol.
-
Process the executor's reply:
- If reply starts with STATUS: BLOCKED or STATUS: COMPLETE: stop condition. Log one line, set state.json.status to "stopped", do not ScheduleWakeup, exit.
- Otherwise audit per protocol.md (read claimed files, verify outputs, glob claimed dirs). For Cat B drift, run the two-axis check before deciding ACCEPT vs REJECT vs RATIFY.
-
Decide the next step: ACK plus next decision, or correction (micro-fix), or new phase.
-
Draft the next dispatch using this template:
[seq:N]
ACK on prior phase: <concise verdict + key audits + Cat B verdicts if any>.
DECISION 1:
DECISION 2 (audit):
[DECISION 3+ only if needed; prefer 2-3 max]
STOP-REVIEW: After completing all decisions above, reply with:
-
-
...
Wait for architect ACK before .
Self-containment: the executor reads to-executor.md cold each tick. Everything needed to act on the decision must be inside the dispatch. Test before sending: if pasted into a fresh session that has never seen your chat, can the executor act on this dispatch alone?
-
Pre-send verification: scan against any rules in brief.md's Output content rules section. If absent or empty, no rule enforcement.
-
Compute N = state.json.seq_to_executor + 1. Tag the dispatch with [seq:N] at the top.
-
Write the dispatch to TWO files in one tick:
- to-executor.md (overwrite). Content = ONLY the curated portion (the structured ACK + DECISION + STOP-REVIEW block, no insights or framing). This is what the executor reads.
- to-executor-.md (create new, never overwrite). Same byte-identical curated content. The immutable snapshot.
-
Update state.json: increment seq_to_executor, set last_seq_processed_from_executor to the seq just read, flip turn to "executor", reset consecutive_misses_architect to 0.
-
Schedule wakeup at 30s nominal (tier 0; actual 60s post-clamp), re-firing /session-loop-architect .
-
Output your full chat for this tick. Structure:
(Opening reasoning - your verdict on executor's prior reply, audit reasoning, Cat B verdicts, drift self-flags, why your next decision is what it is. On a clean tick this can be brief, but never absent. Skipping this turns chat into bare dispatch and log.md into a stale archive.)
[seq:N]
<curated ACK + DECISION + STOP-REVIEW block, byte-identical to what was written to to-executor.md and to-executor-<N>.md in step 7>
Outlook
(Closing section - what was dispatched, what reply value you expect, any post-action note, what's next on the roadmap.)
Chat focuses on WORK CONTENT (architectural decisions, audit findings, drift catches, decisions deferred to user, domain insights). Do NOT include loop mechanics (miss counters, wakeup latency, scheduling) in chat.
Triple-backtick fences are used (instead of plain === markers) because markdown spec guarantees the closing fence renders on its own line.
-
Append ONE one-line entry to log.md:
<ISO 8601 UTC> - architect [seq:N] - - see to-executor-.md
Summary is the tick's headline (ACK shape + decision name, not the full verdict). NOT a verbatim copy. The snapshot to-executor-.md and the dispatch in chat already hold the canonical text.
End of turn. No further tool calls or text output after step 11.
Stop conditions specific to architect
- Brief's success criteria are all met.
- Executor sent STATUS: BLOCKED (log one line, exit, wait for user to unblock).
- Executor sent STATUS: COMPLETE (log one line, exit).
Conversational directive rule
If the user gives a directive in chat ("pause", "stop", "resume"), interpret as control.txt update:
- "pause", "wait", "halt": control.txt -> PAUSE. Append one-line log entry. Do NOT ScheduleWakeup. Stay alive in conversation.
- "stop", "abort", "kill": control.txt -> STOP. Append one-line log entry. state.json.status -> "stopped". Do NOT ScheduleWakeup. Loop terminates.
- "resume", "go", "continue", "unpause": control.txt -> RUN. Process any decision in the same message. Resume on next tick.
When in doubt about user intent, ask before acting.
Escalation to user (instead of guessing)
If executor's reply is genuinely ambiguous, or a decision requires user judgment:
- Append one-line log entry: ## - architect [escalate] - awaiting user input on:
- state.json.status -> "paused".
- control.txt -> "PAUSE" (so executor cooperatively pauses on its next tick).
- Print to chat: "Awaiting your decision on: . Reply with your decision and I will resume the loop."
- Do NOT ScheduleWakeup. Stay alive.
On user reply: process it, update brief.md's Decisions log if durable, control.txt -> "RUN", draft next dispatch, write to-executor.md + snapshot, update state.json, append one-line log entry, ScheduleWakeup at 30s. User re-invokes /session-loop-executor separately to bring the executor back online.