@chris1807/claude-kit 2.1.8 → 2.1.9

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.9",
+  "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/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 |