@chris1807/claude-kit 2.3.5 → 2.3.7

package/README.md

@@ -28,7 +28,7 @@ Every session Claude learns from your feedback and gets better at helping you sp
 | **Global Agents** | 10 | `~/.claude/agents/` (your machine, all projects) | backend, frontend, legacy (Lucee/CFML), mockup, reviewer, test-runner, build-validator, lint-checker, azure-ops, security-auditor |
 | **Project Agents** | 2 | `.claude/agents/` (in the project) | deployer, db-admin |
 | **Hooks** | 10 | `.claude/hooks/` (in the project) | Secret blocker, sensitive data blocker (Bash + MCP + output), protected files, auto-format, test suggestions, work item intent, UAT reminder, self-improve |
-| **Slash Commands** | 24 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/deep-review`, `/resolve-feedback`, `/fix-review`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/track`, `/plan-backlog`, `/plan-sprint`, `/quote-backlog`, `/cleanup-branches`, `/close-orphan-tasks`, `/quote`, `/explain`, `/create-work-item`, `/edit-work-item` |
+| **Slash Commands** | 26 | `.claude/commands/` (in the project) | `/implement`, `/autopilot`, `/review`, `/deep-review`, `/resolve-feedback`, `/fix-review`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/track`, `/plan-backlog`, `/plan-sprint`, `/quote-backlog`, `/cleanup-branches`, `/close-orphan-tasks`, `/quote`, `/explain`, `/create-work-item`, `/edit-work-item` |
 | **MCP Servers** | Up to 6 | `.mcp.json` (in the project) | **Azure DevOps** (work items, repos, pipelines, wiki), Playwright, MongoDB/SQL/Postgres, Teams, Stripe, Azure CLI |
 | **Workflow Template** | 1 | Appended to `CLAUDE.md` | Documents the full development process |
 | **Settings** | 1 | `.claude/settings.json` (in the project) | Registers all hooks and MCP servers |
@@ -207,6 +207,7 @@ your-project/                      ← Project-specific
 │   │
 │   ├── commands/
 │   │   ├── implement.md           # /implement AB#1234
+│   │   ├── autopilot.md           # /autopilot AB#1234
 │   │   ├── review.md              # /review 142
 │   │   ├── deploy.md              # /deploy "commit message"
 │   │   ├── create-release.md      # /create-release 23
@@ -284,6 +285,16 @@ Claude automatically:
 
 **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.
 
+### Implement Without Stopping
+
+```
+/autopilot AB#1234
+```
+
+Runs every step of `/implement` — plan, architect review, branch, Task, implementation, build, tests, lint, code review, PR — but never stops to ask. Where `/implement` would wait for you, Claude makes the call and logs it. An independent architect-review agent stands in for your plan approval, and the verified find → refute review stands in for your fix decisions. The PR is where you come in: it's labeled `autopilot`, its first comment thread holds the plan and every decision, and its description carries the UAT checklist nobody has run yet. Autopilot never merges, deploys, or moves an item past `Code Review`.
+
+It only stops before writing code (item not found, already has a PR, nothing to build, worktree locked by another session). If it can't get the build, tests, or review clean in three rounds, it opens a **draft** PR with what's left and leaves the item `Active`. Set `/effort` before starting, and run in auto mode (or `/add-dir` the worktree) so Claude Code's own permission prompts don't stall it.
+
 ### Review a Pull Request
 
 ```
@@ -674,6 +685,7 @@ Claude reviews for:
 | Command | Usage | What It Does |
 |---------|-------|-------------|
 | `/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 |
+| `/autopilot` | `/autopilot AB#1234` | `/implement` with no approval gates — Claude decides, logs every decision to the PR, and stops at the PR. Never merges or deploys. Draft PR if it can't finish cleanly |
 | `/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 |
@@ -688,7 +700,7 @@ Claude reviews for:
 | `/track` | `/track release 24` | Check status of a release, pipeline, work item, or environment; flags work items whose state lags their environment |
 | `/qa` | `/qa AB#1234 [env]` | Verify the item is fully deployed with a green pipeline → open the app in a real browser → sign in as a test account → full regression of the screens the story touched → pass/fail comment on the work item (never a state change). Environments: `local`, `dev`, `test`, `staging` |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose one child task with hours per story |
-| `/plan-sprint` | `/plan-sprint [project]` | Sweep the current sprint for stories/bugs with no child tasks → propose one child task with hours per item |
+| `/plan-sprint` | `/plan-sprint [project] [--next]` | Sweep the current sprint (or the next one with `--next`) for stories/bugs with no child tasks → propose one child task with hours per item |
 | `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for unpointed items ready to estimate — stories in `Design Approved`, bugs in `New` (bugs have no design states) → review completeness, check for duplicates, suggest rewrites, propose points + creator comments (10 at a time, approval-gated). Also audits the drop-out queue — tagged bugs and stories bounced to Design Review — for items whose creator answered but which nobody returned to the sweep |
 | `/quote` | `/quote AB#1234` | Estimate a work item in story points (senior-calibrated Fibonacci rubric) |
 | `/explain` | `/explain AB#1234` | Summarize and explain a work item in plain language |

package/bin/cli.js

@@ -312,7 +312,7 @@ async function main() {
       choices: [
         { name: 'Project Agents (deployer, db-admin)', value: 'agents', checked: true },
         { name: 'Hooks (secret blocker, auto-format, test suggestions)', value: 'hooks', checked: true },
-        { name: 'Slash Commands (implement, review, deploy, releases, cherry-pick, promote, rollback, track, cleanup, create-work-item, …)', value: 'commands', checked: true },
+        { name: 'Slash Commands (implement, autopilot, review, deploy, releases, cherry-pick, promote, rollback, track, cleanup, create-work-item, …)', value: 'commands', checked: true },
         { name: 'MCP Servers (Playwright, DB, Teams, Stripe, Azure, Azure DevOps)', value: 'mcp', checked: true },
         { name: 'Settings (hook registration)', value: 'settings', checked: true },
         { name: 'CLAUDE.md Workflow Section', value: 'workflow', checked: true },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.3.5",
+  "version": "2.3.7",
   "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/autopilot.md

@@ -0,0 +1,188 @@
+Implement work item AB#$ARGUMENTS on autopilot: the full `/implement` workflow, start to PR, with no human approval gates. Claude makes every decision `/implement` would ask about, and records it. Follow this workflow:
+
+## What autopilot changes, and what it doesn't
+
+`/autopilot` runs **every step of `/implement`**: workspace, summary, exploration, plan, architect review, branch, `Active` state, child Task, implementation with unit tests, build, full test suite, lint, AC coverage, code review, UAT checklist, PR, deployment-script attachments, Task close, `Code Review` state, and worktree cleanup. Features run in `Custom.Order` waves, exactly as `/implement` runs them.
+
+The only difference is who answers `/implement`'s prompts. Wherever `/implement` waits for the user, autopilot applies the matching rule in the **Gate Table**, writes the decision to the **Decision Log**, and keeps going. **Never call `AskUserQuestion`, and never end a turn to wait for a reply**, at any point in the run.
+
+What stays fixed:
+
+- **The PR is the human gate.** Autopilot opens the PR and stops there. It never merges, approves, or sets auto-complete on the PR, and it never promotes or deploys. Everything it decided is in the PR for the reviewer.
+- **Removing the approver doesn't remove the scrutiny.** Each place `/implement` relies on a person to catch a mistake gets an independent check instead. See **Independent Checks**.
+- **No human decision is taken.** Autopilot never moves an item past `Code Review`, never sets `Ready for Testing`, never changes a Feature's state, and never closes a story. Only Tasks are closed, as in `/implement`.
+- **Every rule in CLAUDE.md and every hook still holds.** That covers sensitive fields, secrets, and protected files. When a hook blocks something, record it as an open item for the PR. Never route around it.
+
+**Permission prompts are not this command's to remove.** Autopilot drops the prompts `/implement` asks. Claude Code's own permission prompts belong to the harness and the user's permission mode, and no command can suppress them. The work happens in a sibling worktree (`../{repo}-AB{id}`), outside the session's folder, so the first edit there prompts unless that folder was added with `/add-dir` or the session runs in auto mode.
+
+## Arguments
+
+`$ARGUMENTS` is the work item id, as `1234` or `AB#1234`. It can be followed by `work in place` or `no worktree`, the same opt-out `/implement` takes. Strip the phrase before reading the id.
+
+## Before Step 0: Load `/implement`
+
+Autopilot executes `/implement`'s steps, so read them first: `.claude/commands/implement.md` at the repo root (`git rev-parse --show-toplevel`). The file is committed, so every worktree has it. If it isn't there, fall back to `~/.claude/commands/implement.md`. If neither exists, Hard Stop: `/autopilot runs /implement's workflow, and .claude/commands/implement.md is missing. Re-run npx @chris1807/claude-kit init.`
+
+Run implement.md from Step 0 through Step 11, or F1 through F8 for a Feature. **This file wins every conflict with implement.md.** Three overrides apply throughout:
+
+1. **Gates resolve without asking.** Where implement.md says to wait, ask, or prompt, or offers a `(yes / no / …)` choice, apply that gate's row in the Gate Table. For a prompt the table doesn't list, take the answer implement.md suggests (its "suggested", "recommended", or "press enter to accept" value). If it suggests none, take the option that changes the least and is easiest to undo. Log the decision either way.
+2. **Ultracode is on.** Invoking `/autopilot` is the opt-in. Use the `Workflow` tool wherever implement.md's Ultracode callouts apply, at the scale they set: fan out for non-trivial work, stay lean for a one-file change. implement.md's Ultracode rules hold unchanged. Workflow agents are read-only analysts, and every write stays in the main loop.
+3. **The run ends one of three ways:** a PR ready for review, a draft PR with open items (**Unfinished Work**), or a **Hard Stop**. There is no other outcome.
+
+Open with this block, then start Step 0 without waiting:
+
+```
+## Autopilot — AB#{id}
+Running /implement end to end with no approval gates. Every decision is logged and posted to the PR.
+I stop only on a hard stop; the PR is where you review.
+Claude Code's own permission prompts can still appear. Edits in the ticket's worktree (../{repo}-AB{id})
+prompt once unless you've added it with /add-dir or are in auto mode.
+```
+
+## Gate Table
+
+Each row is a prompt in implement.md and the decision autopilot makes instead. Log every row that fires.
+
+| implement.md | The prompt | Autopilot's decision |
+|---|---|---|
+| **Workspace** | | |
+| 0b | The folder is on another ticket's branch and CLAUDE.md names no PR target. Which base? | origin's default branch (`git symbolic-ref --short refs/remotes/origin/HEAD`). |
+| 0b | *(new check)* | **PR-target guard.** If CLAUDE.md names the PR target (e.g. "PRs always target `main`") and `CURRENT` is a different branch, use the named target, unless the item is a Hot Fix. Otherwise an unwatched run started on `dev` would open a PR that deploys on merge. |
+| 0b | `origin/{BASE_BRANCH}` doesn't exist. | Hard Stop. |
+| 0d case 3 | `WT` exists but git doesn't know it. Delete or rename it? | Leave the folder alone. Use the first free `{WT}-2`, `{WT}-3`, … as `WT`. |
+| 0d case 4 | Several local `*/AB#{id}-*` branches. Which one? | The one with the newest commit (`git for-each-ref --sort=-committerdate`). |
+| 0d | The worktree is already locked. | Hard Stop. Another session may be editing it, and two unwatched edit streams in one folder can't be untangled afterward. If the lock is stale: `git worktree unlock "{WT}"`. |
+| **Work item and plan** | | |
+| 2 | Summary: "Does this look correct? Any added context?" | Print the summary, with the effort recommendation as information only, and continue. Resolve gaps with the **Ambiguity Rule**. |
+| 2 | Use Ultracode? | Yes (override 2). |
+| 3 | Approve this plan? | Run the Architect Review as an independent agent (see **Independent Checks**), apply what it finds, print the final plan, and continue. The plan goes in the PR thread. |
+| **Branch and Task** | | |
+| 4 | The open Task has no estimate. Proposed hours OK? | Set the proposed hours on `OriginalEstimate` and `RemainingWork`. |
+| 4 | More than one open Task. Which one? | The one in `Active`, then the one titled `{PREFIX} - Implement…`, then the lowest id. Leave the others alone and name them in the final report. |
+| 4 | No open Task. Create it? (yes / edit / skip) | Yes, with the proposed title and hours. |
+| 4 | Task create or link failed. Continue without one, or stop? | Continue. Step 10's after-the-fact rule creates the Task when the PR goes up. Log a warning. |
+| 4 | The state can't be advanced (no `Active` or fallback). | Log it and continue. |
+| **Quality** | | |
+| 6, 7 | The build or test suite is red. | Fix it and re-run, up to the round limit in **Unfinished Work**. Check **Pre-existing Failures** first. |
+| 7.3 | A missing environment-config cell. What value? | **Environment Config Rule**, below. |
+| 7.4 | An AC has no covering test or code path. | Add the coverage. If the AC can't be verified automatically (visual layout, a third-party system), mark it **manual-only** on the UAT checklist and in Open Items. |
+| 8 | Address the findings? (yes / select / skip) | Fix every verified must-fix. Fix a should-fix when it sits in code this change wrote or touched. List the remaining should-fixes and every nit in Open Items. Re-run the review after each round. |
+| **PR** | | |
+| 9 | UAT: "Did manual testing pass?" | Don't wait. The checklist goes in the PR description as unchecked boxes for the reviewer, and the PR says nobody has tested it by hand. |
+| 9 | Hot Fix: Create PR? | Yes. |
+| 10 | Close related Tasks? (yes / no / select) | Close only the Task this run logged against (Step 4). Leave other open Tasks alone and name them in the final report. |
+| 10 | Completed hours? | The suggested value: `OriginalEstimate` when `CompletedWork` is empty. Keep `CompletedWork` when it's already set. |
+| **Feature** | | |
+| F1 | No implementable child stories. Implement the Feature itself? | Yes, through Steps 2–11, if the Feature's own description or AC describes buildable work. Otherwise Hard Stop. |
+| F2 | Feature summary and wave plan. Look correct? | Print it and continue. Stories with no `Custom.Order` run in the final wave, in id order. |
+| F4.1 | Approve this wave's plan? | Run the Architect Review agent on the combined wave plan, apply what it finds, and continue. |
+| F4.2 | Create these Tasks? | Yes, for every story in the wave. |
+| F6 | Combined UAT | As Step 9, grouped by story. |
+
+## Ambiguity Rule
+
+`/implement` closes a gap in the requirements by asking. Autopilot closes it with these rules, in order, and logs each one as an **assumption**:
+
+1. **The latest word wins.** A later comment overrides an earlier one. Comments override the AC field, and the AC field overrides the description. An embedded mockup decides layout, and the text decides behavior.
+2. **Follow the codebase.** Where the work item is silent, do what the nearest existing feature of the same kind does: the same validation style, the same paging, the same error shape.
+3. **Take the smallest reading that meets the literal AC.** Never add behavior to fill a gap.
+4. **Fail closed.** When it's unclear who may see or do something, take the more restrictive reading. A reviewer can widen access in one line, but nobody can un-expose data.
+
+An assumption that changes what a user sees or can do also goes in Open Items, so the reviewer can't miss it.
+
+## Independent Checks
+
+Each human check in `/implement` gets a stand-in that doesn't share the author's reasoning:
+
+| `/implement` relies on | Autopilot uses |
+|---|---|
+| The user reading the plan | The Architect Review as a separate `Workflow` agent on **every** plan, trivial or not (implement.md's Ultracode variant). It gets the work item, the AC, and the draft plan, but never the reasoning behind the plan, and it reads the code itself. Apply each finding unless it grows the scope or contradicts an AC. Log every finding you decline, with the reason. |
+| The user choosing which review findings to fix | The find → adversarially-verify review, on every round. Only verified findings count. |
+| The user doing UAT | Every AC traced to a test or code path (Step 7.4), the full test suite including any E2E specs the repo has, and the UAT checklist handed to the reviewer in the PR. |
+
+## Environment Config Rule (Step 7.3)
+
+For each key this change added to one environment file but not to its parallels:
+
+- **Same in every environment by nature** (a page size, a timeout, a retry count, a relative path): copy the base value into every parallel file that exists.
+- **Varies by environment, or is a secret or a feature switch** (a URL, host, connection string, key, credential, or flag): don't invent a value. Leave the file as it is and list the cell under **Config to supply**.
+- **`appsettings.Staging.json` and `appsettings.Production.json`**: never edit them, since the protected-files hook blocks both. Always list their cells under Config to supply.
+
+## Pre-existing Failures
+
+Step 7 treats any red test as a regression from this change. Before spending fix rounds on a failing test outside the change's files, check whether it also fails on the base. Run that test in a temporary detached worktree at `origin/{BASE_BRANCH}`, then remove the worktree. If it fails there too, it's pre-existing. Don't fix it here, because that's scope nobody asked for. List it in Open Items and carry on.
+
+## Unfinished Work: the Draft PR
+
+Autopilot gets **three fix rounds** at each of these: a red build, a red test suite (regressions only), and verified must-fix review findings. If a round limit runs out, or an AC can't be met without breaking a rule in CLAUDE.md, stop fixing and finish as a draft:
+
+1. Commit what's there. Run lint, but don't hide what's still failing.
+2. Push, and create the PR with `isDraft: true`. Put a **⚠ Autopilot could not finish** section at the top of the description: what's failing, what was tried, and where it stands.
+3. Link the PR and attach deployment scripts as usual.
+4. **Leave the work item in `Active` and the Task open.** Don't log hours and don't move anything to `Code Review`. The work isn't ready for review, and the board shouldn't say it is.
+5. Run Step 11 as usual. The branch is on origin, and `/rework AB#{id}` picks it back up.
+
+A draft keeps the work and puts the problem in front of a person. Stopping without a PR would leave both on a local disk nobody is watching.
+
+## Hard Stops
+
+Halt, report, and change nothing further. Every hard stop happens before any code is written:
+
+- The Azure DevOps MCP server isn't connected, or the work item isn't found.
+- The work item is `Closed`, `Removed`, or `Deployed`.
+- The work item already has a linked PR that is **active or completed**. That is `/rework`'s job, so suggest `/rework AB#{id}`. An abandoned PR doesn't count.
+- There's nothing to build. The description and the acceptance criteria (Repro Steps for a Bug or Hot Fix) are both empty. Treat the template placeholder (`💡 Tip: … Define acceptance criteria: - [ ] …`) as empty.
+- implement.md is missing, `origin/{BASE_BRANCH}` is missing, or the ticket's worktree is locked (see the Gate Table).
+
+If a hard stop hits after Step 0 made a new worktree, give it back: `git worktree unlock "{WT}"`, then `git worktree remove "{WT}"`. It has no branch or changes yet.
+
+## Decision Log
+
+Log one line for every decision a person would have made under `/implement`: each Gate Table row that fired, each assumption, each architect finding declined, and each review finding left unfixed.
+
+`| {n} | {step} | {decision} | {why} |`
+
+Write the log to a file as you go, `{scratchpad}/autopilot-AB{id}.md` (the system temp dir if the session has no scratchpad), not only to the conversation. A Feature run is long enough for the context to be summarized, and the log has to survive that intact. The PR thread is built from this file.
+
+Print one progress line as each step finishes, so a user who comes back can see how the run went: `▶ Step 3 — plan: 4 files, 6 tests; architect review changed 2 things`.
+
+## The PR (Step 10)
+
+Create the PR as implement.md Step 10 says, with these additions:
+
+- **Labels:** `autopilot`, plus `hotfix` for a Hot Fix.
+- **Description.** Azure DevOps caps it at 4,000 characters, so keep it to this:
+
+  ```
+  > 🤖 Opened by /autopilot. No person approved the plan or ran UAT. The full plan,
+  > architect review, and every decision are in the first comment thread.
+
+  ## Summary
+  {what changed, 3–6 bullets}
+
+  ## Open Items
+  {Config to supply (key × environment) · assumptions that change behavior · manual-only ACs ·
+   should-fixes and nits not fixed · pre-existing failures · hand-run scripts. "None" if empty.}
+
+  ## UAT Checklist
+  - [ ] {item}
+  ```
+- **First comment thread.** Right after creating the PR, post one thread (`repo_pull_request_thread_write`) with the final plan, its Architect Review section, AC coverage as `| AC | Covered by |`, and the full Decision Log. Leave it active for the reviewer to resolve once they've read it.
+
+## Final Report
+
+When Step 11 is done, print:
+
+```
+## Autopilot finished — AB#{id}: {title}
+
+PR #{n} → {BASE_BRANCH}   {ready for review | DRAFT — see ⚠ in the description}
+Work item: {state}   Task AB#{t}: {closed, {h}h logged (the estimate; edit it if actual differs) | left open}
+Decisions: {n} (in the PR thread)   Open items: {n}   Other open Tasks left alone: {ids, or omit}
+
+Next: review the PR and run its UAT checklist. Once it's on Dev, run /qa AB#{id}.
+```
+
+For a hard stop, print the reason and what to fix.
+
+Then, if a `PushNotification` tool is available (load it with `ToolSearch` if it's deferred), send one notification: `AB#{id}: autopilot opened PR #{n}`, `AB#{id}: autopilot opened draft PR #{n}, needs attention`, or `AB#{id}: autopilot stopped, {reason}`. The user has probably walked away, and this is how they find out.

package/templates/commands/plan-sprint.md

@@ -1,10 +1,14 @@
-Sweep the **current sprint** for user stories and bugs without child tasks and propose a single implementation task per item with an hour estimate. Usage: `/plan-sprint [project]`
+Sweep the **current sprint** (or the **next sprint** with `--next`) for user stories and bugs without child tasks and propose a single implementation task per item with an hour estimate. Usage: `/plan-sprint [project] [--next]`
 
-This command finds every **User Story** and **Bug** in the current sprint of a chosen Azure DevOps project that **has no child tasks yet**, and — item by item — proposes **one child Task** with an hour estimate (points set the band, complexity sets where in the band it lands) for the user to approve before any work items are created. Exactly one task per work item — never a multi-task breakdown.
+This command finds every **User Story** and **Bug** in the target sprint of a chosen Azure DevOps project that **has no child tasks yet**, and — item by item — proposes **one child Task** with an hour estimate (points set the band, complexity sets where in the band it lands) for the user to approve before any work items are created. Exactly one task per work item — never a multi-task breakdown.
 
-This is the sprint-planning counterpart of `/plan-backlog`. Use `/plan-backlog` to groom the unscheduled backlog; use `/plan-sprint` after items are pulled into the sprint to make sure each has its implementation task and hours.
+This is the sprint-planning counterpart of `/plan-backlog`. Use `/plan-backlog` to groom the unscheduled backlog; use `/plan-sprint` after items are pulled into the sprint to make sure each has its implementation task and hours. Use `/plan-sprint --next` during sprint planning, once items have been pulled into the upcoming sprint but before it starts.
 
-Treat `$ARGUMENTS` as an optional project name (e.g. `/plan-sprint CSI Development`). If provided, skip the project prompt in Step 1.
+Parse `$ARGUMENTS`:
+- If it contains `--next` or the standalone word `next`, the **target sprint** is the next sprint — the first iteration that starts after the current one. Otherwise the target sprint is the current sprint.
+- Any remaining text is an optional project name (e.g. `/plan-sprint CSI Development --next`). If provided, skip the project prompt in Step 1.
+
+Below, `{sprint}` means the target sprint's name.
 
 ## Step 1: Choose the Azure DevOps Project
 
@@ -27,21 +31,43 @@ Or specify a different project name, or "list" to see all projects.
 
 If the user types `list`, call `mcp__azure-devops__core_list_projects` and present the names, then re-prompt. **Wait for the user's response.** Validate the chosen project name exists (call `core_list_projects` if uncertain).
 
-## Step 2: Resolve the Current Sprint
+## Step 2: Resolve the Target Sprint
 
-Resolve the team's **current iteration** — do not guess the iteration path:
+Resolve the target sprint from the team's iterations — do not guess the iteration path:
 
 1. Determine the team. Most projects have a default team named after the project; if `mcp__azure-devops__core_list_project_teams` shows multiple teams and it isn't obvious which one runs the sprint, ask the user which team to use.
-2. Fetch the current iteration via `mcp__azure-devops__work_list_team_iterations` (or the equivalent `work` tool) with `timeframe: current` and capture its full **iteration path** and date range.
+2. Fetch the current iteration via `mcp__azure-devops__work` (action `list_team_iterations`) with `timeframe: current` and capture its full **iteration path** and date range.
 
-If no current iteration exists (no sprint with today's date in range), report:
+**Current sprint (default):** the iteration from step 2 is the target. If no current iteration exists (no sprint with today's date in range), report:
 
 ```
 {project} has no active sprint (no iteration covers today). Nothing to plan.
+Run /plan-sprint --next to plan the upcoming sprint instead.
 ```
 
 and stop.
 
+**Next sprint (`--next`):** the API only filters on `current`, so find the next one yourself:
+
+3. Fetch **all** the team's iterations via `mcp__azure-devops__work` (action `list_team_iterations`) with no `timeframe`.
+4. Drop iterations with no start or finish date, and any named like `Release #N` — those are release groupings from `/create-release`, not sprints.
+5. Of the rest, the target is the iteration with the **earliest start date after the current sprint's finish date**. If there is no current sprint, take the earliest start date after today.
+
+If no such iteration exists, report:
+
+```
+{project} has no next sprint scheduled (no iteration starts after {current sprint or today}).
+Create the next iteration in Azure DevOps and assign it to the team, then re-run.
+```
+
+and stop.
+
+Capture the target sprint's full **iteration path** and date range, and state which sprint you resolved before querying:
+
+```
+Planning {sprint} ({start} – {finish}) — the {current | next} sprint for {team}.
+```
+
 ## Step 3: Query the Sprint
 
 Run a WIQL query via `mcp__azure-devops__wit_query` (action `wiql`) using the **literal iteration path** from Step 2:
@@ -53,7 +79,7 @@ SELECT [System.Id], [System.Title], [System.State],
 FROM WorkItems
 WHERE [System.TeamProject] = '{project}'
   AND [System.WorkItemType] IN ('User Story', 'Bug')
-  AND [System.IterationPath] UNDER '{current sprint iteration path}'
+  AND [System.IterationPath] UNDER '{target sprint iteration path}'
   AND [System.State] NOT IN ('Closed', 'Removed', 'Done', 'Resolved', 'Code Review', 'Ready for Testing', 'Testing', 'Ready for Staging', 'Staging', 'Ready to Deploy', 'Deployed')
 ORDER BY [Microsoft.VSTS.Common.StackRank] ASC
 ```
@@ -65,7 +91,7 @@ Unlike `/plan-backlog`, **Story Points are not required** — an unpointed item
 If the query returns zero items, report:
 
 ```
-No open stories or bugs found in {current sprint} of {project}.
+No open stories or bugs found in {sprint} of {project}.
 Nothing to plan.
 ```
 
@@ -83,14 +109,14 @@ Skipped {n} items that already have child tasks:
   - ...
 ```
 
-If after filtering there are zero items left, report "Every open story and bug in {current sprint} already has a task — nothing to plan." and stop.
+If after filtering there are zero items left, report "Every open story and bug in {sprint} already has a task — nothing to plan." and stop.
 
 ## Step 5: Present the Working List
 
 Show the remaining items the user is about to walk through:
 
 ```
-Found {n} items in {current sprint} ({date range}) with no child tasks:
+Found {n} items in {sprint} ({date range}) with no child tasks:
 
 | #  | ID       | Type       | Title                                    | State     | Points |
 |----|----------|------------|------------------------------------------|-----------|--------|
@@ -204,7 +230,7 @@ Create the approved task with `mcp__azure-devops__wit_work_item_write` (action `
 - **fields**:
   - `Microsoft.VSTS.Scheduling.OriginalEstimate` — the hour estimate (as a number)
   - `Microsoft.VSTS.Scheduling.RemainingWork` — the same hour estimate
-  - `System.IterationPath` — copy from the parent (the parent is in the current sprint, so the task lands on the sprint taskboard)
+  - `System.IterationPath` — copy from the parent (the parent is in the target sprint, so the task lands on that sprint's taskboard)
   - `System.AreaPath` — copy from the parent
   - `System.AssignedTo` — copy from the parent (pass the parent's `uniqueName` / email if its `System.AssignedTo` value is an identity object). If the parent is unassigned, leave this field unset rather than failing.
 
@@ -225,7 +251,7 @@ Then move to the next item.
 Once the loop ends (all items handled, or user said `cancel-all`):
 
 ```
-## Sprint Planning Complete — {project} / {current sprint}
+## Sprint Planning Complete — {project} / {sprint}
 
 Items planned:      {n_planned}
   ✓ Tasks created:  {n_tasks_total} — one per item ({hours_total} hrs)

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -53,6 +53,8 @@ Short, single-query operations (`/track`, `/explain`, `/close-orphan-tasks`) do
 
 **`/implement` uses ultracode scaled to the change** — its code review always fans out (find → adversarially-verify), but exploration and per-AC coverage fan out only for non-trivial / full-stack stories; a one-line config change runs lean. It's the daily driver, so it doesn't blanket-fan-out like `/rework`.
 
+**`/autopilot` always uses it**, at `/implement`'s scale — invoking the command is the opt-in. With no human approving the plan or choosing review fixes, the independent Architect Review agent and the find → adversarially-verify review are what stand in for that scrutiny.
+
 **`/plan-backlog`, `/plan-sprint`, and `/quote-backlog` use it opt-in** — only when ultracode is on.
 
 ### Sensitive Data Policy
@@ -381,6 +383,7 @@ All deployment and release operations are available as slash commands:
 | Command | Usage | What It Does |
 |---|---|---|
 | `/implement` | `/implement AB#1234` | Summarize work item → approve plan → ensure an open child Task with hours → implement → PR (closes the Task, logs hours). On a Feature: child stories in `Custom.Order` waves, same-order stories in parallel |
+| `/autopilot` | `/autopilot AB#1234` | `/implement` end to end with no approval gates: Claude plans, runs an independent architect review, implements, fixes verified review findings, and opens the PR (labeled `autopilot`) with every decision logged in a PR thread and the UAT checklist for the reviewer. Never merges or deploys. Hard-stops only before code is written; if it can't finish cleanly, it opens a draft PR and leaves the item `Active` |
 | `/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 (only on `dev`/`test`/`staging`/`prod` — never on `main`) |
@@ -394,7 +397,7 @@ All deployment and release operations are available as slash commands:
 | `/where` | `/where AB#1234` | Show which environment branches contain a work item's commits |
 | `/qa` | `/qa AB#1234 [env]` | Verify the item is fully deployed with a green pipeline → open the app in a real browser → sign in as a test account → full regression of the screens the story touched → pass/fail comment (never a state change) |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose child tasks with hours |
-| `/plan-sprint` | `/plan-sprint [project]` | Sweep the current sprint for stories/bugs with no child tasks → propose one child task with hours per item |
+| `/plan-sprint` | `/plan-sprint [project] [--next]` | Sweep the current sprint (or the next one with `--next`) for stories/bugs with no child tasks → propose one child task with hours per item |
 | `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for unpointed items ready to estimate — stories in `Design Approved`, **bugs in `New`** (bugs have no design states) → review completeness, check for duplicates, suggest rewrites, propose points (+ Investment Category / Impact where unset) + creator comments (10 at a time, approval-gated). Pointed items move to Dev Ready; stories that can't be quoted move back to **Design Review**, bugs that can't be quoted get a **`needs-info`** tag, so the next sweep skips them. Every run also audits the drop-out queue (tagged bugs **and** stories bounced to Design Review) and reports any whose creator answered but which nobody returned to the sweep — neither mechanism expires, so those are otherwise invisible forever |
 | `/quote` | `/quote AB#1234` | Estimate story points for one work item, and propose Investment Category / Impact if it has none; on approval, sets them and moves the item to Dev Ready. If it can't be estimated, offers to send a story back to **Design Review** or tag a bug **`needs-info`** |
 | `/create-work-item` | `/create-work-item [description]` | Interactively draft and create a Feature, Bug, User Story, or Hot Fix — opens each with a plain-English Summary for the PM, then code-grounded Technical Details for the developer, proposes story points and Investment Category / Impact (user must agree) and creates pointed items in Dev Ready; on a Feature, also drafts its child stories with `Custom.Order` waves. Runs automatically for any plain-language request to create a work item |