@chris1807/claude-kit 2.1.8 → 2.1.10

package/README.md

@@ -1,6 +1,6 @@
 # Claude Kit
 
-> A starter kit for [Claude Code](https://claude.ai/code) — agents, hooks, MCP servers, slash commands, and workflow automation, installed into any project with a single `npx` command.
+> A [Claude Code](https://claude.ai/code) starter kit **built for Azure DevOps teams** — agents, hooks, MCP servers, and slash commands that automate the full work item → branch → PR → release → deploy lifecycle. Installed into any project with a single `npx` command.
 
 [![npm](https://img.shields.io/npm/v/@chris1807/claude-kit)](https://www.npmjs.com/package/@chris1807/claude-kit)
 
@@ -8,7 +8,16 @@
 
 ## About
 
-This package installs a complete AI development infrastructure into any project. It includes specialized agents that handle specific tasks (deployment, database ops, code review), security hooks that prevent mistakes automatically, MCP server connections to your tools (databases, Teams, Stripe, Azure CLI), and slash commands that automate your entire workflow from work item to pull request.
+Claude Kit installs a complete AI development infrastructure into any project that uses **Azure DevOps** for work tracking, source control (Azure Repos), and CI/CD (Azure Pipelines). It includes specialized agents that handle specific tasks (deployment, database ops, code review), security hooks that prevent mistakes automatically, MCP server connections to your tools (Azure DevOps, databases, Teams, Stripe, Azure CLI), and slash commands that automate the entire workflow from work item to pull request.
+
+The slash commands assume Azure DevOps as the system of record:
+
+- **Work items** — read, created, and updated via the Azure DevOps MCP server (`AB#1234` ids throughout)
+- **Branches & pull requests** — created in Azure Repos and voted on / merged through Azure DevOps
+- **Releases & deployments** — tracked as Azure DevOps iterations (`Release #N`) and tags; CD runs on Azure Pipelines
+- **Wiki, test plans, advanced security alerts** — all surfaced through the same Azure DevOps MCP server
+
+> **Not using Azure DevOps?** The Claude Code primitives (agents, hooks, memory) are still useful, but the slash commands, the `devops-tracker` agent, and the deployment workflow won't apply out of the box — you'd need to rewrite the `/implement`, `/review`, `/deploy`, `/create-release`, `/deploy-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/rework`, and `/resolve-feedback` commands against GitHub / GitLab / Jira / etc.
 
 Every session Claude learns from your feedback and gets better at helping you specifically. The infrastructure is modular — install only what your project needs.
 
@@ -19,8 +28,8 @@ Every session Claude learns from your feedback and gets better at helping you sp
 | **Global Agents** | 13 | `~/.claude/agents/` (your machine, all projects) | backend, frontend, legacy (Lucee/CFML), manager, mockup, reviewer, test-runner, build-validator, lint-checker, uat-generator, azure-ops, security-auditor, api-tester |
 | **Project Agents** | 3 | `.claude/agents/` (in the project) | deployer, db-admin, devops-tracker |
 | **Hooks** | 9 | `.claude/hooks/` (in the project) | Secret blocker, sensitive data blocker (Bash + MCP + output), protected files, auto-format, test suggestions, UAT reminder, self-improve |
-| **Slash Commands** | 13 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/cleanup-branches`, `/quote`, `/explain` |
-| **MCP Servers** | Up to 6 | `.mcp.json` (in the project) | Playwright, MongoDB/SQL/Postgres, Teams, Stripe, Azure CLI |
+| **Slash Commands** | 13 | `.claude/commands/` (in the project) | `/implement`, `/review`, `/resolve-feedback`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/cleanup-branches`, `/quote`, `/explain` |
+| **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 |
 
@@ -30,6 +39,8 @@ Every session Claude learns from your feedback and gets better at helping you sp
 
 - [Claude Code CLI](https://claude.ai/code) installed
 - [Node.js](https://nodejs.org/) 18 or later
+- An **Azure DevOps** organization with a project for work items, an Azure Repos Git repository, and (optionally) Azure Pipelines for CD
+- An Azure DevOps Personal Access Token (PAT) — used by the Azure DevOps MCP server. Scopes needed: Work Items (read/write), Code (read/write), Build (read/execute), Wiki (read/write)
 
 ### Verify it works
 
@@ -62,7 +73,7 @@ You'll be asked:
 2. **Components** — checkboxes to pick which parts to install:
    - ☑ Project Agents (deployer, db-admin, devops-tracker)
    - ☑ Hooks (secret blocker, auto-format, etc.)
-   - ☑ Slash Commands (13 commands — /implement, /review, /deploy, /create-release, /deploy-release, /add-to-release, /cherry-pick, /promote, /rollback, /status, /cleanup-branches, /quote, /explain)
+   - ☑ Slash Commands (/implement, /review, /resolve-feedback, /deploy, /create-release, /deploy-release, /add-to-release, /cherry-pick, /promote, /rollback, /status, /cleanup-branches, /quote, /explain)
    - ☑ MCP Servers
    - ☑ Settings
    - ☑ CLAUDE.md Workflow
@@ -606,6 +617,7 @@ Claude reviews for:
 |---------|-------|-------------|
 | `/implement` | `/implement AB#1234` | Read work item → summarize → approve plan → implement → quality checks → UAT → PR |
 | `/review` | `/review 142` | Full code review on a PR with inline comments |
+| `/resolve-feedback` | `/resolve-feedback 142` | Address unresolved PR comment threads, push fixes, reply + resolve threads |
 | `/deploy` | `/deploy "message"` | Commit, push, trigger pipeline if on environment branch |
 | `/create-release` | `/create-release 23` | Group work items into Release #23 iteration with tags |
 | `/deploy-release` | `/deploy-release 23 staging` | Cherry-pick release work items to environment via PR |

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.8",
-  "description": "Claude Code starter kit — agents, hooks, MCP servers, slash commands, and workflow automation",
+  "version": "2.1.10",
+  "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": {
     "claude-kit": "./bin/cli.js"
@@ -17,7 +17,10 @@
     "mcp",
     "agents",
     "hooks",
-    "starter-kit"
+    "starter-kit",
+    "azure-devops",
+    "azure-pipelines",
+    "devops-workflow"
   ],
   "author": "Chris Waters <chriswaters@caresolutions.com>",
   "license": "MIT",

package/templates/commands/plan-backlog.md

@@ -0,0 +1,219 @@
+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]`
+
+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.
+
+Treat `$ARGUMENTS` as an optional project name (e.g. `/plan-backlog CSI Development`). If provided, skip the project prompt in Step 1.
+
+## Step 1: Choose the Azure DevOps Project
+
+### Detect the default project
+
+Before prompting, attempt to detect the default Azure DevOps project from CLAUDE.md, in this order:
+
+1. **Project CLAUDE.md** — read `<current-repo>/CLAUDE.md`. Look for an explicit `project: <name>` declaration, a "Work items live in **<Project Name>**" sentence, or a `## Pipeline Configuration` table with project references.
+2. **Parent CLAUDE.md** — read `<parent-dir>/CLAUDE.md` (e.g. `~/Projects/CLAUDE.md`). Look for the same patterns. The CSI parent CLAUDE.md, for example, declares: "Work items for both **COMPASS** and **CSI Pay** live in the **CSI Development** Azure DevOps project."
+
+If a default is found, present it pre-selected:
+
+```
+Which Azure DevOps project should I sweep?
+
+  Default: {detected project}   ← press enter to accept
+
+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: Query the Backlog
+
+Run a WIQL query via `mcp__azure-devops__wit_query_by_wiql` to find candidate stories. "Backlog" means items at the **root iteration path** (not assigned to any sprint).
+
+```sql
+SELECT [System.Id], [System.Title], [System.State],
+       [System.WorkItemType], [System.IterationPath],
+       [Microsoft.VSTS.Scheduling.StoryPoints], [System.Tags]
+FROM WorkItems
+WHERE [System.TeamProject] = '{project}'
+  AND [System.WorkItemType] IN ('User Story', 'Bug')
+  AND [System.State] = 'Dev Ready'
+  AND [Microsoft.VSTS.Scheduling.StoryPoints] > 0
+  AND [System.IterationPath] = '{project}'
+ORDER BY [Microsoft.VSTS.Common.StackRank] ASC
+```
+
+> The `[System.IterationPath] = '{project}'` clause restricts results to the **root** iteration — items not yet placed in a sprint. If a project uses a different convention (e.g. an explicit "Backlog" iteration), ask the user to confirm before proceeding.
+
+If the query returns zero items, report:
+
+```
+No Dev Ready stories with Story Points were found on the backlog of {project}.
+Nothing to plan.
+```
+
+and stop.
+
+## Step 3: Filter Out Stories That Already Have Child Tasks
+
+For each candidate from Step 2, fetch the work item with `mcp__azure-devops__wit_get_work_item` expanding `relations`. If the item has any `System.LinkTypes.Hierarchy-Forward` relation pointing at a `Task`, mark it as **already broken down** and skip it.
+
+Present a one-line summary of what was skipped:
+
+```
+Skipped {n} stories that already have child tasks:
+  - AB#{id}: {title}  ({k} existing tasks)
+  - ...
+```
+
+If after filtering there are zero stories left, report "All Dev Ready backlog stories already have tasks — nothing to plan." and stop.
+
+## Step 4: Present the Working List
+
+Show the remaining stories the user is about to walk through:
+
+```
+Found {n} Dev Ready stories with Story Points and no child tasks on the {project} backlog:
+
+| #  | ID       | Title                                    | Points |
+|----|----------|------------------------------------------|--------|
+| 1  | AB#4521  | COM - Admin can export payments to CSV   |   5    |
+| 2  | AB#4523  | COM - Add bulk approval workflow         |   8    |
+| 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.
+
+Continue? (yes / cancel)
+```
+
+**Wait for the user.** If `cancel`, stop with no changes.
+
+## Step 5: Per-Story Task Breakdown (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.
+
+### 5b. Map Story Points → total hour budget
+
+Use this rough mapping (calibrated to ~6 productive hours per day):
+
+| Points | Hour budget | Notes |
+|--------|-------------|-------|
+| 1  |  4 hrs  | trivial change |
+| 2  |  8 hrs  | small, one-layer change |
+| 3  | 14 hrs  | one feature slice, modest tests |
+| 5  | 24 hrs  | cross-layer or new component |
+| 8  | 40 hrs  | multi-area, real unknowns |
+| 13 | 64 hrs  | large feature — should probably be split |
+| 21 | 100 hrs | very large — almost certainly split |
+
+If the points value isn't on the Fibonacci scale, round to the nearest entry above.
+
+### 5c. Tailor the task list (hybrid template)
+
+Start from this template, then **add, remove, or rename** tasks based on what the AC actually describes:
+
+| 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).
+
+### 5d. Show the proposal
+
+```
+─────────────────────────────────────────────────────────────
+AB#{id}: {title}      ({points} pts → {budget} hrs total)
+─────────────────────────────────────────────────────────────
+
+Proposed child tasks:
+
+| # | 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**|
+
+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
+- `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
+
+For each approved task, call `mcp__azure-devops__wit_create_work_item` with:
+
+- **project**: the chosen project
+- **workItemType**: `Task`
+- **title**: the task title (with prefix)
+- **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 (which is the root)
+  - `System.AreaPath` — copy from the parent
+
+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.
+
+### 5f. Confirm per-story result
+
+```
+✓ AB#{id}: created {k} child tasks ({budget} hrs total)
+```
+
+Then move to the next story.
+
+## Step 6: Final Summary
+
+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)
+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
+- ...
+
+Next steps:
+  /quote AB#{id}      — re-estimate any story whose budget felt off
+  /implement AB#{id}  — start working on a planned story
+```
+
+Do not assign tasks, change parent state, or add tags unless the user explicitly asks — those are downstream decisions.

package/templates/commands/resolve-feedback.md

@@ -0,0 +1,167 @@
+Resolve unresolved comment threads on a pull request. Usage: `/resolve-feedback <pr-id>` (or `/resolve-feedback` to auto-detect from the current branch).
+
+This is the lightweight counterpart to `/rework`. It targets **PR comment threads** specifically — read each active thread, implement the fix, push, then reply to and resolve the thread on the PR. No Task creation, no hours tracking, no UAT gate. Use `/rework` when feedback spans the whole work item or requires a new round of full quality checks.
+
+## Step 1: Identify the Pull Request
+
+Parse `$ARGUMENTS`:
+
+- **PR id given** (`142`, `#142`, `!142`) — strip non-digits and use as the PR id.
+- **No argument** — find the PR for the current branch:
+  1. Get current branch via `git rev-parse --abbrev-ref HEAD`.
+  2. Call `repo_list_pull_requests_by_repo_or_project` filtered to `sourceRefName: refs/heads/<branch>` and `status: active`.
+  3. If exactly one match, use it. If zero or multiple, ask the user which PR id to target — do not guess.
+
+Fetch the PR via `repo_get_pull_request_by_id`. Record:
+- `pullRequestId`, `title`, `status`
+- `sourceRefName` (the branch holding the fixes) and `targetRefName`
+- Linked work item id(s) from artifact links — used only for context, not modified by this command.
+
+## Step 2: List Active Comment Threads
+
+Call `repo_list_pull_request_threads` for the PR. Filter the returned threads to the ones that need a response:
+
+**Include a thread when all of these are true:**
+- `status` is `active` or `pending` (statuses `1` or `6`). Skip `fixed`, `wontFix`, `closed`, `byDesign`.
+- It contains at least one comment authored by a real reviewer (`commentType` is `text`, not `system`).
+- It is not a system-generated thread (vote changes, policy violations, build failures, work-item link additions, etc. — these have `commentType: system` or no real comments).
+- It is not authored exclusively by the current PR author. A thread where the PR author is talking to themselves with no reviewer input is not feedback to resolve. (Use the PR `createdBy.id` as the author id.)
+
+For each remaining thread, capture:
+- `threadId`
+- `threadContext` — `filePath`, `rightFileStart.line` / `leftFileStart.line` (may be null for PR-level threads)
+- Full comment chain via `repo_list_pull_request_thread_comments` — author, date, body. Inline images in comments often carry critical context; if a comment body contains an `<img src="...">` pointing to an Azure DevOps attachment, download and view it via WebFetch before proposing a fix.
+
+If there are zero qualifying threads, tell the user `No unresolved reviewer threads on PR #{id}.` and stop.
+
+## Step 3: Switch to the PR Branch
+
+Before reading code or proposing fixes, make sure local state matches the PR:
+
+1. `git fetch`
+2. If the current branch ≠ `sourceRefName` (stripping `refs/heads/`): `git checkout <source-branch>`. If the branch does not exist locally, `git checkout -b <source-branch> origin/<source-branch>`.
+3. `git pull --ff-only` — refuse to proceed on a dirty or diverged working tree; ask the user to resolve it first rather than auto-stashing or force-resetting.
+
+## Step 4: Triage and Propose Responses
+
+For each qualifying thread, read the referenced code (use `threadContext.filePath` + line) and decide one of:
+
+- **fix** — code change needed. Draft the change in your head and capture which files will be touched.
+- **reply-only** — answers the reviewer's question without a code change (clarification, link to existing code, explanation of intentional design). Capture the reply text.
+- **defer** — out of scope for this round; reply explaining why and leave the thread `active`. Do not silently skip.
+
+Present the full triage to the user before touching any code:
+
+```
+PR #{id}: {title}
+Branch: {source-branch} → {target-branch}
+Active reviewer threads: {count}
+
+## Thread 1 — {file}:{line}  (or "PR-level" if no file context)
+Reviewer ({name}, {date}):
+> {comment excerpt — first ~200 chars}
+{additional reply chain summarized in 1 line each, if any}
+
+Proposed action: FIX
+Files to change:
+  - {path} — {what changes}
+  - {path} — {what changes}
+Reply on resolve: "{short summary that will be posted with the resolution}"
+
+## Thread 2 — {file}:{line}
+Reviewer ({name}, {date}):
+> {comment excerpt}
+
+Proposed action: REPLY-ONLY (no code change)
+Reply: "{text to post}"
+
+## Thread 3 — PR-level
+Reviewer ({name}, {date}):
+> {comment excerpt}
+
+Proposed action: DEFER (out of scope for this round)
+Reply: "{text explaining why this will be handled separately}"
+
+---
+Approve this plan? (yes / edit <n>: <change> / skip <n> / no)
+```
+
+**Wait for the user's response.** Apply edits and re-present until the user replies `yes`. `skip <n>` removes a thread from this round entirely — it stays active on the PR and gets no reply.
+
+## Step 5: Implement the Fixes
+
+For each thread marked **fix** in the approved plan:
+
+1. Make the code change. Use the `backend` / `frontend` / `legacy` agents when the change is non-trivial; small targeted edits can go through `Edit` directly.
+2. Add or update tests when the fix changes observable behavior. A reviewer comment that says "this doesn't handle empty input" implies a missing test case — add it. Do not add tests for pure rename/comment/formatting fixes.
+
+Implement all fixes before moving to validation — batching keeps the build/test cycle short.
+
+## Step 6: Validate
+
+Run in this order. Stop and fix on the first failure before continuing.
+
+1. **Build** — via the `build-validator` agent. Build must be clean.
+2. **Lint** — `dotnet format` for `.cs` changes, ESLint for `.ts`/`.tsx` changes (only on touched files; full-repo lint runs are wasteful here).
+3. **Tests** — run the test suites that cover the files you touched (`test-runner` agent). If a touched file has no test coverage, call that out in the final summary rather than silently skipping.
+
+If validation fails after a reasonable fix attempt, stop and report — do not push broken code to resolve a comment.
+
+## Step 7: Confirm Before Pushing
+
+Show the user exactly what will happen next:
+
+```
+Validation passed.
+
+Changes ready to push to {source-branch}:
+{git diff --stat output}
+
+About to:
+  1. git push origin {source-branch}
+  2. For each FIX thread:   reply with the resolution summary + mark as Fixed (status 2)
+  3. For each REPLY-ONLY:    reply with the response + mark as Closed (status 4)
+  4. For each DEFER thread:  reply with the deferral note + leave status Active
+
+Proceed? (yes / no)
+```
+
+**Wait for `yes`.** Anything else aborts without pushing or touching the PR.
+
+## Step 8: Push and Update the PR
+
+1. `git push origin <source-branch>`.
+2. For each thread in the approved plan, in order:
+   - Call `repo_reply_to_comment` with the reply text. Reference the new commit SHA in FIX replies (e.g. `Fixed in {sha} — {one-line summary of what changed}`).
+   - Call `repo_update_pull_request_thread` to set `status`:
+     - **fix** → `fixed` (2)
+     - **reply-only** → `closed` (4)
+     - **defer** → leave as `active` (do not call the update; only the reply was posted)
+3. After every thread has been processed, post one PR-level summary comment via `repo_create_pull_request_thread` (new top-level thread, status `closed`):
+
+   ```
+   Resolved review feedback in {sha}:
+   - {N} threads addressed with code fixes
+   - {M} threads answered without code changes
+   - {K} threads deferred ({reason summary})
+   ```
+
+   Skip the summary comment if only one thread was touched — the reply on that thread already says everything.
+
+4. Do **not** change the work item state, do **not** create Tasks, do **not** log hours. Those belong to `/rework`. Leave the PR vote alone — the reviewer drives the next vote when they see the resolved threads.
+
+## Step 9: Final Report
+
+Print to the user:
+
+```
+PR #{id} — feedback resolved
+  Branch:       {source-branch} ({sha})
+  Fixed:        {N} thread(s)
+  Replied:      {M} thread(s)
+  Deferred:     {K} thread(s)
+  Files touched: {file count}
+  Tests added/updated: {test file count, or "none — no behavior change"}
+```
+
+If any thread was deferred, list those thread ids explicitly so the user can decide whether they need to file a follow-up work item or address them in a later round.

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -3,6 +3,8 @@
 
 This project uses [Claude Kit](https://github.com/Christopher-Waters/claude-kit) — a standardized set of agents, hooks, MCP servers, and workflows installed via `npx @chris1807/claude-kit init`.
 
+> **This workflow is built for Azure DevOps.** Work items, branches, pull requests, releases (as iterations), and CD pipelines all live in Azure DevOps. The slash commands below talk to it through the Azure DevOps MCP server — `AB#1234` ids refer to Azure DevOps work items, PR numbers refer to Azure Repos pull requests, and pipeline ids refer to Azure Pipelines build definitions. If your project lives somewhere else (GitHub, GitLab, Jira), these commands will not work as-is.
+
 ### Agent Pipeline
 
 When given a task, Claude Code can delegate through specialized agents:
@@ -51,7 +53,7 @@ These run automatically — no action needed:
 
 | Server | What It Does |
 |--------|-------------|
-| **Azure DevOps** | Work items, pipelines, repos, wiki |
+| **Azure DevOps** *(core — drives every slash command)* | Work items, repos, pull requests, pipelines, wiki, test plans, advanced security |
 | **Playwright** | Browser testing (navigate, click, fill, screenshot) |
 | **MongoDB** | Direct database queries and updates |
 | **Microsoft Teams** | Send/read team messages and notifications |
@@ -200,6 +202,7 @@ All deployment and release operations are available as slash commands:
 |---|---|---|
 | `/implement` | `/implement AB#1234` | Summarize work item → approve plan → implement → PR |
 | `/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 |
 | `/create-release` | `/create-release 23` | Group work items into Release #23 |
 | `/deploy-release` | `/deploy-release 23 staging` | Cherry-pick release to environment |
@@ -208,6 +211,7 @@ All deployment and release operations are available as slash commands:
 | `/promote` | `/promote staging production` | Promote all code between environments |
 | `/rollback` | `/rollback AB#1234 production` | Revert commits on an environment |
 | `/status` | `/status release 24` | Check release, pipeline, or work item status |
+| `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose child tasks with hours |
 | `/cleanup-branches` | `/cleanup-branches` | Delete merged branches |
 
 The CD pipeline is only triggered manually when pushing directly to an environment branch. For feature/work branches, the pipeline triggers on PR merge.