| name | wrap |
| description | Close out a work session — final human smoke test, doc/ADR reconciliation, optional skill packaging, then dispose the ephemeral STATE.md and hand off to /dobby:commit. Use when finishing a feature or session, or wrapping up before committing. |
| argument-hint | |
Turn a finished work session into durable project memory, confirm it works and the user understands it, then clean up. Read STATE.md (goal, findings, spec, work log) to know what shipped.
Step 1: Final human smoke test
From STATE.md's spec (user flow, goals, edge cases) and anything the executors/verifiers flagged as needing human judgment, build a SHORT list of user-facing behaviors the machine layers couldn't fully prove — cross-task end-to-end flows, subjective UX. Present them one at a time with AskUserQuestion (Pass / Fail / Skip). On Fail, dispatch the implementor agent (Agent tool, subagent_type: "dobby:implementor"; no commits) to fix it, then re-present. Don't re-run the per-task verification the workflow already did.
Push right — present a decision-ready brief, not raw output. For each behavior, the user should be able to judge in seconds: give them a compact Brief — what to test (the exact flow/steps to exercise), what to decide (the pass/fail question in their terms), and what's needed from you (any credential, seed data, or environment they must supply). Do the reduction work yourself; never dump logs, diffs, or a wall of raw output and ask the user to interpret it. If a behavior needs setup they alone can do, that goes in "what's needed from you" so nothing stalls silently.
Step 2: Reconcile project docs
Update only what the work changed:
- Root
CONTEXT.md — add or sharpen the domain terms resolved during the session. Before writing, read references/context-format.md for the format and the admission rules (domain-unique terms only — general programming concepts don't belong). Create it lazily if absent.
- Purity: it is a glossary and NOTHING else. Not a spec, not a scratch pad, not a home for decisions (those become ADRs). If a line describes HOW something works rather than what a term MEANS, it doesn't belong here.
- Module
CONTEXT.md — for each module the work created or changed, create/update its own CONTEXT.md (purpose · Files · Interface · Invariants · What's NOT here) so it reflects the module's current interface, invariants, and contents. (Executors keep this current as they build; here you reconcile anything left.)
- Cross-reference invariants with the code — don't just transcribe. When you record or carry forward an invariant, verify it against what the code actually does. If they contradict, surface it rather than writing the stale claim: "the
CONTEXT says Orders cancel whole, but the code cancels line items — which is right?" A reconciled doc that quietly disagrees with the code is worse than no doc.
- CLAUDE.md — if a new top-level convention emerged, or a new module belongs in the module map (one line + a link to the module's
CONTEXT.md).
- docs/adr/ — for each decision flagged as an ADR candidate (in
STATE.md's findings) that meets the three criteria in references/adr-format.md (hard to reverse · surprising without context · real trade-off), offer to write the ADR. The user approves before you write. Number sequentially: rescan docs/adr/ for the highest existing number rather than assuming one — /dobby:address-review also writes sequential ADRs into this directory (0001 = the Conductor execution host).
Step 3: Evaluate a reusable skill
If the work surfaced a replicable project pattern, convention, or gotcha a future task would repeat, evaluate distilling it into a skill (project scope) via /dobby:create-skill. Offer it; the user approves before you create. Skip if it already fits an existing skill, CLAUDE.md, or CONTEXT.md.
Step 4: Dispose and hand off
The durable bits now live in CONTEXT.md / CLAUDE.md / docs/adr/. Delete the ephemeral STATE.md. Present a final summary (what shipped, decisions, docs updated, deferred items). Do NOT commit — hand off to /dobby:commit when the user is ready.
Next step
The session is wrapped. Present the next stage as an AskUserQuestion — one question that restates wrap just finished — with the options below (recommended first, then Stop here). On the user's selection, invoke the chosen /dobby:<skill> via the Skill tool; "Stop here" ends the turn (commit later).
/dobby:commit (Recommended) — sync docs, commit, push, open the PR.- Stop here — commit later.
Language
Interact with the user in their language. Write docs / ADRs / CONTEXT in English; keep domain glossary terms in their real-world form and user-facing UI strings in the product's language.
Acceptance checklist
