@chris1807/claude-kit 2.1.33 → 2.1.34

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.33",
+  "version": "2.1.34",
   "description": "Claude Code starter kit for Azure DevOps teams — agents, hooks, MCP servers, slash commands, and end-to-end work item → PR → release → deploy workflow automation",
   "type": "module",
   "bin": {

package/templates/commands/deep-review.md

@@ -40,6 +40,26 @@ Unlike `/review`, this command works against the real working tree so it can bui
 
 If checkout fails (branch deleted after merge, etc.), tell the user and offer to fall back to a diff-only review (the `/review` behavior) instead.
 
+### Effort gate — before the deep analysis (Steps 3–8)
+
+Reasoning effort is a harness setting the user controls; this command cannot change it. `/deep-review` is the exhaustive, checkout-based review, so its analysis is heavy by nature — bias the recommendation upward. Rubric:
+
+| Effort | When |
+|--------|------|
+| `high` | A focused PR — small diff, few subsystems, straightforward acceptance criteria. The floor for this command. |
+| `xhigh` | The common case for a deep review — a real feature diff, several subsystems or acceptance criteria, regressions to reason about. Recommend this by default. |
+| `max` | Large, security-critical, or architecturally risky PRs where you want maximum scrutiny. Session-only. |
+
+Signals: files changed (from the confirmation above), acceptance-criteria count, number of subsystems touched, and whether the code is security- or data-integrity-sensitive. Present:
+
+```
+Suggested reasoning effort for this deep review: **{level}** — {one-line justification}.
+Effort is set by you, not me. Run `/effort` to adjust if needed, then reply **ready** —
+or reply **go** to proceed at your current level.
+```
+
+**Wait for `ready` or `go` before launching the Step 3 workflow.** Never try to set the effort level yourself; only recommend it.
+
 ## Step 3: Detect Rework Context — do this BEFORE judging acceptance criteria
 
 A small diff does not mean a small feature. The PR you are reviewing may be a rework that only addresses targeted feedback, while the bulk of the implementation already shipped in earlier PRs. Judging acceptance criteria against the current diff alone will produce false "not met" findings.

package/templates/commands/fix-review.md

@@ -41,6 +41,27 @@ For each flagged item, capture:
 
 If there are zero qualifying threads, tell the user `No open reviewer feedback on PR #{id}.` and stop.
 
+### Effort gate — before planning and applying fixes (Steps 4–5)
+
+Reasoning effort is a harness setting the user controls; this command cannot change it. Recommend a level based on the flagged items you just collected, then let the user set it. Rubric (the session default is usually `high`):
+
+| Effort | When |
+|--------|------|
+| `medium` | A short list of low-severity, mechanical fixes (renames, nits, one or two obvious changes). |
+| `high` | The common case — a mix of warnings and a few criticals across several files. Recommend this unless clearly lighter or heavier. |
+| `xhigh` | Many findings, multiple critical issues, or fixes that touch subtle logic / span subsystems and risk regressions. |
+| `max` | Exceptional: a critical finding that requires a genuine rethink or security-critical fix. Session-only. |
+
+Signals: total flagged-item count and the severity mix (how many critical), plus whether the fixes concentrate in tricky code. Present:
+
+```
+Suggested reasoning effort for these fixes: **{level}** — {one-line justification citing the counts}.
+Effort is set by you, not me. Run `/effort` to adjust if needed, then reply **ready** —
+or reply **go** to proceed at your current level.
+```
+
+**Wait for `ready` or `go` before switching branches and planning.** Never try to set the effort level yourself; only recommend it.
+
 ## Step 3: Switch to the PR Branch
 
 Before reading code or proposing fixes, make sure local state matches the PR:

package/templates/commands/implement.md

@@ -34,6 +34,19 @@ Read the work item comments via `wit_list_work_item_comments`. Comments often co
 
 ## Step 2: Summarize and Confirm
 
+### Assess reasoning effort
+
+Reasoning effort is a **harness setting the user controls** — this command cannot change it, and no prompt or hook can. Your job is to *recommend* a level; the user applies it (via `/effort`) before the heavy work in Steps 3–8 runs. Base the recommendation on the work item's scope using this rubric (the session default is usually `high`):
+
+| Effort | When |
+|--------|------|
+| `medium` | Trivial / mechanical: single-file or config change, copy tweak, one obvious fix. |
+| `high` | Standard work: cross-layer change, a handful of files, normal test + review load. Recommend this unless the work is clearly lighter or heavier. |
+| `xhigh` | Heavy: multi-subsystem or full-stack change, many acceptance criteria, subtle logic, tricky regressions, or ambiguous requirements. |
+| `max` | Exceptional: genuinely novel design, security-critical, or high-uncertainty work. Session-only. |
+
+Concrete signals for this command: number of subsystems/layers touched, acceptance-criteria count, and how much is net-new logic vs. following an existing pattern.
+
 Present a summary of the work item to the user:
 
 ```
@@ -51,10 +64,15 @@ Present a summary of the work item to the user:
 
 Does this look correct? Do you have any additional context or requirements?
 
+**Suggested reasoning effort: {level}** — {one-line justification citing the signals above}.
+Effort is set by you, not me. If your current level differs, run `/effort` to adjust before replying.
+
 Use **Ultracode effort** for this run? Ultracode fans out exploration, AC-coverage checks, and code review across parallel agents — more thorough, but slower and more token-hungry. (yes / no — suggested: {yes for multi-subsystem / multi-AC work, no for trivial changes})
+
+Reply with your Ultracode choice (and any added context). Say **ready** once your effort level is set, or **go** to proceed at your current level.
 ```
 
-**Wait for the user to respond.** Do NOT proceed until the user confirms or provides additional context. If they add context, incorporate it into the plan. Record the Ultracode answer — it governs whether the `Workflow` fan-outs in Steps 3, 7, and 8 run at all.
+**Wait for the user to respond.** Do NOT proceed until the user confirms or replies `ready`/`go`. If they add context, incorporate it into the plan. Record the Ultracode answer — it governs whether the `Workflow` fan-outs in Steps 3, 7, and 8 run at all. Never try to set the effort level yourself; only recommend it.
 
 ## Step 3: Explore & Plan
 

package/templates/commands/plan-backlog.md

@@ -1,6 +1,6 @@
-Sweep an Azure DevOps backlog for Dev Ready user stories without child tasks and propose a per-story task breakdown with hour estimates. Usage: `/plan-backlog [project]`
+Sweep an Azure DevOps backlog for Dev Ready user stories without child tasks and propose a single implementation task per story with an hour estimate. Usage: `/plan-backlog [project]`
 
-This command walks the **backlog** of a chosen Azure DevOps project (work items not assigned to any sprint), finds user stories that are **Dev Ready**, **have Story Points**, and **have no child tasks yet**, and — story by story — proposes a tailored Task breakdown with hour estimates for the user to approve before any work items are created.
+This command walks the **backlog** of a chosen Azure DevOps project (work items not assigned to any sprint), finds user stories that are **Dev Ready**, **have Story Points**, and **have no child tasks yet**, and — story by story — proposes **one child Task** with an hour estimate for the user to approve before any work items are created. Exactly one task per story — never a multi-task breakdown.
 
 Treat `$ARGUMENTS` as an optional project name (e.g. `/plan-backlog CSI Development`). If provided, skip the project prompt in Step 1.
 
@@ -81,8 +81,8 @@ Found {n} Dev Ready stories with Story Points and no child tasks on the {project
 | 3  | AB#4530  | COM - Dashboard trend graphs             |   3    |
 | .. | ...      | ...                                      |  ...   |
 
-I'll walk through each one. For each story you'll see a proposed task list
-with hours; you can approve, edit, or skip per story.
+I'll walk through each one. For each story you'll see one proposed task
+with an hour estimate; you can approve, edit, or skip per story.
 
 Continue? (yes / cancel)
 ```
@@ -93,18 +93,18 @@ Continue? (yes / cancel)
 
 Only when **ultracode is on** (a system-reminder confirms it, or the user typed `ultracode`): the analysis in 5a–5c is independent per story, so pre-compute all proposals in parallel with the `Workflow` tool instead of analyzing one story at a time.
 
-- Fan out **one agent per story** that does 5a–5c — re-read the story, map points → budget, tailor the task list — and returns a structured proposal (story id, points, budget, and the list of `{title, hours}` tasks). Use a `schema` so each agent returns validated JSON.
-- Then run Step 5's loop **using the pre-computed proposals** — but keep 5d (approval) and 5e (creation) exactly as written: present each proposal, wait for `yes / edit / skip / cancel-all`, and create tasks only after approval. **Never fan out the approval or the work-item creation** — those stay sequential and interactive.
+- Fan out **one agent per story** that does 5a–5c — re-read the story, map points → budget, draft the single task — and returns a structured proposal (story id, points, budget, and one `{title, hours}` task). Use a `schema` so each agent returns validated JSON.
+- Then run Step 5's loop **using the pre-computed proposals** — but keep 5d (approval) and 5e (creation) exactly as written: present each proposal, wait for `yes / edit / skip / cancel-all`, and create the task only after approval. **Never fan out the approval or the work-item creation** — those stay sequential and interactive.
 
 If ultracode is off, ignore this and run Step 5 the normal sequential way. The output is identical either way; ultracode only makes the analysis faster for large backlogs.
 
-## Step 5: Per-Story Task Breakdown (loop)
+## Step 5: Per-Story Task (loop)
 
 For each remaining story, in order:
 
 ### 5a. Re-read the story in full
 
-Fetch the work item again (Description and Acceptance Criteria fields) if not already cached. You need the AC text to tailor the task list.
+Fetch the work item again (Description and Acceptance Criteria fields) if not already cached. You need the AC text to write an accurate task title.
 
 ### 5b. Map Story Points → total hour budget
 
@@ -124,64 +124,39 @@ Use this mapping (calibrated for a senior developer at ~6 productive hours per d
 
 If the points value isn't on the Fibonacci scale, round to the nearest entry above. If the story has tags like `spike`, `research`, or `unknown-stack`, add 20–30% on top — those are the cases where seniority doesn't help.
 
-### 5c. Tailor the task list (hybrid template)
+### 5c. Draft the single task
 
-Start from this template, then **add, remove, or rename** tasks based on what the AC actually describes:
+Create **exactly one task** covering all the work for the story — implementation, tests, code review revisions, and UAT support are all rolled into it. Do not split the story into design/backend/frontend/test tasks.
 
-| Default task           | When to include                                          |
-|------------------------|----------------------------------------------------------|
-| Design / Spike         | AC has open questions or the implementation isn't obvious |
-| Backend implementation | AC mentions API, service, job, persistence, or data flow |
-| Frontend implementation| AC mentions UI, screen, form, button, or workflow         |
-| Database / migration   | AC requires schema changes or data backfill              |
-| Automated tests        | Always include unless the story is purely a config tweak |
-| Code review revisions  | Always include                                           |
-| UAT support            | Always include unless explicitly out of scope            |
-
-Distribute the hour budget across the chosen tasks. Reasonable defaults:
-
-- Code review revisions: ~10% of budget (min 1 hr)
-- UAT support: ~10% of budget (min 1 hr)
-- Automated tests: ~15–25% of budget
-- Design / Spike (if present): ~10–20% of budget
-- Remaining hours split across implementation tasks based on the AC
-
-Round each task to a whole hour. Final total should equal the budget (give or take 1 hr from rounding).
+- **Title**: `{Prefix} - Implement: {short summary of the story}` — use the same product prefix as the parent (e.g. `COM`, `PAY`, `CDA`), extracted from the parent's title.
+- **Hours**: the full hour budget from 5b, rounded to a whole hour.
 
 ### 5d. Show the proposal
 
 ```
 ─────────────────────────────────────────────────────────────
-AB#{id}: {title}      ({points} pts → {budget} hrs total)
+AB#{id}: {title}      ({points} pts → {budget} hrs)
 ─────────────────────────────────────────────────────────────
 
-Proposed child tasks:
+Proposed child task:
 
-| # | Task title                                    | Hours |
-|---|-----------------------------------------------|-------|
-| 1 | {Prefix} - Design: clarify export field set   |   3   |
-| 2 | {Prefix} - Backend: CSV export endpoint       |   8   |
-| 3 | {Prefix} - Frontend: export button + download |   6   |
-| 4 | {Prefix} - Tests: export endpoint + UI        |   4   |
-| 5 | {Prefix} - Code review revisions              |   2   |
-| 6 | {Prefix} - UAT support                        |   1   |
-|   | **Total**                                     | **24**|
+| Task title                                     | Hours |
+|------------------------------------------------|-------|
+| {Prefix} - Implement: payments CSV export      |  24   |
 
 Approve? (yes / edit / skip / cancel-all)
 ```
 
-Task titles use the same product prefix as the parent (e.g. `COM`, `PAY`, `CDA`) — extract it from the parent's title. Use the format `{Prefix} - {what the task does}`.
-
 **Wait for the user.**
 
-- `yes` → proceed to 5e (create the tasks)
-- `edit` → ask which row to change (title or hours), revise, re-show the table, ask again
+- `yes` → proceed to 5e (create the task)
+- `edit` → ask what to change (title or hours), revise, re-show, ask again
 - `skip` → skip this story, move to the next; record it as skipped
 - `cancel-all` → stop the entire loop with no further changes. Report what was already created.
 
-### 5e. Create the child tasks
+### 5e. Create the child task
 
-For each approved task, call `mcp__azure-devops__wit_create_work_item` with:
+Create the approved task with `mcp__azure-devops__wit_create_work_item`:
 
 - **project**: the chosen project
 - **workItemType**: `Task`
@@ -195,12 +170,12 @@ For each approved task, call `mcp__azure-devops__wit_create_work_item` with:
 
 Then link the new task as a child of the parent with `mcp__azure-devops__wit_add_child_work_items` (or fall back to `wit_work_items_link` with link type `System.LinkTypes.Hierarchy-Forward` from parent → task).
 
-If any create or link call fails, report the failure for that task, stop creating tasks for this story, and ask the user whether to continue with the next story or abort the loop.
+If the create or link call fails, report the failure and ask the user whether to continue with the next story or abort the loop.
 
 ### 5f. Confirm per-story result
 
 ```
-✓ AB#{id}: created {k} child tasks ({budget} hrs total)
+✓ AB#{id}: created 1 child task ({budget} hrs)
 ```
 
 Then move to the next story.
@@ -213,14 +188,14 @@ Once the loop ends (all stories handled, or user said `cancel-all`):
 ## Backlog Planning Complete — {project}
 
 Stories planned:    {n_planned}
-  ✓ Tasks created:  {n_tasks_total} ({hours_total} hrs)
+  ✓ Tasks created:  {n_tasks_total} — one per story ({hours_total} hrs)
 Stories skipped:    {n_skipped}
   - already had tasks: {n_existing}
   - user skipped:      {n_user_skipped}
 
 Planned stories:
-- AB#4521: 6 tasks, 24 hrs
-- AB#4530: 4 tasks, 14 hrs
+- AB#4521: 1 task, 24 hrs
+- AB#4530: 1 task, 14 hrs
 - ...
 
 Next steps:

package/templates/commands/review.md

@@ -4,6 +4,25 @@ Review PR #$ARGUMENTS in the current project. Automatically:
 
 2. **Read the linked work item** and gather the full acceptance criteria.
 
+   **Effort gate — do this before the review reasoning (steps 3+).** Reasoning effort is a harness setting the user controls; this command cannot change it. Recommend a level based on the diff you just read, then let the user set it. Rubric (the session default is usually `high`):
+
+   | Effort | When |
+   |--------|------|
+   | `medium` | Small diff — a few files, mechanical or well-scoped change, short AC list. |
+   | `high` | Standard PR — cross-layer diff, a handful of files, a normal AC set. Recommend this unless clearly lighter or heavier. |
+   | `xhigh` | Large or subtle diff — many files/subsystems, many acceptance criteria, security-sensitive or concurrency-heavy code. |
+   | `max` | Exceptional: security-critical or architecturally risky change where you want maximum scrutiny. Session-only. |
+
+   Signals: files changed, additions/deletions, acceptance-criteria count, and whether the diff touches security- or data-integrity-sensitive code. Present:
+
+   ```
+   Suggested reasoning effort for this review: **{level}** — {one-line justification}.
+   Effort is set by you, not me. Run `/effort` to adjust if needed, then reply **ready** —
+   or reply **go** to review at your current level.
+   ```
+
+   **Wait for `ready` or `go` before continuing.** Never try to set the effort level yourself; only recommend it.
+
 3. **Detect rework context — do this BEFORE judging acceptance criteria.**
 
    A small diff does not mean a small feature. The PR you are reviewing may be a rework that only addresses targeted feedback, while the bulk of the implementation already shipped in earlier PRs. Judging acceptance criteria against the current diff alone will produce false "not met" findings.

package/templates/commands/rework.md

@@ -53,6 +53,19 @@ Regardless of whether description/acceptance criteria changed, **always read the
 
 ## Step 3: Summarize Rework and Confirm
 
+### Assess reasoning effort
+
+Reasoning effort is a **harness setting the user controls** — this command cannot change it, and no prompt or hook can. Recommend a level; the user applies it (via `/effort`) before the rework in Steps 4–10 runs. Base it on the rework's scope using this rubric (the session default is usually `high`):
+
+| Effort | When |
+|--------|------|
+| `medium` | A small targeted fix: one or two files, a single low-risk feedback item. |
+| `high` | Standard rework: a handful of files, a few feedback items across a layer or two. Recommend this unless clearly lighter or heavier. |
+| `xhigh` | Heavy rework: multi-subsystem changes, many feedback items / ACs, subtle regressions, or ambiguous feedback. |
+| `max` | Exceptional: the feedback exposes a design flaw needing a rethink, or security-critical work. Session-only. |
+
+Concrete signals for this command: number of feedback items, how many ACs they map to, and how many subsystems the fixes touch.
+
 Present a summary of the rework feedback to the user. **Every feedback item must be mapped to an Acceptance Criterion** — if a feedback item doesn't map to any AC, flag it explicitly as either (a) implied by an AC that's worded too loosely or (b) scope-creep that should be a separate work item.
 
 ```
@@ -78,10 +91,15 @@ Present a summary of the rework feedback to the user. **Every feedback item must
 
 Does this capture the rework correctly? Any feedback items that should be flagged as scope-creep (separate work item) instead of being addressed here?
 
+**Suggested reasoning effort: {level}** — {one-line justification citing the signals above}.
+Effort is set by you, not me. If your current level differs, run `/effort` to adjust before replying.
+
 Use **Ultracode effort** for this rework? Ultracode fans out exploration, AC-coverage checks, and code review across parallel agents — more thorough, but slower and more token-hungry. (yes / no — suggested: {yes for multi-file / multi-AC rework, no for a small targeted fix})
+
+Reply with your Ultracode choice (and any reclassifications or context). Say **ready** once your effort level is set, or **go** to proceed at your current level.
 ```
 
-**Wait for the user to respond.** Do NOT proceed until the user confirms the AC mapping. Record the Ultracode answer — it governs whether the `Workflow` fan-outs in Steps 4, 9, and 10 run at all. If they reclassify any item as scope-creep, drop it from the plan and note it in the final summary. If they add context, incorporate it.
+**Wait for the user to respond.** Do NOT proceed until the user confirms the AC mapping and replies `ready`/`go`. Record the Ultracode answer — it governs whether the `Workflow` fan-outs in Steps 4, 9, and 10 run at all. If they reclassify any item as scope-creep, drop it from the plan and note it in the final summary. If they add context, incorporate it. Never try to set the effort level yourself; only recommend it.
 
 ## Step 4: Explore & Plan