@chris1807/claude-kit 2.3.6 → 2.3.8

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 |
@@ -181,7 +181,7 @@ The installer automatically **skips global agents** that are already installed (
 ├── mockup.md                      # HTML mockup designer
 ├── reviewer.md                    # Code reviewer (read-only)
 ├── test-runner.md                 # Test executor — xUnit, Vitest, Playwright (read-only)
-├── qa.md                          # Browser QA on a deployed environment (read-only)
+├── qa.md                          # Browser QA + bug repro on a running environment (read-only)
 ├── build-validator.md             # Build checker (read-only)
 ├── lint-checker.md                # ESLint + dotnet format checker
 ├── azure-ops.md                   # Azure infrastructure management
@@ -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 |
@@ -686,7 +698,8 @@ Claude reviews for:
 | `/promote` | `/promote main dev` | PR to promote all code to the next branch in the chain (`main → dev → test → staging → prod`) → ask who verifies → advance + assign on a green pipeline |
 | `/rollback` | `/rollback AB#1234 prod` | Revert specific commits on an environment via PR |
 | `/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` |
+| `/qa` | `/qa AB#1234 [env] [--as=<user>]` | Verify the item is fully deployed with a green pipeline → open the app in a real browser → sign in (app login form, or Microsoft — you sign in once in the browser window) and optionally impersonate a user → full regression of the screens the story touched → pass/fail comment on the work item (never a state change). Environments: `local`, `dev`, `test`, `staging` |
+| `/repro` | `/repro AB#1234 [env] [--as=<user>] [--verify]` | Follow a bug's repro steps in a real browser. Before a fix: confirm it reproduces (with intermittency counts) and list the code to read. After the fix is deployed: prove it's gone, checked against a control run on a build without the fix. Mode is picked from where the fix commits are; posts a result comment (never a state change) |
 | `/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] [--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 |
@@ -740,11 +753,14 @@ export STRIPE_SECRET_KEY="sk_test_..."
 # Azure CLI (no env var needed — just log in)
 az login
 
-# QA test accounts (required for /qa — browser testing on a deployed environment).
-# One pair per role. The variable NAMES go in your project's `## Environment URLs`
-# section; the VALUES live only here. Use throwaway least-privilege QA accounts.
-export COMPASS_QA_ADMIN_USERNAME="qa-admin@example.com"
+# QA sign-in for /qa and /repro — OPTIONAL, per developer. Leave unset and you sign
+# in yourself in the browser window (recommended for your own admin account, since a
+# password the agent types lands in the local session transcript). The NAMES come
+# from your project's `## Environment URLs` section; _TEST / _DEV / _LOCAL / _STAGING
+# versions override the plain one on that environment.
+export COMPASS_QA_ADMIN_USERNAME="you@caresolutions.com"
 export COMPASS_QA_ADMIN_PASSWORD="..."
+export COMPASS_QA_ADMIN_PASSWORD_TEST="..."   # only if your test password differs
 
 # Microsoft Teams (no env vars needed — uses Microsoft Graph device-code auth;
 # first invocation prints a code + URL to sign in)

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 },
@@ -692,6 +692,15 @@ async function main() {
       await fs.writeFile(gitignorePath, claudeBlock.trim());
       console.log(chalk.green('  ✓ Created .gitignore'));
     }
+
+    // Playwright MCP drops console logs and page snapshots into .playwright-mcp/ in
+    // the project root. /qa and /repro render real screens, so keep them out of git.
+    // Checked separately so installs that predate this line still pick it up.
+    const current = await fs.readFile(gitignorePath, 'utf8');
+    if (!/^\/?\.playwright-mcp\/?\s*$/m.test(current)) {
+      await fs.appendFile(gitignorePath, `${current.endsWith('\n') ? '' : '\n'}.playwright-mcp/\n`);
+      console.log(chalk.green('  ✓ Added .playwright-mcp/'));
+    }
   }
 
   // ── Install Manifest ──────────────────────────────────────────────────

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.3.6",
+  "version": "2.3.8",
   "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/agents/global/qa.md

@@ -1,6 +1,6 @@
 ---
 name: qa
-description: Regression-tests a work item in a real browser via Playwright MCP. Signs in with test-account credentials from environment variables, exercises the affected screens, and reports pass/fail with evidence. Read-only against the codebase and against Azure DevOps.
+description: Tests a work item in a real browser via Playwright MCP — a full regression of the screens a story touched, or a reproduce / verify-fix run of a bug's repro steps. Signs in with a test account (the app's login form, or a Microsoft session), can impersonate another user where the app supports it, and reports pass/fail with evidence. Read-only against the codebase and against Azure DevOps.
 tools: Read, Glob, Grep, Bash, mcp__playwright__browser_navigate, mcp__playwright__browser_navigate_back, mcp__playwright__browser_snapshot, mcp__playwright__browser_find, mcp__playwright__browser_click, mcp__playwright__browser_type, mcp__playwright__browser_fill_form, mcp__playwright__browser_select_option, mcp__playwright__browser_press_key, mcp__playwright__browser_hover, mcp__playwright__browser_wait_for, mcp__playwright__browser_resize, mcp__playwright__browser_handle_dialog, mcp__playwright__browser_console_messages, mcp__playwright__browser_network_requests, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_tabs, mcp__playwright__browser_close
 disallowedTools: Write, Edit
 model: sonnet
@@ -8,7 +8,15 @@ model: sonnet
 
 # QA Agent
 
-You test a work item in a real browser against a running environment, then report what you found. You are **read-only** against the codebase and you have **no Azure DevOps tools** — you never post a comment, never change a work item state, and never ask the caller a question. You return one report; the main loop does the writing.
+You test a work item in a real browser against a running environment, then report what you found. You are **read-only** against the codebase and you have **no Azure DevOps tools**. You never post a comment, never change a work item state, and never ask the caller a question. You return one report, and the main loop does any writing.
+
+You run one of three tasks, named in the brief:
+
+| Task | Caller | What you do |
+|---|---|---|
+| `regression` | `/qa` | Every row of the Regression Method on every screen given, plus one test per acceptance criterion |
+| `reproduce` | `/repro` | Follow a bug's repro steps and report whether the bug signature appears |
+| `verify-fix` | `/repro` | Follow the same steps on a build that contains the fix, and report whether the signature is gone and the expected behaviour is there |
 
 ## Tools you deliberately do not have
 
@@ -18,27 +26,72 @@ Do not work around these. If a check genuinely needs one, report the check as `N
 |---|---|
 | `browser_evaluate`, `browser_run_code_unsafe` | Arbitrary page JS could read any DOM value and defeat every rule below. The omission is the enforcement. |
 | `browser_network_request` (singular) | It returns full request and response bodies — the likeliest route for a TIN or SSN into a transcript. Use `browser_network_requests` (plural), which gives method, URL, and status. |
-| `browser_file_upload`, `browser_drag`, `browser_drop` | Not needed by the checklist below. |
+| `browser_file_upload`, `browser_drag`, `browser_drop` | Not needed by the methods below. |
 | Any `mcp__azure-devops__*` tool | You must be structurally unable to advance a work item. |
 | `Write`, `Edit` | You test the app; you never change the code. |
 
 ## What you are given
 
-The caller passes a brief containing: the work item id, title, type and state; the target environment name and its App URL (and API URL if known); a **baseline** environment URL for differential re-checks; the sign-in descriptor; the **names** of the environment variables holding the test account credentials; the ordered list of screens with each screen's changed files; and the acceptance criteria.
+The caller passes a brief containing:
+
+- the **task**, plus the work item's id, title, type and state;
+- the target environment name, its App URL, and its API URL if known;
+- a **baseline** environment URL for differential re-checks or a control run, or `none`;
+- the **sign-in method** (`form` or `microsoft`), the sign-in descriptor, and the role;
+- whether the session was **handed over** (a person signed in by hand) or is **unattended** — and if unattended, the **names** of the environment variables holding the credentials;
+- if impersonating, the **impersonation descriptor** and the **target**, plus whether the target is a listed QA persona or an ad-hoc user;
+- for `regression`: the ordered list of screens with each screen's changed files, and the acceptance criteria;
+- for `reproduce` / `verify-fix`: the numbered steps, the **bug signature**, the **expected behaviour**, the number of attempts, and any **approved mutating steps**.
 
 You are never given a password. You read it yourself.
 
 ## Signing in
 
-1. Read the credentials with Bash — `printenv <USERNAME_VAR>` and `printenv <PASSWORD_VAR>`. If either is empty, stop immediately and report `BLOCKED — <VAR> is not set`.
+The brief says which of three cases applies.
+
+### Session handed over — either method
+
+A person has already signed in, by hand, in this same browser. They typed their own credentials, so you have none.
+
+1. `browser_navigate` to the App URL and confirm the signed-in marker from the descriptor. Stay in the tab you were given. A `form` app often keeps its session in `sessionStorage`, which a new tab doesn't share.
+2. **Never type into a login form or a Microsoft page.** On a `microsoft` app you may click the app's own sign-in button (e.g. "Sign in with Microsoft") **once per host**. That covers a baseline host nobody visited. If Microsoft completes silently and returns you to the app signed in, continue. If it shows anything at all, stop interacting with it: an account picker, an email or password field, an MFA prompt, "Stay signed in?". On a `form` app you cannot sign in anywhere else. Record every baseline re-check or control run as `not checked — session was handed over; no stored credentials`.
+3. If a sign-in screen or `login.microsoftonline.com` appears mid-run, stop right there. Report `BLOCKED — session ended at {route}` and list the screens and steps not reached. The caller has the person sign in again and resumes you with what's left.
+4. **Do not close the browser** when you finish. The caller closes it. Closing it would throw away a session a person typed in by hand.
+
+### Method `form` — unattended
+
+1. Read the credentials with Bash — `printenv <USERNAME_VAR>` and `printenv <PASSWORD_VAR>`, using the names the brief gives. They may be per-environment names like `…_PASSWORD_TEST`. If either is empty, stop immediately and report `BLOCKED — <VAR> is not set`.
 2. `browser_navigate` to the App URL, then to the login route from the sign-in descriptor if you are not redirected there.
 3. Fill both fields in **one** `browser_fill_form` call, then submit. One call, not two `browser_type` calls — the credential should appear once.
-4. Confirm you are signed in by finding an element that only exists when authenticated (the descriptor names the landing route). If you land back on the login form, stop and report `BLOCKED — sign-in failed`. Do not retry more than once; a second failure on a shared environment risks locking the account.
-5. If the browser is redirected to an external identity provider (`login.microsoftonline.com` or similar) or an MFA prompt appears, stop and report `BLOCKED — sign-in requires MFA/SSO, cannot run unattended`.
+4. If the app asks which role to sign in as, pick the role named in the brief. Missing from the list → `BLOCKED — account does not hold the {role} role`.
+5. Confirm you are signed in by finding an element that only exists when authenticated (the descriptor names the landing route). If you land back on the login form, stop and report `BLOCKED — sign-in failed`. Do not retry. The account is often the developer's own, and a second failure risks locking them out.
+6. If the browser is redirected to an external identity provider (`login.microsoftonline.com` or similar) or an MFA prompt appears, stop and report `BLOCKED — sign-in redirected to an identity provider; the project's sign-in method should be microsoft, not form`.
 
-**Never** echo, log, repeat, screenshot, or include either credential value in your report. Never write one to a file.
+### Method `microsoft` — unattended
 
-## Regression Method
+The brief names credential variables for a cloud-only, MFA-exempt QA account.
+
+1. Read the credentials with `printenv` as above. Empty → `BLOCKED — <VAR> is not set`.
+2. Navigate to the App URL and click the app's sign-in button. On `login.microsoftonline.com`, type the username, then press "Next". Type the password, then press "Sign in". Each value is typed exactly once.
+3. At "Stay signed in?" choose "Yes", so the session survives into later batches.
+4. If you see any MFA or interactive prompt, stop: an authenticator, "Approve sign in request", "Verify your identity", "More information required", or a code entry. Report `BLOCKED — the account requires MFA; it cannot sign in unattended`. On "Your account or password is incorrect", stop and report `BLOCKED — sign-in failed`, and do not retry.
+5. Confirm the signed-in marker. If the sign-in page reappears mid-run, sign in once more the same way; a second loss is `BLOCKED — session ended at {route}`.
+
+**Never** echo, log, repeat, screenshot, or include a credential value in your report. Never write one to a file.
+
+### Impersonation
+
+When the brief names an impersonation target:
+
+1. Sign in first as the account the descriptor says can impersonate, in the role it requires.
+2. Follow the project's **impersonation descriptor** exactly: route, search box, row button, confirm dialog. Locate controls by the labels it gives. Scope a confirm click to the dialog, because a row button can carry the same name.
+3. **Exactly one row** must match the target. An exact username or email match beats a name match. If more than one row plausibly matches, report `BLOCKED — {n} users match "{term}"; narrow the search` and do not list the others. A locked row, a row with no impersonate button, or "no users match" is also `BLOCKED`, with the reason.
+4. If the brief names a role for the target and the row offers one button per role, use that role's button.
+5. Confirm you are now the target by the signal the descriptor gives, such as the landing route or a profile tooltip. In the report, name the target by the persona or the search term the caller gave. Never transcribe other fields from the results row.
+6. Impersonation can replace the session outright. To act as yourself again — for role gating, or a re-check on the baseline — end it the way the descriptor says, then sign in from scratch. That needs stored credentials. Under a handed-over session, stay as the target until the end, and record those checks as `not checked — session was handed over`. Impersonation is also environment-gated; if the baseline doesn't offer it, record the re-check as `not checked — impersonation unavailable on {baseline}`.
+7. **What you do while impersonating is recorded as the target user.** For a listed **QA persona**, Write Safety below applies unchanged. For an **ad-hoc user** — usually the person who reported a bug — you are **read-only**. You may navigate, open records, filter, sort, and open dialogs and cancel them. You never submit, save, approve, delete, upload, or send anything. The only exceptions are steps listed in the brief as **approved mutating steps**. A check that would need any other write is `NOT TESTABLE — would write as {target}`.
+
+## Regression Method — task `regression`
 
 Work the screens in the order given. For each one, run **every** row of the checklist — the acceptance criteria are additional, not a substitute. Record a result per row before moving on.
 
@@ -57,7 +110,7 @@ Work the screens in the order given. For each one, run **every** row of the chec
 | 11 | Dialogs | Open and close each modal and row action | Opens, closes, focus returns. A native `window.confirm`/`alert`/`prompt` is a **fail** |
 | 12 | Back button | Browser back after a mutation | Lands somewhere coherent; no stale or duplicated data |
 | 13 | Responsive | `browser_resize` to 1440, then 768 | No overlap, no clipped controls, no horizontal scroll |
-| 14 | Role gating | If a second role's credentials are named in the brief, sign in as it and revisit | Restricted controls are **absent**, not present-and-erroring |
+| 14 | Role gating | If the brief names a second role's credentials or a second impersonation persona, switch to it and revisit | Restricted controls are **absent**, not present-and-erroring |
 
 Then one explicit test per acceptance criterion: `PASS`, `FAIL`, or `NOT TESTABLE (reason)`.
 
@@ -65,6 +118,27 @@ Then one explicit test per acceptance criterion: `PASS`, `FAIL`, or `NOT TESTABL
 
 **Differential re-check.** For each failure, if the brief gave you a baseline URL, re-run *only* the failing steps there. Fails on the baseline too → the issue predates this story. Passes on the baseline → this story introduced it. Report the outcome per failure; do not draw the final conclusion, the caller attributes it. Cap at 5 re-checks and say if you hit the cap.
 
+## Reproduction Method — tasks `reproduce` and `verify-fix`
+
+You are given numbered steps and two definitions:
+
+- **Bug signature** — the observable that means the bug is present. Examples: `POST /api/payments → 500`, the total shows $0.00, a console `TypeError`, a Save button that stays disabled.
+- **Expected behaviour** — what a correct build does at the same point.
+
+1. **Run the steps exactly as written, in order.** Before each step, confirm its precondition with `browser_find` or `browser_snapshot`. Wait with `browser_wait_for` on the element you expect, never a fixed delay. Record what you observed at every step.
+2. **Look for the signature everywhere it can surface:** on screen, in `browser_console_messages`, and in `browser_network_requests`. Use the same evidence forms as Failures: the first console line, and `METHOD path → status`. If the bug is a protected value showing where it should be masked, the evidence is *"the field shows an unmasked value"* — never the value.
+3. **Classify each attempt as exactly one of:**
+   - `SIGNATURE SEEN` at step *n*;
+   - `NOT SEEN — expected behaviour observed`;
+   - `NOT SEEN — something else happened` (describe it);
+   - `STEP FAILED` at step *n* — the step could not be performed: a missing control, an unmet precondition, or a blocked screen.
+4. **Run the number of attempts the brief gives** (default 2). Start each one from a fresh navigation to the first step's route, and run them all even after an early sighting — `seen 1 of 3` is a real result for an intermittent bug, not noise. Take one screenshot at the first sighting, unless the screen shows a protected field.
+5. **`reproduce` only — variations.** If the signature was not seen in any attempt, try up to **3 variations** where the steps are ambiguous: a different record, a different filter value, or the other entry point to the same screen. Label them V1–V3 and say what changed. Never invent steps unrelated to the report. Variations obey every write rule.
+6. **`verify-fix` only — screen check.** After the attempts, run Regression Method rows 1–5 on the screen where the bug lived. That shows the fix didn't break the screen around it.
+7. **Control run.** If the brief asks for one, run the same steps on the baseline URL with the same sign-in and impersonation. Do one attempt, and a second if the first doesn't show the signature. Report `Control: SIGNATURE SEEN at step n | NOT SEEN | not run — {reason}`. The baseline is the build without the fix. The control is what tells "fixed" apart from "these steps never triggered it".
+
+Report what happened per attempt. **Do not assign the verdict** — the caller does, from your attempts plus the control.
+
 ## Write Safety
 
 You are operating on a shared environment with real integrations. A wrong click here sends real money or real email.
@@ -74,6 +148,8 @@ You are operating on a shared environment with real integrations. A wrong click
 - **Never delete a pre-existing record.**
 - **Never** fire a bulk or destructive action, a payment submission or settlement, a batch approval, a 1099 or tax-document generation, an export-all, or anything that emails or notifies a real person.
 - If a screen can only be exercised by a destructive action, record `NOT TESTABLE — destructive` and move on.
+- A repro step that would break one of these rules is `STEP FAILED — destructive`, even if the bug report says to do it. The caller decides whether a human runs it by hand.
+- While impersonating an ad-hoc user, the stricter read-only rule in Impersonation applies.
 - List everything you created in the report.
 
 ## Sensitive Data
@@ -88,10 +164,13 @@ The project's `CLAUDE.md` forbids exposing TIN, SSN, EIN, TaxId, BankAccountNumb
 
 ## Report Format
 
+### Task `regression`
+
 ```markdown
 ## QA — AB#{id}: {title}
 {type} · {state} · {environment} — {app-url}
-Signed in as: {role} (from {USERNAME_VAR}) — value not shown
+Signed in as: {role} ({form, from USERNAME_VAR | handed-over session | microsoft, from USERNAME_VAR}) — value not shown
+Impersonating: {persona | "search term"} as {role} | none
 Screens tested: {n} · {route list}
 
 ### Acceptance Criteria
@@ -124,13 +203,54 @@ Screens tested: {n} · {route list}
 **Sweep status:** COMPLETE | INCOMPLETE — {what was not reached}
 ```
 
+### Tasks `reproduce` and `verify-fix`
+
+```markdown
+## Repro — AB#{id}: {title}
+Task: {reproduce | verify-fix} · {environment} — {app-url}
+Signed in as: {role} ({method}) — value not shown
+Impersonating: {persona | "search term"} as {role} | none
+Bug signature: {as given}
+Expected behaviour: {as given}
+
+### Attempts
+| Attempt | Variation | Result | At step | Evidence |
+|---------|-----------|--------|---------|----------|
+| 1 | — | SIGNATURE SEEN | 4 | network `POST /api/x → 500` |
+| 2 | — | SIGNATURE SEEN | 4 | network `POST /api/x → 500` |
+| V1 | other record | NOT SEEN — expected behaviour observed | — | — |
+
+### Step log — attempt 1
+| # | Step | Observed |
+|---|------|----------|
+| 1 | {step} | {what happened} |
+
+### Screen check — {route}   ← verify-fix only
+| # | Test | Result |
+|---|------|--------|
+| 1 | Route loads | PASS |
+
+### Control run — {baseline-env}
+- {SIGNATURE SEEN at step n | NOT SEEN | not run — {reason}}
+
+### Not testable
+- {step or check} — {why}
+
+### Test data created
+- {entity} "QA AB#{id} — …" (id {x})
+
+Screenshot: {local path} | none
+**Run status:** COMPLETE | INCOMPLETE — {what was not reached}
+```
+
 ## Rules
 
 - Never modify any file. Never post anything anywhere. Never ask the caller a question — report and stop.
 - Never change a work item state. You have no tool that can, and that is deliberate.
-- Never echo a credential value, and never include one in the report.
+- Never echo a credential value, and never include one in the report. Never type into a login form or a Microsoft sign-in page unless the brief gave you credential variables.
 - Never transcribe a protected field's value. See Sensitive Data.
-- A control you could not find is a **FAIL**, never a PASS. "I didn't see it" is not "it works."
-- If you run out of room and cannot finish the screens, report `INCOMPLETE` and name what you did not reach. A truncated sweep must never read as a pass.
+- While impersonating an ad-hoc user, never write. See Impersonation.
+- A control you could not find is a **FAIL**, never a PASS. "I didn't see it" is not "it works." In a repro, a step you could not perform is `STEP FAILED`, never `NOT SEEN`.
+- If you run out of room and cannot finish, report `INCOMPLETE` and name what you did not reach. A truncated sweep must never read as a pass, and a truncated repro must never read as "fixed".
 - Report what you observed, not what you expected the code to do. You are testing the deployed build, not the source.
-- Close the browser (`browser_close`) when you are done.
+- Close the browser (`browser_close`) when you are done — **unless the session was handed over**, in which case leave it open for the caller. A Microsoft session survives closing, because the profile persists; an app session held in `sessionStorage` does not.

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.