Skills/boss/SKILL.md

---
name: boss
description: User-invoked only (typed as `/boss`). Activates autonomous orchestrator mode — Claude picks the next iteration from the project's issue backlog, dispatches the appropriate skill, and continues until done-state or genuine bounce-back. Outside `/boss`, the default is interactive collaboration with the user, not autonomous queue execution.
---

# boss — autonomous orchestrator mode

> **Violating the letter of these rules is violating the spirit.**

## Overview

Autonomous orchestrator mode is how the orchestrator moves a
project forward when the user is away. Inside this mode, Claude
reads the project's issue backlog, picks the top item,
dispatches the right skill, integrates the result, and continues
to the next item — until the queue is empty (done-state) or a
real design fork forces a bounce-back to the user.

Outside this mode, the default is interactive collaboration:
the user asks; Claude answers or executes the specific request;
Claude stops. There is no autonomous picking from the backlog,
no multi-iteration sequence chained off a single user message.

This skill exists to make the mode-switch explicit. Without it,
autonomous behaviour and interactive behaviour both fight for
"default" in every fresh session, with the failure mode of an
interactive session silently turning into an autonomous one
(or vice versa).

## When to Use / Skipping

Trigger:

- The user explicitly types `/boss` in chat.

Never auto-invoked. Even if a skill-system convention says "if a
skill might apply, invoke it" — that does NOT apply here.
`/boss` is a deliberate mode switch performed by the user, not a
heuristic the orchestrator resolves on its own. A session that
wanders into autonomous behaviour without `/boss` is the exact
failure mode this skill exists to prevent.

May be exited mid-session by:

- The user signalling "stop", "pause", or "back to chat".
- A bounce-back trigger firing (see "Direction freedom" below).
- Done-state (the queue is empty and the done-state procedure has
  fired).

A fresh session always starts in interactive mode; the user
re-enters by typing `/boss` again.

## The Iron Law

```
NO AUTONOMOUS DISPATCH OUTSIDE A `/boss` SESSION.
DONE-STATE = QUEUE EMPTY, NOT SUB-GOAL COMPLETE.
BOUNCE-BACK ONLY ON THE FOUR NAMED TRIGGERS.
A NEW CYCLE NEVER STARTS AUTONOMOUSLY — IT IS A BOUNCE-BACK.
```

Universal rules (only-orchestrator-commits, main-is-sacrosanct,
language, RED-first for bugs) come from the project's `CLAUDE.md`
— and from the user-level `~/.claude/CLAUDE.md` identity/security
layer above it, loaded in every session. Both bind regardless of
mode; autonomy does not lift a user-level constraint (e.g. an
external-service-consent rule that names `/boss` explicitly). This
skill does not restate them.

## The Process

### Step 1 — Read the queue

The project's issue tracker is the forward queue. Read open
issues via the list command in the project's CLAUDE.md project
facts. If the project names no issue tracker there, it does not
have an autonomously addressable queue — bounce back to the user
with that diagnosis.

If the entire open backlog is empty: skip to Step 5
(done-state). Do not invent work; an empty queue is a real
signal that the cycle closed and there is nothing left.

### Step 2 — Pick the top item per direction-freedom rules

See "Direction freedom" below. The rules permit picking
autonomously when the path is clear. If the top item is a real
fork (two substantive options with no clear default), bounce
back to the user.

### Step 3 — Dispatch the appropriate downstream skill

Pipeline:

```
brainstorm → specify → planner → implement → audit → fieldtest
             specify → planner  (design settled in sources, no discovery)
                  +
                  debug (bug-triggered)
                  +
                  tdd → implement (mini)  (test-specifiable feature)
                  +
                  compiler-driven  (behaviour-preserving type/signature edit; observe-then-bounce)
                  +
                  docwriter (post-stability)
```

Match the chosen item to the right entry skill. If a spec exists
but no plan: `planner`. If a plan exists: `implement`. If a cycle
is closing: `audit`. If the iteration is a bug-fix: `debug`. For
new feature work with no spec or plan yet, run the **Entry-path
reflection** below before dispatching anything. Read each skill's
`SKILL.md` trigger section if unsure.

**Entry-path reflection (feature work).** Entry paths form an **ordered
cascade**, and the choice is made by reflection every time, not by
habit. The discriminator is no longer a single "design line": it adds a
**verification / enumeration axis** *ahead of* the settled-vs-fork
question, so each lighter path carries a **positive** trigger matched by
signature rather than being reached by elimination. Walk the cascade top
to bottom and take the **first** arm that matches; record the one-line
verdict ("observed bug → `debug`" / "design fork → `brainstorm`" /
"mechanical type-edit → `compiler-driven`" / "test-specifiable →
`tdd`" / "settled prose design → `specify`") in the loop.

```
route(task):
    observed bug                          -> debug          # RED-first gate, FIRST — never bypassed, even for a one-line fix
    forces a genuine design choice        -> brainstorm      # the only place doubt resolves "up"
    a type/signature edit at a definition
      site, propagating mechanically       -> compiler-driven  # observe-then-bounce; behaviour-preserving
    new behaviour as one honest assertion -> tdd
    else                                  -> spec-driven      # the deliberate heavy fallback (specify -> planner)
```

- **Observed bug → `debug`.** A regression of existing behaviour is
  RED-first, always, and this check is **first in the cascade** so a bug
  whose fix happens to be a one-line type edit cannot slip into the
  compiler-driven arm and bypass the RED-first gate. Dispatch
  autonomously, as a bug issue already is.
- **Forces a genuine design choice → `brainstorm`.** Writing the work
  down would force a choice between two or three plausible designs with
  real trade-offs. Discovery must resolve it first. Starting a fresh
  `brainstorm` cycle is itself a bounce-back per §"Direction freedom"
  trigger 4 — green-light the cycle (and the session shape) with the
  user first.
- **A type/signature edit at a definition site, propagating mechanically
  → `compiler-driven`.** The positive trigger is *syntactic and
  observable*: a carrier/newtype narrowing, a constructor or field
  rename, a signature change at a definition that the type checker then
  enumerates across N call sites — **behaviour preserved**. The arm is
  **observe-then-bounce** (its executor is `../implement` "The
  compiler-driven arm" + the `compiler-driven-edit` workflow): make the
  edit, build, run the suite; **clean build AND suite green unchanged →
  commit; a hole that forces a design decision → bounce to `specify` (or
  `tdd` if the hole turns out to be test-specifiable new behaviour, per
  the straddle rule); the suite not green-unchanged → bounce to `debug`,
  RED-first.** Entering on
  the observable trigger and letting a real run settle the verdict is
  what makes this sound — a mis-routed behaviour change fails the
  post-condition and bounces instead of shipping green-but-wrong.
  Dispatch autonomously; its bounces are reactive, not a pre-dispatch
  checkpoint.
- **New behaviour as one honest assertion → `tdd`.** The desired
  behaviour can be pinned by one minimal falsifiable assertion — "calling
  X with Y returns Z". Dispatch autonomously.
- **Else → spec-driven (`specify` → `planner`).** The deliberate heavy
  fallback for prose-design work the sources already settle (an
  exhaustive issue body, a long in-context discussion). `specify` is
  bounded (no interview); dispatch it autonomously and it pauses at its
  own user-review gate (a problem-state notify, not a pre-dispatch
  checkpoint) unless the project enables spec auto-sign.

**The straddle rule (a rule, not an example).** "Add an enum variant"
straddles the compiler-driven and the tdd/spec arms. Decide by what the
edit *encodes*, not by its surface shape: an arm that is **mechanical /
forwarding** — the type checker enumerates the sites and behaviour is
preserved (an exhaustiveness-only variant, a pass-through case) — is
**compiler-driven**; an arm that **encodes new behaviour** — a variant
whose handling is a new code path with new observable output — is
**tdd** (one assertion) or **spec-driven** (a real design). When unsure
which side a change falls on, that doubt is itself the signal it carries
behaviour: route up to tdd/spec, not down to compiler-driven.

The asymmetry in autonomy — `debug`, `compiler-driven`, `tdd`, and
`specify` all dispatch autonomously, while a fresh `brainstorm` cycle
bounces back — is **not** a ranking of the paths. It is a consequence of
context budget: the four are bounded (no open Q&A; `compiler-driven` and
`debug` self-settle on a run), whereas a fresh `brainstorm` is
high-context discovery the orchestrator cannot compact on its own (see
trigger 4). `specify` dispatched in `/boss` pauses at its own Step-6
user-review gate to take sign-off — a final-sign-off notify, not a
pre-dispatch checkpoint. The one exception is spec auto-sign: when a
project enables it in its CLAUDE.md project facts, a spec that clears all
objective gates AND a unanimous adversarial `spec-skeptic` panel is
signed by the orchestrator without pausing, and the run continues to
`planner` — see §"Spec auto-sign" below. The gate is built so the
orchestrator's own confidence is never what signs; absent that, the
human signature stays mandatory. Do not let the asymmetry harden into a
reflex of routing borderline items to `brainstorm` "to be safe" — that
is the exact bias this reflection exists to break; walk the cascade
honestly each time. The one principled tilt is two-sided and lives
*inside* the test: genuine doubt about whether the sources (or one
assertion) can pin the design *is itself* the design-fork signal, so it
resolves to `brainstorm` — not because `brainstorm` is preferred, but
because unresolved ambiguity is a fork by definition. The lighter arms
also bounce reactively: a `specify` or `tdd` that later reports the
design was not settled / not test-specifiable, or a `compiler-driven`
run that hits a hole, escalates — `specify` / `tdd` to `brainstorm` (a
fresh cycle, a trigger-4 bounce-back), `compiler-driven` to `specify` or
`tdd` (a hole — a design choice vs. test-specifiable new behaviour, per
the straddle rule) or `debug` (the regression).

All entry paths are always available — none is profile-gated. The
cascade is the order of decision: the lighter arms (`debug`,
`compiler-driven`, `tdd`) carry positive triggers and dispatch
autonomously, `specify` dispatches autonomously and pauses at its
sign-off gate, and a fresh `brainstorm` is the one path that bounces
back to the user before it starts.

If the working tree is mid-flight (uncommitted changes left over
from a previous session): inspect first, then resume the right
step. Do not restart from scratch.

### Step 4 — Loop, deciding on each agent output

For each dispatched skill's result, decide:

- **Continue** — agent output is good, next item is obvious,
  the queue is non-empty. Most common case.
- **Bounce-back** — one of the four named triggers fired (see
  "Notifications" below). Send a notify, stop the loop.
- **Done-state** — queue is empty AND the cycle is fully
  ratified (audit drift-clean, fieldtest clean if applicable).
  Go to Step 5. A `/boss` done-state means this run has nothing
  left to dispatch; it is **not** an automatic milestone close —
  closing a tracker milestone needs its end-to-end milestone
  fieldtest green and stays a deliberate manual act (see
  `../docs/pipeline.md` § Milestone-close gate).

If a term-drift is resolved during the loop — two names collapsed to
one, or a settled term not yet listed — record it in the project
glossary per `../docs/glossary-convention.md`: record reality, never
invent. This is the only glossary write authority outside the user.
Building a glossary from scratch (the `glossary` skill's bootstrap) is
*not* this authority — it is high-context, user-only work; when a project
lacks a glossary and drift is visible, recommend a bootstrap via
bounce-back, never run one autonomously.

### Step 5 — On done-state: Notify

Run the procedure named in "Done-state notifications" below.

## Direction freedom

The orchestrator has authority to choose the next iteration,
refactor, or feature without asking. Wrong calls are contained,
not recovered: only the orchestrator commits, and only when the
working-tree state is consistent — so bad work doesn't reach
main in the first place. If a dispatched agent's output is
wrong, the remedy is `git checkout -- <paths>` on the working
tree (orchestrator-side), never a rewind of main HEAD. main is
forward-only.

The cost of asking "what should I do next" — context-switch for
the user, latency on my side — exceeds the expected cost of
discarding a bad working-tree state. So when the queue is
non-empty and the path is clear, just pick and proceed.

Bounce back to the user only when:

- A queued option requires a real design judgement I have not
  made myself (genuine architectural fork, multiple substantive
  options none of which is clearly default).
- I have hit something genuinely unexpected that changes the
  project's direction (a fundamental design flaw, an external
  dependency failure, a discovered invariant violation).
- The user has explicitly asked for a checkpoint.
- **The next item on the queue is a new cycle** — i.e. a top-
  level work container (a milestone) that has no spec file yet and
  would require dispatching `brainstorm` to even begin.
  Continuing an open cycle (next iteration, audit, fieldtest,
  post-audit tidy) is autonomous; *starting* a new cycle is a
  bounce-back.

  **Why this is different from the other three triggers.**
  Cross-cycle work is high-context work. A fresh brainstorm
  alone routinely consumes tens of thousands of tokens on
  grounding-check reads, design Q&A, and spec drafting — on top
  of whatever context the just-closed cycle left behind. The
  orchestrator cannot compact its own context window; only the
  user can decide that the right shape for the next cycle is a
  fresh session rather than a continuation. A new cycle is
  therefore the natural checkpoint: stop, surface the
  candidate, let the user pick the session shape (continue here
  / spawn fresh / defer / pick a different backlog item).

A summary of what shipped is fine and welcome — but in
autonomous mode, follow it with the next dispatch, not a
question.

## Notifications

Two states call for a notify; nothing else does — plus a third,
narrow one that exists only when spec auto-sign is enabled:

1. **Done-state.** The autonomous queue is empty — the cycle
   closed, the audit ratified, and no further iteration is
   obvious from the spec or the backlog (or, in a user-scoped
   session, every objective the user named has been completed
   and there is nothing else queued). A finished sub-goal
   inside a still-open cycle is *not* done-state. If the next
   iteration is obvious and substantive, keep dispatching —
   "test suite landed", "audit clean before close-fixes",
   "iter N done with N+1 in scope" are internal progress, not
   notify events.

2. **Problem-state.** A bounce-back trigger per §"Direction
   freedom" — design fork the orchestrator cannot resolve, an
   unexpected invariant violation, an external dependency
   failure, the user has explicitly asked for a checkpoint, or
   the next backlog item is a new cycle (no spec yet) and
   starting it would force a fresh `brainstorm`.

3. **Auto-sign (only when the project enables spec auto-sign).** The
   orchestrator signed a spec in the user's place and is
   continuing the run — see §"Spec auto-sign". This is the one
   sanctioned mid-flow notify, and it is sanctioned *because it
   carries a decision*: the spec normally needs the user's
   signature, so the user retains a veto over what was signed
   without them. It is not a progress ping — it is the audit
   trail for a gate the user delegated. It does not stop the
   loop.

A user-specified stop trigger ("until X is done, then notify")
counts as done-state only if X is truly the last actionable
item in the autonomous queue at that moment. If hitting X
still leaves an open cycle with obvious follow-up iterations,
the right action is to continue past X without notifying —
the user's intent behind the trigger is "wake me when there's
nothing else to do", not "wake me at this specific checkpoint".

Mid-flow progress notifications burn the user's attention
without giving them a decision to make. When in doubt,
continue.

The notification command is `~/.claude/notify.sh` (the user-level
convention); it receives the message text as a single argument. If it
is unavailable, fall back to printing the notification in chat.

When notifying, the message body should be the actionable
summary: what the orchestrator needs from the user, in one
short line. Skip the "hi, I" framing — just the gist. The user
will see it on a phone and likely respond by returning to the
session.

By default, the orchestrator acts autonomous. The notification
is the exception, not the rule.

## Done-state notifications

When the trigger is **done-state** (autonomous work has wrapped
up, nothing left to do for the user to react to), send one
text via the configured notification command.

The text must be written for the **user-as-reader who did not
watch the orchestrator work**:

- **Language: same as the rest of the repo.** The notify push is
  permanent enough to be treated as project content; under the
  cross-project English-in-repos rule, it is English.
- **No technical internals.** Don't name crates, function
  identifiers, type names, agent names, or iteration codes
  (`ct.1.7`, `18a`, etc.). Describe the *change in the project*
  — what is now possible, fixed, or visible — not the mechanics.
- **No assumption of context.** The user is on their phone and
  has not seen this session. Lead with the result; the *why*
  is fine if it fits in one short clause.
- **Length: Telegram-pragmatic.** No hard cap, but a few
  sentences, not an essay. If the work covered multiple
  unrelated things, bullet them.
- **Tone: factual, not performative.** No celebration, no
  "I have successfully…". Just "X works now, Y is fixed, Z is
  new".

**Bounce-backs** (asking the user for a design judgement or
checkpoint) follow the same editorial rules but carry the
actionable ask, not a wrap-up summary.

## Spec auto-sign

Off by default. A project turns it on in its CLAUDE.md project facts
(spec auto-sign: enabled). With it off, a `specify`
dispatch in `/boss` always pauses for the user's signature — the
conservative default, unchanged.

With it on, the orchestrator MAY sign a spec in the user's place,
but only through `specify`'s Step-6 auto-sign gate, which is owned
and defined there. The boss-side contract is just this:

- **The gate is not the orchestrator's judgement.** Signing requires
  every objective gate green (precondition, parse, a `grounding-check`
  `PASS` that needed no human override) AND a unanimous five-lens
  `spec-skeptic` panel returning `SOUND`. "The spec looks good to me" is
  never a signature; that confidence is the exact signal the gate
  refuses to trust.
- **A `BLOCK` is repaired or escalated, never signed over.** The gate
  splits the five lenses by what a `BLOCK` means. An *editorial* `BLOCK`
  (`criterion` / `ambiguity` / `plan-readiness` — the spec is
  under-articulated) the orchestrator may repair in a bounded loop:
  edit, re-run the objective gates, re-dispatch all five lenses, up to
  2 rounds. A *design* `BLOCK` (`scope-fork` / `grounding` — the ground
  is not settled), an `INFRA_ERROR`, any objective gate not green, or an
  exhausted 2-round budget routes the spec to the human sign-off pause
  it would have hit anyway. The orchestrator never settles a design
  question in the user's place; the full re-panel each round is what
  stops an editorial repair from laundering one in. The gate owns this
  loop (`../specify/SKILL.md` Step 6) — boss only enforces the notify.
  One upstream detail matters here: a fork settled in-context may be
  invisible to the `scope-fork` juror, which reads the seeding issue.
  `specify` Step 1.5 gives it an auditable source either way — when a
  seeding issue exists but still lists the fork open, it posts a
  provenance-bearing reconciliation comment; when there is *no* seeding
  issue (design settled in pure chat), it creates one that records the
  resolution with provenance and becomes the cycle's seeding issue.
  Both record a *user* decision; neither lets the orchestrator certify
  its own — no real user statement is a Step-1.5 bounce, not an artefact
  to manufacture. The orchestrator writes the record; the juror checks
  the provenance.
- **On a clean sign, do not stop.** Commit the spec (the auto-sign
  commit subject carries `(boss-signed)` so the act is auditable in
  history), fire the auto-sign notify, and continue to `planner` in
  the same run. The notify is informational-with-veto, not a pause.
- **The notify must be vetoable.** It follows the same editorial rules
  as a done-state notify (English, user-as-reader, no iteration codes
  or crate names) with one addition forced by its purpose: it must
  name, in the user's terms, *what capability the signed spec covers*,
  so the user can decide whether to veto. State plainly that the spec
  was signed without them, that the plan is proceeding, and that a
  reply vetoes. One example shape: "Signed off the spec for <plain
  capability> myself and started the implementation plan — reply to
  veto." No internals, but enough identity to act on.
- **A veto is a forward correction.** If the user vetoes after the
  fact, the signed spec is already a commit on `main` (forward-only).
  Undo it forward — revert the spec commit, discard the downstream
  working-tree work with `git checkout`, file the redirection — never
  a history rewind. This is the same containment as any other
  orchestrator call (§"Direction freedom"): bad calls are contained on
  the forward edge, not recovered by rewinding HEAD.

## Common Rationalisations

| Excuse | Reality |
|--------|---------|
| "Iteration just landed cleanly, let me notify so user can see" | Mid-flow notifications burn user attention without giving them a decision to make. Iteration-clean is internal progress, not a notify event. |
| "Sub-goal of the cycle is done, that counts as done-state" | Done-state is queue-empty, not sub-goal-complete. If the next iteration is obvious and substantive, keep dispatching. |
| "Top of the backlog has two equally good options, I'll just pick one" | If both are substantive and the choice is non-obvious, that's a real fork — bounce back. The cost of a wrong pick (working-tree discard) is higher than the cost of one short ping to the user. |
| "User said 'until X then notify', X just completed, notify now" | Check whether X was actually the last actionable thing. If hitting X leaves an open cycle with obvious follow-up, the user's intent was "wake me when there's nothing else to do" — continue. |
| "Notify can name the iteration code — user will figure out what it means" | No. The notify text is for the user-as-reader who did not watch the orchestrator work. Iteration codes, crate names, function identifiers, type names — all internal, all banned. |
| "The previous cycle closed cleanly and the next backlog item is obvious — just dispatch `brainstorm` and keep going" | No. Starting a new cycle is itself a bounce-back. A fresh `brainstorm` is high-context work, and the orchestrator cannot compact its own context — only the user can decide whether the next cycle wants a fresh session or a continuation of this one. The "obviousness" of the candidate is irrelevant; the *cross-cycle hop* is the checkpoint, not the topic choice. |
| "It's the same broad area as the cycle I just closed, that's not really a new cycle" | If there is no spec file for it yet and it would route through `brainstorm` to get one, it IS a new cycle for this rule's purposes. The rule keys on "needs a fresh spec", not on subjective continuity. |
| "Feature work, so route it to `brainstorm` — that's the safe default" | The entry paths are an ordered cascade, none the default. Routing a settled design to `brainstorm` re-litigates decided choices; routing a test-specifiable item there wastes the test path; routing a behaviour-preserving type-edit there is the heavy-path gravity well this whole reflection exists to break. Walk the cascade and take the first matching positive trigger. The only tilt toward `brainstorm` is a genuinely unresolved fork — and that is a fork, not a default. |
| "It's just a mechanical rename across N files — run the full implement loop on it" | That is the `compiler-driven` arm's job, not the heavy loop. Route it there; the type checker enumerates the sites, and the done-signal (clean build AND suite green unchanged) is the gate. Funnelling a behaviour-preserving edit through the full per-task loop is the disproportionality the cascade was added to fix. |
| "The compiler-driven edit built clean — that's the done-signal, commit" | Clean build is only half. The done-signal is clean build **AND suite green unchanged**. A behaviour change can build clean; the unchanged-green suite is what catches it. No suite run, no commit — and if the suite isn't green-unchanged, bounce to `debug`. |
| "It's a bug but the fix is a one-line type edit — route it `compiler-driven`" | No. An observed bug is first in the cascade → `debug`, RED-first, regardless of how mechanical the fix looks. The bug-gate sits before the type-edit arm precisely so a regression cannot launder itself around RED-first. |
| "The issue is exhaustive but it's a new cycle, so bounce to the user before `specify`" | `specify` direct-entry is bounded and autonomously dispatchable — it is NOT the high-context `brainstorm` cycle that trigger 4 reserves for the user. Dispatch it; it will pause at its own user-review gate for sign-off. The pre-dispatch bounce is for an *open* design that needs discovery, not for a settled one that needs only production. |
| "`tdd` is the secondary skill, `brainstorm` is the real entry" | All entry paths are always available. The choice among them is the cascade, walked per item — not a habit of treating `brainstorm` as primary and the lighter arms as exceptions. The lighter arms exist to be reached; reaching past them by elimination is the failure the verification axis was added to prevent. |
| "Auto-sign is on and this spec is clearly good — I'll sign it and skip the panel" | The panel IS how a spec gets signed under auto-sign; there is no signing on judgement. Your sense that it is clearly good is the precise signal the gate is built not to trust. Run the objective gates, dispatch the five jurors, require unanimity. |
| "Four jurors said SOUND, one blocked on something I think is wrong — I'll sign" | Unanimous-or-nothing. You never sign over a `BLOCK`. If it is an editorial lens, repair it and re-run the whole panel (≤ 2 rounds); if it is a design lens or the budget is spent, it routes to the human sign-off it would have had anyway. Signing because *you* think the juror is wrong is overruling the panel — confidence by the back door. |
| "Auto-sign let me continue, so I don't need to notify — it's just progress" | The auto-sign notify is mandatory and carries a decision (the user's veto over a signature made without them). It is the one sanctioned mid-flow notify precisely because it is not progress — it is the audit trail for a delegated gate. |

## Red Flags — STOP

- About to send a notify on an internal-progress event (test suite landed, audit clean before close-fixes, iter N done with N+1 in scope).
- About to dispatch the next skill without checking that the previous output was actually good.
- About to autonomously dispatch in a session where the user did NOT type `/boss`.
- About to send a notify that names a crate, an iteration code, or an agent.
- About to bounce back at every iteration boundary "just to be safe" — that's reactive deference, not direction freedom.
- About to dispatch `brainstorm` on a backlog issue that does not yet have a spec file, without first bouncing back to the user. New cycles never start autonomously.
- About to route feature work to `brainstorm` without walking the Entry-path cascade — defaulting to it because it "feels safer" than the lighter arms, rather than taking the first matching positive trigger. Routing a *settled* design, a *test-specifiable* item, or a *behaviour-preserving type-edit* to `brainstorm` is as much a failure as skipping discovery on an open one.
- About to route an observed bug to the `compiler-driven` arm because "the fix is mechanical" — a regression is `debug`, RED-first; the bug-gate is first in the cascade for exactly this reason.
- About to route a behaviour-encoding change to `compiler-driven` because it "looks mechanical" — apply the straddle rule: if the change encodes new behaviour it is `tdd` / `spec-driven`, and doubt means it carries behaviour.
- About to accept a `compiler-driven` edit on a clean build without confirming the suite is green *unchanged* — the conjunction is the done-signal; a green-but-wrong change builds clean.
- About to sign a spec under auto-sign on confidence — without all objective gates green and a unanimous `spec-skeptic` panel; signing over any `BLOCK`; self-correcting a *design*-lens (`scope-fork` / `grounding`) `BLOCK` instead of escalating; or looping past the 2-round budget. The gate exists so the orchestrator's confidence never signs.
- About to run the auto-sign path at all when the project has not enabled spec auto-sign, or to skip the mandatory auto-sign notify after signing.

## Cross-references

- **Skill system index:** `../README.md` — skill table, agent
  roster, pipeline diagram.
- **Universal rules:** the project's `CLAUDE.md` — orchestrator
  role boundaries, commit discipline, design rationale,
  authority over skills, feature acceptance, RED-first for bugs.
  Plus the user-level `~/.claude/CLAUDE.md` (identity/security
  layer, loaded in every session, above the project file) — it
  carries constraints that bind autonomous runs too, including
  external-service-consent rules that `/boss` does not lift.
- **Queue:** the project's issue tracker — its CLAUDE.md project
  facts name the repo slug, the browsable URL, and the list command.
- **Glossary write-rule:** `../docs/glossary-convention.md` —
  record-reality discipline for the only autonomous glossary writer.
- **Spec auto-sign gate:** owned by `../specify` Step 6; the
  adversarial juror is `../specify/agents/spec-skeptic.md` (dispatched
  five times, one per lens). Enabled per project in its CLAUDE.md
  project facts — see `../docs/conventions.md`.
- **Downstream skills dispatched:** `../brainstorm`,
  `../specify` (spec-production core; autonomously dispatchable for a
  settled design), `../planner`, `../implement`, `../audit`,
  `../fieldtest`, `../debug`, `../tdd` (test-specifiable feature,
  always available; autonomously dispatchable like `../debug`),
  `../docwriter`.
- **Compiler-driven arm:** the lighter `compiler-driven` cascade arm and
  its observe-then-bounce executor are owned by `../implement` ("The
  compiler-driven arm") and shipped as the `compiler-driven-edit`
  workflow. The selector arm here and that executor are co-located on
  purpose: a future edit re-routing the light path back through the full
  loop changes both cross-references and is a visible regression.