@chamba/claude-extras 0.5.0 → 0.5.2

package/README.md

@@ -159,13 +159,23 @@ Then, in Claude Code:
 /ticket TICKET-123
 ```
 
-`/ticket` runs the full orchestrator-worker flow: create worktrees →
-`chamba_load_context` → delegate the plan to the **planner** subagent →
-`chamba_review_plan` + the **reviewer** subagent → delegate code to **implementer** and
-tests to **tester** (all inside the worktrees) → `chamba_summarize_to_vault`. It runs to
-the end and stops for your review. It **never commits, merges or pushes** — you review,
-commit and send to code review by hand. Each worker runs with the model + effort you
-configured above.
+If you already wrote a plan (in plan mode, exported to a `.md`, or by hand), reuse it and
+skip the planning step:
+
+```
+/ticket -p ./plans/TICKET-123.md TICKET-123
+```
+
+`/ticket` runs the full orchestrator-worker flow: `chamba_load_context` → delegate the
+plan to the **planner** subagent (or, with `-p <plan-path>`, read your plan and skip
+this) → `chamba_review_plan` + the **reviewer** subagent → **ask you any open questions
+the plan left unresolved**, fold in your answers → create worktrees only for the repos
+the plan touches → delegate code to **implementer** and tests to **tester** (all inside
+the worktrees) → verify the real diff (referential closure + build/typecheck) →
+`chamba_summarize_to_vault`. It clarifies once up front, then runs to the end and stops
+for your review with an acceptance-criteria checklist. It **never commits, merges or
+pushes** — you review, commit and send to code review by hand. Each worker runs with the
+model + effort you configured above.
 
 > **Security:** `copyEnvFiles` copies secrets into the worktree directories. Add your
 > `worktrees.root` (e.g. `WORKTREES/`) to `.gitignore` so they're never committed. It's

package/assets/agents/planner.md

@@ -11,8 +11,15 @@ map + relevant notes). Produce a concrete, reviewable plan — do not write code
 - State explicit acceptance criteria and how they'll be verified (tests).
 - Call out risks and any sensitive areas (auth, payments, migrations, data).
 - Keep it tight and concrete enough that an implementer can execute it without
-  guessing. If the ticket is ambiguous, state the assumptions you made instead of
-  inventing scope.
+  guessing.
+- Separate what you can decide from what you can't. Assumptions you're confident
+  in: state them as assumptions and move on. Genuine forks that change scope or
+  behaviour, or product decisions only the human can make: put them under a
+  `## Open questions` section, each as a specific question a one-line answer
+  resolves. Only list questions that would actually change the plan — not
+  implementation details the implementer can settle. Never invent scope to paper
+  over them.
 
 Return the plan as structured markdown. The orchestrator runs it through
-`chamba_review_plan` and the reviewer subagent before any code is written.
+`chamba_review_plan` and the reviewer subagent, then resolves any `## Open
+questions` with the human, before any code is written.

package/assets/commands/ticket.md

@@ -1,41 +1,64 @@
 ---
 description: Resolve a ticket end-to-end in isolated worktrees, delegating to chamba's agents
-argument-hint: <ticket> [repo ...]
+argument-hint: "[-p <plan-path>] <ticket> [repo ...]"
 ---
 
 You are orchestrating ticket **$ARGUMENTS** end-to-end. chamba provides context,
 plan validation, worktrees and vault memory; you delegate the thinking and the
-code to the configured subagents. **Run to the end and stop only for my final
-review** — do not pause for approval mid-way.
+code to the configured subagents.
 
-**One exception to running autonomously:** the plan itself may mark an item as
-needing my approval (scope expansion beyond the ticket, a destructive or
-irreversible change, a product decision you can't make). You do NOT act on those.
-You complete everything else and surface them at the final gate. Autonomy is
-bounded by the plan's gates — it must never silently drop an acceptance criterion.
+**Clarify once, up front; then run to the end.** There is exactly one point where
+you may pause: once the plan is ready, if it has unresolved open questions or
+decisions only I can make, ask me, fold my answers into the plan, and continue.
+After that, run to the end and stop only for my final review — do not pause again
+mid-way. You never resolve a flagged decision on your own and never silently drop
+an acceptance criterion.
 
-The first token of the arguments is the ticket id; any further tokens are repos I
-named explicitly. Analyze first, create worktrees only for the repos actually
-touched — do not create a worktree for every repo in the workspace.
+Parse the arguments first. If they start with `-p` or `--plan`, the next token is
+the path to a plan I already wrote (relative to the workspace root, or absolute) —
+read it and skip planning (see step 2). The first non-flag token is the ticket id;
+any tokens after it are repos I named explicitly. Analyze first, create worktrees
+only for the repos actually touched — do not create a worktree for every repo in
+the workspace.
 
 1. Call `chamba_load_context` with the ticket to pull the workspace map (all repos
    and what each one is) + relevant Obsidian notes + each repo's coding rules.
-2. Delegate to the **planner** subagent to produce the plan. The plan MUST state
-   **which repos the ticket touches and why**, with subtasks grouped per repo, and
-   it MUST map **every acceptance criterion of the ticket** to a subtask. If an AC
-   needs a decision you can't make autonomously, the plan marks it
-   **needs-approval** — that is a hard gate, not something to resolve on your own.
-   If I named repos in the arguments, use exactly those; otherwise infer the set
-   from the ticket + the workspace map. List ambiguities as assumptions — do not
-   invent scope.
-3. Run the plan through `chamba_review_plan` and have the **reviewer** subagent
-   audit it. Fix and re-review until approved (max 3 rounds). Do NOT stop to ask me.
-4. Create isolated worktrees ONLY for the repos the plan identified: call
+2. Obtain the plan:
+   - **If I passed `-p <plan-path>` and the file exists:** read it and use it as
+     THE plan — do NOT delegate to the planner. Run it through `chamba_review_plan`
+     to sanity-check structure and surface issues, but do NOT bring in the reviewer
+     subagent to rewrite it (I already approved this plan). If the plan doesn't
+     cover a ticket acceptance criterion, or fails to mark a risky item
+     **needs-approval**, note it as a gap and carry it to the final report — don't
+     invent scope to fill it. Then continue to the clarification gate (step 4).
+   - **If `-p` was given but the file does not exist:** tell me you couldn't find
+     it, then fall back to generating the plan (next bullet).
+   - **Otherwise (no `-p`):** delegate to the **planner** subagent to produce the
+     plan, then continue to step 3.
+   Either way the plan MUST state **which repos the ticket touches and why**, with
+   subtasks grouped per repo, and map **every acceptance criterion of the ticket**
+   to a subtask. Items needing a decision you can't make autonomously are marked
+   **needs-approval** — a hard gate, not something to resolve on your own. If I
+   named repos in the arguments, use exactly those; otherwise infer the set from
+   the plan + the workspace map. State confident assumptions as assumptions and put
+   genuine forks under **Open questions** — do not invent scope.
+3. (Skip when the plan came from `-p` — already checked in step 2.) Run the plan
+   through `chamba_review_plan` and have the **reviewer** subagent audit it. Fix
+   and re-review until approved (max 3 rounds). Do NOT stop to ask me.
+4. **Clarification gate.** Before creating any worktree, check the plan for
+   unresolved **Open questions** and any item marked **needs-approval**;
+   `chamba_review_plan` flags these as `unresolved-open-questions`. If there are
+   any: ask me all of them in one concise batch, wait for my answers, fold them
+   into the plan (adjust scope, subtasks and acceptance criteria as needed), and
+   only then continue. If the plan has none, proceed without pausing. This is the
+   only place you stop before the final review — it applies whether the plan came
+   from the planner or from `-p`.
+5. Create isolated worktrees ONLY for the repos the plan identified: call
    `chamba_create_worktrees` with the ticket and that repo list. ALL work happens
    inside these worktrees — never edit the main checkouts.
-5. For each subtask/repo, delegate implementation to the **implementer** subagent
+6. For each subtask/repo, delegate implementation to the **implementer** subagent
    (in that repo's worktree) and the tests to the **tester** subagent; run them.
-6. **Verify against the real diff** (not the plan). For each touched repo: have the
+7. **Verify against the real diff** (not the plan). For each touched repo: have the
    **reviewer** subagent audit the actual diff for correctness, missing tests, and
    **referential closure** — anything the change deleted must leave no orphaned
    callers and no now-unused exports. Then run that repo's build / typecheck / lint,
@@ -43,8 +66,8 @@ touched — do not create a worktree for every repo in the workspace.
    misses orphans whose name doesn't contain the deleted symbol — rely on the
    build/typechecker/dead-code tool, not just grep. Fix what comes back, then
    re-verify (max 3 rounds).
-7. Call `chamba_summarize_to_vault` with a summary of what changed.
-8. STOP and report for my review. The report MUST include:
+8. Call `chamba_summarize_to_vault` with a summary of what changed.
+9. STOP and report for my review. The report MUST include:
    - the repos touched and why;
    - per repo, what changed and the test + verify results;
    - an **acceptance-criteria checklist**: every AC of the ticket marked

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chamba/claude-extras",
-  "version": "0.5.0",
+  "version": "0.5.2",
   "description": "Optional Claude Code extras for chamba: slash commands, subagents and hooks installer",
   "license": "MIT",
   "type": "module",
@@ -31,8 +31,8 @@
   ],
   "dependencies": {
     "@inquirer/prompts": "^7.0.0",
-    "@chamba/adapters": "0.5.0",
-    "@chamba/core": "0.5.0"
+    "@chamba/core": "0.5.2",
+    "@chamba/adapters": "0.5.2"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",