@chris1807/claude-kit 2.0.0

package/templates/commands/cherry-pick.md

@@ -0,0 +1,96 @@
+Cherry-pick specific work items to an environment. Usage: `/cherry-pick <work-item-ids> <environment>`
+
+Parse `$ARGUMENTS` to extract:
+- **Work item IDs**: one or more IDs (e.g., "AB#1234 AB#1235" or "1234, 1235")
+- **Target environment**: the environment to deploy to (e.g., "staging", "production")
+
+## Step 1: Read the Work Items
+
+Fetch each work item from Azure DevOps via MCP. Present the list:
+
+```
+## Cherry-Pick to {environment}
+
+| ID | Type | Title | State |
+|----|------|-------|-------|
+| AB#1234 | User Story | Add payment export | Ready for Testing |
+| AB#1235 | Bug | Fix login redirect | Ready for Testing |
+
+Cherry-pick {count} work items to {environment}? (yes/no)
+```
+
+Wait for confirmation.
+
+## Step 2: Find Commits
+
+For each work item, find associated commits using `repo_search_commits` with `includeWorkItems: true`, or by searching for `AB#{id}` in commit messages on the source branch.
+
+If no commits are found for a work item, STOP and report which work item has no associated commits.
+
+## Step 3: Create Cherry-Pick Branch
+
+Determine the target environment branch. Do NOT hardcode branch names — check the project's CLAUDE.md or pipeline configuration.
+
+```bash
+git checkout <target-environment-branch>
+git pull origin <target-environment-branch>
+git checkout -b cherry-pick/<date>-to-<environment>
+```
+
+## Step 4: Cherry-Pick Commits
+
+Cherry-pick commits for each work item in chronological order:
+
+```bash
+git cherry-pick <commit-hash>
+```
+
+If conflicts arise, STOP and report them. Do not resolve automatically. Present recovery options:
+
+```
+CONFLICT while cherry-picking AB#1235 (commit def5678)
+
+Conflicting files:
+- src/API/Controllers/PaymentController.cs
+
+Options:
+1. Skip this work item and continue with the rest
+2. Abort the entire cherry-pick and clean up
+3. I will resolve the conflict manually — wait for me
+
+Which option? (1 / 2 / 3)
+```
+
+- **Option 1:** Run `git cherry-pick --skip` and continue with remaining work items. Note the skipped item in the summary.
+- **Option 2:** Run `git cherry-pick --abort`, delete the cherry-pick branch, and switch back to the original branch.
+- **Option 3:** Wait for the user to resolve conflicts and run `git cherry-pick --continue`, then proceed.
+
+Track progress:
+```
+Cherry-picking:
+[x] AB#1234: Add payment export (2 commits)
+[ ] AB#1235: Fix login redirect (1 commit) — CONFLICT
+```
+
+## Step 5: Push and Create PR
+
+1. Push: `git push -u origin HEAD`
+2. Create a PR via Azure DevOps MCP:
+   - **sourceRefName**: `refs/heads/cherry-pick/<date>-to-<environment>`
+   - **targetRefName**: `refs/heads/<target-environment-branch>`
+   - **title**: `Cherry-pick AB#1234, AB#1235 → {Environment}`
+   - **description**: List all work items with IDs and titles
+3. Link all work items to the PR via `wit_link_work_item_to_pull_request`
+
+## Step 6: Present Summary
+
+```
+Cherry-pick PR created for {environment}.
+
+PR: {pr-url}
+Work items:
+- AB#1234: Add payment export
+- AB#1235: Fix login redirect
+
+Merge the PR to trigger the CD pipeline for {environment}.
+```

package/templates/commands/cleanup-branches.md

@@ -0,0 +1,73 @@
+Clean up merged branches. Usage: `/cleanup-branches [--dry-run]`
+
+If `$ARGUMENTS` contains "dry-run" or "--dry-run", only list branches that would be deleted — do not delete them.
+
+## Step 1: Find Merged Branches
+
+Find all local and remote branches that have been fully merged into the current branch:
+
+```bash
+git branch --merged
+git branch -r --merged
+```
+
+Exclude protected branches — never delete these:
+- `main`, `master`, `develop`, `development`
+- `staging`, `Staging`
+- `Dev`, `QA`
+- Any branch listed in the project's CLAUDE.md Pipeline Configuration table
+
+## Step 2: Identify Candidates
+
+Filter to only feature/work branches that follow our naming conventions or common patterns:
+
+- `feature/*`, `story/*`, `bugfix/*`, `hotfix/*`, `work/*`
+- `release/*-to-*`, `cherry-pick/*`, `revert/*`
+- Task branches (e.g., `T3796`, `U3297`)
+
+Present the list:
+
+```
+## Branch Cleanup
+
+### Branches to delete ({count}):
+| Branch | Last Commit | Merged Into |
+|--------|-------------|-------------|
+| story/AB#4521-admin-export | 2026-03-18 | develop |
+| bugfix/AB#4589-login-plus-sign | 2026-03-19 | develop |
+| release/24-to-staging | 2026-03-21 | staging |
+| cherry-pick/2026-03-22-to-production | 2026-03-22 | main |
+
+### Protected (will NOT be deleted):
+- main, develop, staging
+
+Delete {count} merged branches? (yes/no)
+```
+
+If `--dry-run`, show the list but do NOT ask for confirmation and do NOT delete.
+
+Wait for confirmation before proceeding.
+
+## Step 3: Delete
+
+For each confirmed branch:
+
+```bash
+# Delete local branch
+git branch -d <branch-name>
+
+# Delete remote branch
+git push origin --delete <branch-name>
+```
+
+Report results:
+
+```
+Cleaned up {count} branches.
+
+Deleted:
+- story/AB#4521-admin-export (local + remote)
+- bugfix/AB#4589-login-plus-sign (local + remote)
+- release/24-to-staging (remote only)
+- cherry-pick/2026-03-22-to-production (remote only)
+```

package/templates/commands/create-release.md

@@ -0,0 +1,65 @@
+Create a new release. Follow this workflow:
+
+## Step 1: Determine Release Number
+
+Check existing iterations in the project via Azure DevOps MCP (`work_list_iterations`) to find iterations that follow the `Release #N` naming pattern. The new release number is the next sequential number.
+
+If `$ARGUMENTS` is provided, use it as the release name (e.g., `$ARGUMENTS` = "24" creates "Release #24").
+
+## Step 2: Gather Work Items for the Release
+
+Ask the user which work items to include. They may provide:
+- A list of work item IDs (e.g., "AB#1234, AB#1235, AB#1236")
+- A query (e.g., "all completed user stories in the current sprint")
+- A state filter (e.g., "all items in Ready for Testing")
+
+Use the Azure DevOps MCP to search/query for the specified work items. Present the list for confirmation:
+
+```
+## Release #{N}
+
+| ID | Type | Title | State |
+|----|------|-------|-------|
+| AB#1234 | User Story | Add payment export | Ready for Testing |
+| AB#1235 | Bug | Fix login redirect | Ready for Testing |
+| AB#1236 | User Story | View history | Ready for Testing |
+
+Create this release with {count} work items? (yes/no)
+```
+
+Wait for confirmation before proceeding.
+
+## Step 3: Create the Release Iteration
+
+Create a new iteration in Azure DevOps via `work_create_iterations`:
+- **Name**: `Release #{N}`
+- **Start date**: today
+- No finish date (set when deployed to production)
+
+## Step 4: Assign Work Items to the Release
+
+Use `wit_update_work_items_batch` to set the Iteration Path on each work item to the new release iteration:
+- **path**: `/fields/System.IterationPath`
+- **value**: `{project}\Release #{N}`
+
+## Step 5: Tag Work Items
+
+Use `wit_update_work_items_batch` to add a release tag to each work item:
+- **path**: `/fields/System.Tags`
+- **value**: append `release-{N}` to existing tags
+
+## Step 6: Confirm
+
+Present the final summary:
+
+```
+Release #{N} created with {count} work items.
+
+Work items assigned:
+- AB#1234: Add payment export
+- AB#1235: Fix login redirect
+- AB#1236: View history
+
+To deploy this release to staging:  /deploy-release {N} staging
+To deploy this release to production: /deploy-release {N} production
+```

package/templates/commands/deploy-release.md

@@ -0,0 +1,147 @@
+Deploy release to the next environment. Usage: `/deploy-release <release-number> [environment]`
+
+Parse `$ARGUMENTS` to extract:
+- **Release number**: required (e.g., "23" or "#23")
+- **Target environment**: optional — if not provided, auto-detect the next environment in the promotion flow
+
+## Step 1: Read the Release
+
+Query Azure DevOps for all work items tagged with `release-{N}` or assigned to the `Release #{N}` iteration using `search_workitem` or `wit_get_work_items_for_iteration`.
+
+Present the release contents:
+
+```
+## Release #{N} — Deploy to {environment}
+
+| ID | Type | Title | State | Branch |
+|----|------|-------|-------|--------|
+| AB#1234 | User Story | Add payment export | Ready for Testing | story/AB#1234-add-payment-export |
+| AB#1235 | Bug | Fix login redirect | Ready for Testing | bugfix/AB#1235-fix-login-redirect |
+
+{count} work items in this release.
+```
+
+If no work items are found, STOP and report the error.
+
+## Step 2: Determine Target Environment
+
+If the user specified an environment, use it. Otherwise, auto-detect by checking which environment the work items are currently in:
+
+| Current State | Next Environment |
+|---|---|
+| Work items merged to `develop` | Deploy to **staging** |
+| Work items merged to `staging` | Deploy to **production** |
+
+Check which environment branches contain the commits for these work items using `repo_search_commits` with `includeWorkItems: true`.
+
+**Validation:** Verify all work items in the release have commits on the same source branch. If they are inconsistent (e.g., AB#1234 is on `develop` but AB#1235 has no commits), present a warning listing which work items are on which branches and ask the user to confirm the target environment explicitly.
+
+Confirm with the user:
+
+```
+Deploy Release #{N} ({count} work items) to {environment}?
+
+This will:
+1. Create a release branch: release/{N}-to-{environment}
+2. Cherry-pick all commits for the {count} work items
+3. Create a PR targeting the {environment} branch
+
+Proceed? (yes/no)
+```
+
+Wait for confirmation.
+
+## Step 3: Create Release Branch
+
+Determine the target environment branch. Do NOT hardcode branch names — check the project's CLAUDE.md or use the branch-to-environment mapping:
+
+```bash
+# Switch to the target environment branch and pull latest
+git checkout <target-environment-branch>
+git pull origin <target-environment-branch>
+
+# Create the release branch
+git checkout -b release/{N}-to-<environment>
+```
+
+## Step 4: Cherry-Pick Work Item Commits
+
+For each work item in the release:
+
+1. Find the associated commits using `repo_search_commits` with `includeWorkItems: true`, or by searching for `AB#{id}` in commit messages
+2. Cherry-pick each commit in chronological order:
+   ```bash
+   git cherry-pick <commit-hash>
+   ```
+3. If conflicts arise, STOP and report them. Do not resolve automatically. Present recovery options:
+
+```
+CONFLICT while cherry-picking AB#1236 (commit ghi9012)
+
+Conflicting files:
+- src/API/Controllers/HistoryController.cs
+
+Options:
+1. Skip this work item and continue with the rest
+2. Abort the entire release deploy and clean up
+3. I will resolve the conflict manually — wait for me
+
+Which option? (1 / 2 / 3)
+```
+
+- **Option 1:** Run `git cherry-pick --skip` and continue. Note the skipped item in the summary.
+- **Option 2:** Run `git cherry-pick --abort`, delete the release branch, switch back. Report which items were NOT deployed.
+- **Option 3:** Wait for the user to resolve and run `git cherry-pick --continue`, then proceed.
+
+Track progress as you go:
+
+```
+Cherry-picking commits for Release #{N}:
+[x] AB#1234: Add payment export (3 commits)
+[x] AB#1235: Fix login redirect (1 commit)
+[ ] AB#1236: View history (2 commits) — CONFLICT
+```
+
+## Step 5: Push and Create PR
+
+1. Push the release branch: `git push -u origin HEAD`
+2. Create a PR via Azure DevOps MCP:
+   - **sourceRefName**: `refs/heads/release/{N}-to-<environment>`
+   - **targetRefName**: `refs/heads/<target-environment-branch>`
+   - **title**: `Release #{N} → {Environment}`
+   - **description**: List all work items included with their IDs and titles
+3. Link all work items to the PR via `wit_link_work_item_to_pull_request`
+
+## Step 6: Present Summary
+
+```
+Release #{N} PR created for {environment}.
+
+PR: {pr-url}
+Branch: release/{N}-to-{environment} → {target-branch}
+
+Work items included:
+- AB#1234: Add payment export
+- AB#1235: Fix login redirect
+- AB#1236: View history
+
+Next steps:
+- Review and approve the PR
+- Merge triggers the CD pipeline for {environment}
+- Update work item states in Azure DevOps after merge
+```
+
+Do NOT trigger the CD pipeline — it triggers automatically on PR merge.
+
+## Step 7: Notify Team (if Teams MCP is configured)
+
+Send a notification to the project's Teams channel via the Microsoft Teams MCP server:
+
+```
+🚀 Release #{N} PR created for {environment}
+PR: {pr-url}
+Work items: AB#1234, AB#1235, AB#1236
+Awaiting review and merge.
+```
+
+If the Teams MCP server is not configured, skip this step silently.

package/templates/commands/deploy.md

@@ -0,0 +1,65 @@
+Commit, push, and deploy the current changes. Usage: `/deploy [message]`
+
+`$ARGUMENTS` is an optional commit message. If not provided, auto-generate one from the changes.
+
+## Step 1: Pre-flight Checks
+
+1. Run `dotnet build` on any modified .NET projects
+2. If frontend files changed, run `npx tsc --noEmit` in the relevant client directory
+3. If either fails, STOP and report the errors — do not deploy broken code
+
+## Step 2: Review Changes
+
+```bash
+git status --short
+git diff --stat
+```
+
+Present the changes:
+
+```
+## Changes to Deploy
+
+| Status | File |
+|--------|------|
+| M | src/API/Controllers/PaymentController.cs |
+| M | src/Application/Payments/ExportHandler.cs |
+| A | src/Domain/Payments/ExportResult.cs |
+
+{count} files changed. Deploy? (yes/no)
+```
+
+Wait for confirmation.
+
+## Step 3: Commit
+
+1. Stage only the relevant files (never use `git add -A`)
+2. Never stage `.env`, `appsettings.*.json` with real secrets, or `node_modules`
+3. Commit with the provided message or auto-generated one
+4. Always end with: `Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>`
+5. Use HEREDOC format for the commit message
+
+## Step 4: Push
+
+```bash
+git push -u origin HEAD
+```
+
+Push only the current branch. Do NOT cross-push to other branches.
+
+## Step 5: Pipeline (Conditional)
+
+Check if the current branch is an environment branch (a branch that a CD pipeline watches):
+
+- **On an environment branch**: Trigger the appropriate CD pipeline via Azure DevOps MCP. Monitor the build and report status.
+- **On a feature/work branch**: Do NOT trigger. Report that the pipeline will trigger on PR merge.
+
+## Step 6: Report
+
+```
+Deployed successfully.
+
+Branch: {branch}
+Commit: {hash} - {message}
+Pipeline: {triggered | will trigger on PR merge}
+```

package/templates/commands/explain.md

@@ -0,0 +1,49 @@
+Fetch a work item, summarize it, and explain it in plain language. Usage: `/explain <work-item-id>`
+
+Parse `$ARGUMENTS` to extract the work item ID. Accept formats like `AB#1234`, `#1234`, or just `1234`.
+
+## Step 1: Fetch the Work Item
+
+Read the work item from Azure DevOps using the project from the current repo's CLAUDE.md configuration. Expand with `relations` to include child items and links.
+
+If the work item is not found, report the error and stop.
+
+## Step 2: Gather Context
+
+Collect these fields from the work item:
+- Title, type, state, assigned to
+- Description
+- Acceptance criteria
+- Tags
+- Child work items (if any — fetch their titles and states)
+- Parent work item (if any — fetch its title)
+- Linked PRs (if any)
+
+## Step 3: Present the Explanation
+
+Output the following sections:
+
+### Summary
+A 1–2 sentence plain-language summary of what this work item is about. Avoid jargon — explain it as if to someone unfamiliar with the codebase.
+
+### What needs to happen
+A bullet list translating the acceptance criteria and description into concrete actions. If acceptance criteria are vague, interpret them based on the description and title. If there are child work items, use them to inform this list.
+
+### Why it matters
+A short explanation of the business or user value — why this work item exists. Infer this from the description, parent work item context, and tags.
+
+### Current Status
+- **State:** {state}
+- **Assigned To:** {assignedTo or "Unassigned"}
+- **Parent:** {parent title or "None"}
+- **Child Items:** {count completed}/{count total} complete
+- **PRs:** {list of linked PR numbers and their status, or "None yet"}
+
+### Scope & Risks
+Flag anything that looks ambiguous, missing, or potentially risky:
+- Vague acceptance criteria that may need clarification
+- No acceptance criteria at all
+- Large scope (many child items or broad description)
+- Dependencies on other work items
+
+If nothing stands out, say "No concerns — scope looks clear."

package/templates/commands/implement.md

@@ -0,0 +1,170 @@
+Implement work item AB#$ARGUMENTS. Follow this workflow:
+
+## Step 1: Read the Work Item
+
+Read the work item from Azure DevOps via MCP. Extract:
+- **System.WorkItemType** — determines branch prefix
+- **System.Title** — determines branch suffix
+- **Acceptance criteria / description** — needed for implementation
+
+Handle `$ARGUMENTS` as either `1234` or `AB#1234` — strip the `AB#` prefix when calling the MCP API.
+
+### Embedded Images
+
+The description and acceptance criteria fields may contain embedded images (screenshots, mockups, diagrams). These are typically `<img>` tags with `src` URLs pointing to Azure DevOps attachments. **Download and view every embedded image** using WebFetch — they often contain critical visual requirements (UI layouts, expected behavior, error states) that are not described in the text.
+
+### Comments
+
+Read the work item comments via `wit_list_work_item_comments`. Comments often contain clarifications, scope changes, or additional requirements added after the work item was created. Incorporate any relevant information from comments into your understanding of the work item.
+
+## Step 2: Summarize and Confirm
+
+Present a summary of the work item to the user:
+
+```
+## AB#{id}: {title}
+
+**Type:** {work item type}
+**State:** {state}
+**Assigned To:** {assigned to}
+
+### Description
+{description summary}
+
+### Acceptance Criteria
+{acceptance criteria — numbered list}
+
+Does this look correct? Do you have any additional context or requirements?
+```
+
+**Wait for the user to respond.** Do NOT proceed until the user confirms or provides additional context. If they add context, incorporate it into the plan.
+
+## Step 3: Explore & Plan
+
+1. **Explore** the codebase to map relevant files
+2. **Plan** the implementation approach
+
+Present the plan to the user:
+
+```
+## Implementation Plan for AB#{id}
+
+### Approach
+{brief description of how you will implement this}
+
+### Files to Create
+- `path/to/new/file.cs` — {purpose}
+- `path/to/new/file.tsx` — {purpose}
+
+### Files to Modify
+- `path/to/existing/file.cs` — {what changes and why}
+- `path/to/existing/file.tsx` — {what changes and why}
+
+### Files to Delete (if any)
+- `path/to/old/file.cs` — {why it's being removed}
+
+### Agents
+- **backend**: {what it will do}
+- **frontend**: {what it will do}
+
+### Risks / Considerations
+- {any potential issues or trade-offs}
+
+Approve this plan? (yes / no / suggest changes)
+```
+
+**Wait for the user to approve the plan.** Do NOT start implementation until the user approves. If they suggest changes, revise the plan and present it again.
+
+## Step 4: Create Feature Branch
+
+Only create the branch after the plan is approved.
+
+Capture the current branch as the PR target — do NOT hardcode any branch name:
+
+```bash
+BASE_BRANCH=$(git symbolic-ref --short HEAD)
+```
+
+Determine the branch prefix from the work item type:
+
+| Work Item Type | Branch Prefix |
+|---|---|
+| Feature | `feature/` |
+| User Story | `story/` |
+| Bug | `bugfix/` |
+| Hot Fix | `hotfix/` |
+| (anything else) | `work/` |
+
+Construct the branch name as `{prefix}AB#{id}-{sanitized-title}`:
+- Sanitize the title: lowercase, replace non-alphanumeric characters (except hyphens) with hyphens, collapse consecutive hyphens, truncate to 50 characters, trim leading/trailing hyphens
+- Example: Feature AB#1234 "Add Payment History Export" → `feature/AB#1234-add-payment-history-export`
+
+Create and switch to the branch:
+```bash
+git checkout -b <branch-name>
+```
+
+If the branch already exists, switch to it with `git checkout <branch-name>` instead of failing.
+
+Remember the `BASE_BRANCH` — you will need it for the PR step.
+
+## Step 5: Implement
+
+1. **Implement** using backend and/or frontend agents according to the approved plan
+2. **Generate mockup** if there are UI changes
+
+## Step 6: Build Validation
+
+Run a build check **before** any other quality checks. Use the `build-validator` agent to verify that all projects compile successfully.
+
+- If the build fails, **fix the errors immediately** and re-run until the build passes
+- Do NOT proceed to review, tests, or lint until the build is clean
+
+## Step 7: Quality Checks
+
+1. **Review** code for quality, security, and Clean Architecture compliance
+2. **Run tests** — unit, integration, and build validation
+3. **Run lint** — ESLint and dotnet format
+
+## Step 8: UAT Gate
+
+### If Hot Fix:
+Skip manual UAT. Present an abbreviated confirmation:
+
+```
+Hot Fix ready. All automated checks passed.
+
+Create PR? (yes/no)
+```
+
+Wait for confirmation before proceeding.
+
+### If Feature, User Story, Bug, or other:
+Generate a UAT checklist from the acceptance criteria and present:
+
+```
+Automated checks passed and the UAT checklist is ready.
+
+## UAT Checklist
+[generated checklist here]
+
+Please manually test the feature using the checklist above.
+
+Did manual testing pass?
+- If YES → reply "testing passed" and I will create the PR
+- If NO  → describe what failed or what behaved unexpectedly
+           and I will investigate and fix before asking you again
+```
+
+Wait for the user's response before proceeding. Do NOT create a PR until confirmed.
+
+## Step 9: Push, Create PR, and Update Work Item
+
+1. Push the branch: `git push -u origin HEAD`
+2. Create a PR via Azure DevOps MCP:
+   - **sourceRefName**: `refs/heads/{branch-name}`
+   - **targetRefName**: `refs/heads/{BASE_BRANCH}` (the branch captured in Step 4)
+   - **title**: `AB#{id}: {work item title}`
+   - **labels**: `["hotfix"]` if the work item type is Hot Fix
+3. Link the PR to the work item via `wit_link_work_item_to_pull_request`
+4. Update the work item status in Azure DevOps