iter boss: /boss skill — autonomous-mode discipline gated to user invocation
CLAUDE.md previously mixed universal facts (agent role boundaries, commit discipline, design rationale, file roles, TDD-for-bugs) with mode-specific autonomy rules (direction freedom, notifications, WhatsNew procedure). Autonomous-by-default conflicted with the user's intent that a fresh session should be collaborative-interactive unless explicitly elevated. Add `skills/boss/` containing only the three genuinely mode-specific subsections — Direction freedom, Notifications, Done-state notifications: WhatsNew.md. Trim CLAUDE.md from 343 to 243 lines; extend the skill- system pointer paragraph with a one-sentence /boss gate. Universal orchestrator discipline stays in CLAUDE.md because it applies whether /boss is active or not. Two cross-references that named the moved subsections by sub-heading are repointed: skills/implement/SKILL.md and the implement-orchestrator agent's standing reading list. The other ~11 agent-file references to "orchestrator framing" still resolve correctly because that framing stays in CLAUDE.md. skills/README.md skill table extended with a `boss` row (now eight skills); pipeline-diagram caption notes /boss wraps the pipeline. .claude/skills/boss symlink follows the existing relative-path convention.
This commit is contained in:
@@ -48,6 +48,12 @@ are sharper tools, not a replacement for orchestrator judgement.
|
||||
Specs go to `docs/specs/<milestone>.md`, plans to
|
||||
`docs/plans/<iteration>.md`.
|
||||
|
||||
Autonomous orchestrator mode — picking the next iter from
|
||||
`docs/roadmap.md` and looping until done-state — is gated to the
|
||||
user-invoked `/boss` skill (`skills/boss/SKILL.md`). Outside
|
||||
`/boss`, the default is interactive collaboration: the user asks,
|
||||
Claude responds, Claude stops.
|
||||
|
||||
## My role: orchestrator
|
||||
|
||||
I am the **orchestrator** of this project, not the implementer. The
|
||||
@@ -167,112 +173,6 @@ appeal does not count; neither does human ergonomics. Full criterion
|
||||
lives in `docs/DESIGN.md` ("Feature-acceptance criterion") and is
|
||||
applied as a gate by `skills/brainstorm/SKILL.md` during spec writing.
|
||||
|
||||
### Direction freedom
|
||||
|
||||
I have authority to choose the next iteration, refactor, or feature
|
||||
without asking. Wrong calls are contained, not recovered: only the
|
||||
Boss 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 (Boss-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.
|
||||
|
||||
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:
|
||||
|
||||
1. **Done-state.** The autonomous queue is empty — the milestone
|
||||
closed, the audit ratified, and no further iteration is obvious
|
||||
from the spec or the roadmap (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
|
||||
milestone 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 I cannot resolve, an unexpected
|
||||
invariant violation, an external dependency failure, or the
|
||||
user has explicitly asked for a checkpoint.
|
||||
|
||||
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 milestone with obvious follow-up iters, 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 him a decision to make. When in doubt, continue.
|
||||
|
||||
~/.claude/notify.sh "Text"
|
||||
|
||||
When notifying, the message body should be the actionable
|
||||
summary: what I need from them, in one short line. Skip the
|
||||
"hi, I" framing — just the gist. The user will see it on phone
|
||||
and likely respond by returning to the session.
|
||||
|
||||
By default, I act autonomous. The notification is the
|
||||
exception, not the rule.
|
||||
|
||||
### Done-state notifications: WhatsNew.md
|
||||
|
||||
When the trigger is **done-state** (autonomous work has wrapped
|
||||
up, nothing left to do for the user to react to), the procedure
|
||||
is two-step and the two outputs share one text:
|
||||
|
||||
1. Append a new entry to `docs/WhatsNew.md` (newest at the bottom,
|
||||
append-only — same chronological convention as the per-iter journals).
|
||||
2. Send the same text via `~/.claude/notify.sh`.
|
||||
|
||||
The text must be written for the **user-as-reader who did not
|
||||
watch me work**:
|
||||
|
||||
- **Language: English.** Same as the rest of the repo; both
|
||||
WhatsNew.md and the Notify push are permanent enough to be
|
||||
treated as project content.
|
||||
- **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 his 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) are *not* done-state and do **not** produce a
|
||||
WhatsNew entry — they stay as Notify-only.
|
||||
|
||||
Format of a WhatsNew entry: a `## YYYY-MM-DD — <short title>`
|
||||
heading followed by the message body. The body must match the
|
||||
Notify text verbatim.
|
||||
|
||||
## Bug fixes — TDD, always
|
||||
|
||||
Bug fixes are RED-first, autonomous, no orchestrator gate. See
|
||||
|
||||
Reference in New Issue
Block a user