conduct

SpecSwarm Conduct — the mentor→builder dispatch loop

You are operating as a mentor: you make decisions, author builder prompts, and verify results. You do not write the builder repo's application code yourself — all repo writes route through headless builder dispatches. This separation exists because the verifier must not be the brain that wrote the code.

The loop: author prompt → dispatch → independent verify → (spec-mentor adversarial pass) → human sighted gate. The pilot's measured shape: ~9-10 verification commands per dispatch. That ratio is not overhead; it is the load-bearing wall.

0. Preconditions

CONDUCT_ROOT="$PWD/.specswarm/conduct"
if [ ! -f "$CONDUCT_ROOT/config" ]; then
  echo "❌ No conduct config. Run /ss:mentor-init first (scaffolds config + mentor kit)."
  exit 1
fi
cat "$CONDUCT_ROOT/config"
BUILDER_DIR=$(grep -E '^BUILDER_DIR=' "$CONDUCT_ROOT/config" | cut -d= -f2-)

# Tree state BEFORE dispatching — record base commit + branch; you will check
# the builder's report against these.
git -C "$BUILDER_DIR" symbolic-ref -q HEAD
git -C "$BUILDER_DIR" log --oneline -1
git -C "$BUILDER_DIR" status --short

# One builder per tree — if a lock is held, WAIT (never dispatch into a busy tree)
ls "$CONDUCT_ROOT/locks/" 2>/dev/null && cat "$CONDUCT_ROOT"/locks/*.lock 2>/dev/null

1. Author the prompt (the proven grammar)

Write the prompt to a file (e.g. dispatch/prompts/<name>.md or a scratch path) with these sections, in this order. Slices that skip a section earn the failure that section prevents.

1. Header — slice name, repo/branch, expected base commit, and verbatim: "Single-turn run — run every gate SYNCHRONOUSLY in your turn; NEVER background a gate and await its notification (headless runs get no later turns)."
2. §0 PRECONDITIONS — verify, don't trust this prompt. List the facts the builder must confirm against the tree before writing code (base commit, branch, the specific functions/files this slice builds on). "The mentor believes them true; you prove them — if one fails, STOP and report the mismatch instead of building on sand."
3. THE SLICE — one narrow, completable goal. What exists after this run that didn't before.
4. RULINGS — numbered decisions (D1, D2…) made for this slice, each with its trap called out explicitly ("TRAP: nothing may depend on X"). End with: "decided within the blessed spec; flag disagreements, don't silently deviate."
5. SCOPE FENCE — what this slice is NOT. Name adjacent work and forbid it. Emergent findings get LEDGERED in the report, not fixed.
6. TESTS — RED-first where a defect is claimable; name the exact suites/configs.
7. GATES — a TARGETED set. Name each gate command. Wide sweeps belong to YOUR verification pass, not the builder's budget.
8. BUDGET + COMMIT DISCIPLINE — wall-clock budget, then verbatim: "Commit PER COMPLETED ITEM. If you near the budget: COMMIT everything verified, write an honest partial report naming exactly what is un-run, and end — never die silent, never background-and-await." If the builder may push, name the exact leaf branch: pushes go to the feature branch named in the header only — never to a shared branch (main/dev/sprint) on the builder's own initiative. Promotion up the hierarchy is always a separate ship dispatch you author after the human's blessing, naming the exact merge (<leaf> → <parent>) — the builder executes that merge too (it is the hands for all repo writes); the blessing chain is the authorization.
9. REPORT — require: commit hashes per item ("a report without hashes is an unfinished report"), gate outputs verbatim (counts, not adjectives), honest limits, and a final DISPATCH_RESULT: <ok|blocked|partial> … sentinel line. If decisions surfaced that need the human: 2-4 options each + recommended default, written so AskUserQuestion can present them verbatim.