@chris1807/claude-kit 2.1.33 → 2.1.35

package/README.md

@@ -277,6 +277,8 @@ Claude automatically:
 8. **Pauses for you to manually test**
 9. Creates the PR after you confirm
 
+**Implementing a whole Feature:** point `/implement` at a Feature work item and it implements the child User Stories in waves driven by the `Custom.Order` field — stories with the same order value are implemented in parallel (one agent per story, each in an isolated git worktree), and the next order value starts only after the previous wave is merged and green. Everything lands on one `feature/` branch with a single review, UAT pass, and PR that links every story.
+
 ### Review a Pull Request
 
 ```
@@ -630,7 +632,7 @@ Claude reviews for:
 
 | Command | Usage | What It Does |
 |---------|-------|-------------|
-| `/implement` | `/implement AB#1234` | Read work item → summarize → approve plan → implement → quality checks → UAT → PR |
+| `/implement` | `/implement AB#1234` | Read work item → summarize → approve plan → implement → quality checks → UAT → PR. On a Feature: implements child stories in `Custom.Order` waves, same-order stories in parallel |
 | `/review` | `/review 142` | Full code review on a PR with inline comments |
 | `/deep-review` | `/deep-review 142` | Deep, Ultracode-orchestrated review: checks out the branch, builds/tests it, verifies every requirement, checks for regressions, flags out-of-scope changes, then comments + votes |
 | `/resolve-feedback` | `/resolve-feedback 142` | Address unresolved PR comment threads, push fixes, reply + resolve threads |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.33",
+  "version": "2.1.35",
   "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

@@ -24,6 +24,8 @@ Read the work item from Azure DevOps via MCP. Extract:
 
 Handle `$ARGUMENTS` as either `1234` or `AB#1234` — strip the `AB#` prefix when calling the MCP API.
 
+**If `System.WorkItemType` is `Feature`, switch to the [Feature Workflow](#feature-workflow-ordered-story-waves) at the bottom of this document.** Steps 2–10 below describe the single-work-item flow; the Feature Workflow reuses them per child User Story.
+
 ### Embedded Images
 
 The description and acceptance criteria fields may contain embedded images (screenshots, mockups, diagrams). These are typically `<img>` tags with `src` URLs pointing to Azure DevOps attachments. **Download and view every embedded image** using WebFetch — they often contain critical visual requirements (UI layouts, expected behavior, error states) that are not described in the text.
@@ -34,6 +36,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 +66,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
 
@@ -308,3 +328,89 @@ Once the user has answered, update each task via `wit_update_work_item`:
 - `System.State` → `Closed` (fall back to `Done` if the project's task template uses Agile; warn if neither is valid)
 
 Confirm with a summary line per task: `Closed AB#xxxx — {hours}h logged`.
+
+## Feature Workflow (ordered story waves)
+
+Used when the work item passed to `/implement` is a **Feature**. The Feature's child User Stories are implemented in **waves** driven by the custom order field (`Custom.Order`): all stories sharing the same order value run **in parallel** (one implementation agent each), and waves run sequentially in ascending order — wave 2 starts only after wave 1 is merged, built, and green, so later stories can build on earlier ones.
+
+The single-work-item gates still exist, but they are **batched per wave** so parallel agents never have to prompt the user: one confirmation for the whole feature, one plan approval per wave, one review/UAT/PR cycle for the feature.
+
+### F1: Load Child Stories and Build Waves
+
+1. Fetch the Feature with `expand: Relations` (Step 1 rules apply — description, embedded images, comments).
+2. Collect children (`System.LinkTypes.Hierarchy-Forward`) and fetch them via `wit_work_item` `get_batch` with fields: `System.Id`, `System.Title`, `System.State`, `System.WorkItemType`, `System.AssignedTo`, `Custom.Order`, `Microsoft.VSTS.Scheduling.StoryPoints`.
+3. Keep children of type **User Story** or **Bug** that are not already `Closed`, `Resolved`, or `Removed`. List anything skipped (and why) in the F2 summary.
+4. Group the remaining stories by `Custom.Order` ascending — each distinct value is one **wave**. Stories with equal order values share a wave and run in parallel.
+5. Stories with **no** `Custom.Order` value form a final catch-all wave — flag them in F2 so the user can either accept that placement or set order values in Azure DevOps and re-run.
+6. Read each story fully per Step 1 (description, acceptance criteria, embedded images, comments).
+
+If the Feature has **no** implementable child stories, stop and tell the user; offer to implement the Feature itself via the standard single-work-item flow (Steps 2–10) if its own description/AC support that.
+
+### F2: Summarize and Confirm (one gate for the whole Feature)
+
+Present the Feature summary plus the wave plan:
+
+```
+## AB#{feature-id}: {feature title} (Feature)
+
+**State:** {state}    **Child stories:** {n} implementable ({m} skipped: {ids + reason})
+
+### Description
+{feature description summary}
+
+### Execution Waves (Custom.Order)
+
+| Wave | Order | Story | Title | Points | State |
+|------|-------|-------|-------|--------|-------|
+| 1 | 1 | AB#6242 | ... | 3 | Dev Ready |
+| 1 | 1 | AB#6243 | ... | 2 | Dev Ready |
+| 2 | 2 | AB#6244 | ... | 5 | Dev Ready |
+| 3 | — | AB#6245 | ... | 3 | Dev Ready |  ← no Custom.Order set; runs last
+
+Stories in the same wave are implemented in parallel; waves run in order.
+
+Does this look correct? Any stories to skip, reorder, or context to add?
+```
+
+Include the Step 2 reasoning-effort recommendation (a multi-story Feature is almost always `xhigh`) and the **single** Ultracode question — the answer applies to every story in the run. **Wait for the user** exactly as in Step 2.
+
+### F3: Create the Feature Branch
+
+Capture `BASE_BRANCH` and create `feature/AB#{feature-id}-{sanitized-title}` per Step 4 rules. All story work merges into this branch; the single PR in F7 targets `BASE_BRANCH`.
+
+### F4: Execute Waves
+
+For each wave in ascending order:
+
+1. **Explore & plan** each story in the wave (Step 3 rules; Ultracode fan-outs apply per story if opted in). Present **one combined plan** with a section per story — each section covering approach, files, unit tests, and agents — plus a note on any files touched by more than one story in the wave (a conflict warning). **One approval gate per wave**; wait for the user.
+2. **Implement:**
+   - **Single-story wave** → implement directly on the feature branch in the main loop (Step 5).
+   - **Multi-story wave** → isolate each story in its own worktree so parallel agents never clobber each other:
+
+     ```bash
+     git worktree add "{scratchpad}/wt-{story-id}" -b "story/AB#{story-id}-{sanitized-title}" "{feature-branch}"
+     ```
+
+     Launch **one implementation agent per story, all in a single message** so they run concurrently (`backend`/`frontend`/`general-purpose` per the approved plan; if a story needs both backend and frontend work, give one agent the whole story rather than splitting it). Each agent's prompt must include: the approved plan for its story, the story's full AC, its worktree path, and these rules — work **only** inside your worktree, implement the plan plus its unit tests, run the tests you added, commit to the story branch, and report what you changed. Agents never push, never create PRs, never touch work items, and never ask the user anything.
+   - **Merge back (main loop):** merge each story branch into the feature branch (`git merge --no-ff`), resolving conflicts yourself using both stories' plans as the guide. Then `git worktree remove` and delete the story branch. Merge in `Custom.Order`-then-ID order so conflict resolution is deterministic.
+3. **Wave gate:** run Step 6 (build validation) and Step 7.1–7.2 (full test suite + lint) on the merged feature branch. Fix failures before starting the next wave — the next wave branches from this merged, green state.
+
+### F5: Feature-Level Quality and Review
+
+After the last wave:
+
+1. **Environment config parity** (Step 7.3) across the whole feature diff vs `BASE_BRANCH`.
+2. **Acceptance Criteria check** (Step 7.4) for **every AC of every implemented story** — do not proceed with any AC unverified.
+3. **Code review** (Step 8, including the Ultracode find → verify pipeline if opted in) over the entire feature diff, with the same must-fix loop.
+
+### F6: UAT Gate
+
+Present **one combined UAT checklist grouped by story** (Step 9 rules). Wait for `testing passed` before creating the PR.
+
+### F7: PR and Work Item Updates
+
+1. Push the feature branch and create **one PR**: title `AB#{feature-id}: {feature title}`, source `feature/...`, target `BASE_BRANCH`.
+2. Link the **Feature and every implemented story** to the PR.
+3. Run **Closing Related Tasks** (Step 10) once, covering the child Tasks of every implemented story — one combined table, then the usual per-task hour prompts.
+4. Move each implemented story **and** the Feature to `Code Review` (same fallback rules as Step 10).
+5. The Step 10 PR-completion rule applies unchanged: when the PR merges, only child **Tasks** may be closed — never the stories or the Feature.

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
 

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -217,13 +217,17 @@ PRs always target the branch you were on when `/implement` was invoked. The base
 
 Hot Fix work items follow the same automated checks (build, lint, tests, review) but skip manual UAT. An abbreviated confirmation is shown instead. Hot Fix PRs get a `hotfix` label. Hot Fixes target the current branch (which should be the project's production branch for production hot fixes).
 
+#### Feature Workflow (ordered story waves)
+
+Running `/implement` on a **Feature** implements its child User Stories in **waves** driven by the `Custom.Order` field: stories sharing the same order value are implemented **in parallel** (one agent per story, each in an isolated git worktree), and waves run sequentially in ascending order so later stories build on earlier ones. All work merges into a single `feature/AB#<id>-...` branch; quality checks, code review, UAT, and one PR happen at the feature level, and every implemented story is linked to that PR. Stories without a `Custom.Order` value run in a final catch-all wave (flagged for confirmation first).
+
 #### Slash Commands Reference
 
 All deployment and release operations are available as slash commands:
 
 | Command | Usage | What It Does |
 |---|---|---|
-| `/implement` | `/implement AB#1234` | Summarize work item → approve plan → implement → PR |
+| `/implement` | `/implement AB#1234` | Summarize work item → approve plan → implement → PR. On a Feature: child stories in `Custom.Order` waves, same-order stories in parallel |
 | `/review` | `/review 142` | Automated code review on a PR |
 | `/resolve-feedback` | `/resolve-feedback 142` | Address unresolved PR comment threads, push fixes, reply + resolve threads |
 | `/deploy` | `/deploy "commit message"` | Commit, push, trigger pipeline |