@chamba/claude-extras 0.4.0 → 0.5.1

package/README.md

@@ -159,11 +159,20 @@ 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,
+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 → 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 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.
 

package/assets/agents/reviewer.md

@@ -12,7 +12,12 @@ risky assumptions, scope that's too big for one pass.
 
 When reviewing a diff, check for: correctness bugs, missing tests, unhandled
 errors, security/permissions issues, and anything that violates the project's
-stated conventions.
+stated conventions. When the diff **deletes** code, also check referential
+closure both ways: nothing still references what was removed (forward), and
+nothing the removal orphaned is left behind — now-unused exports, helpers or
+imports whose only caller is gone (backward). A token grep misses orphans whose
+name doesn't contain the deleted symbol; lean on the build/typechecker and a
+dead-code check, not just grep.
 
 Output a verdict (`approved` or `changes requested`) followed by a concise,
 prioritized list of concrete issues. Do not rewrite the code yourself — describe

package/assets/commands/ticket.md

@@ -1,6 +1,6 @@
 ---
 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,
@@ -8,26 +8,66 @@ 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.
 
-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.
+**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.
+
+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.
-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. If I
-   named repos in the arguments, use exactly those; otherwise infer the set from the
-   ticket + the workspace map. If anything is ambiguous, list it as an assumption —
-   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.
+   and what each one is) + relevant Obsidian notes + each repo's coding rules.
+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 skip to 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. List ambiguities as assumptions — 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. 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
    (in that repo's worktree) and the tests to the **tester** subagent; run them.
-6. Call `chamba_summarize_to_vault` with a summary of what changed.
-7. STOP and report for my review: the repos touched and why; per repo, what changed
-   and the test results; the `.code-workspace` to open; and the suggested commit +
-   `git merge --no-ff` commands. Do NOT commit, merge or push — I review, commit and
-   send to my company's code review by hand.
+6. **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,
+   and a dead-code check if the repo has one (knip, ts-prune). Token grep alone
+   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:
+   - the repos touched and why;
+   - per repo, what changed and the test + verify results;
+   - an **acceptance-criteria checklist**: every AC of the ticket marked
+     **Delivered** or **Not delivered**. Anything the plan marked
+     **needs-approval**, or any AC you could not deliver without a deferred
+     decision, goes under **"Needs your decision"** with what's pending and why —
+     never omit it;
+   - the `.code-workspace` to open, and the suggested commit +
+     `git merge --no-ff` commands.
+   Do NOT commit, merge or push — I review, commit and send to my company's code
+   review by hand.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chamba/claude-extras",
-  "version": "0.4.0",
+  "version": "0.5.1",
   "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.4.0",
-    "@chamba/core": "0.4.0"
+    "@chamba/adapters": "0.5.1",
+    "@chamba/core": "0.5.1"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",