@chris1807/claude-kit 2.0.0

package/templates/commands/promote.md

@@ -0,0 +1,71 @@
+Promote all code from one environment to the next. Usage: `/promote [source] [target]`
+
+Parse `$ARGUMENTS` to extract:
+- **Source environment**: optional (e.g., "develop", "staging"). If omitted, auto-detect.
+- **Target environment**: optional. If omitted, use the next environment in the promotion flow.
+
+## Step 1: Determine Source and Target
+
+If not specified, auto-detect based on the current branch:
+
+| Current Branch | Source | Target |
+|---|---|---|
+| `develop` | develop | staging |
+| `staging` | staging | production branch |
+
+If both are specified (e.g., `/promote staging production`), use those directly.
+
+Determine the actual branch names — do NOT hardcode. Check the project's CLAUDE.md or use `git branch -r` to find matching environment branches.
+
+## Step 2: Show What Will Be Promoted
+
+Compare the source and target branches to show what's new:
+
+```bash
+git log <target-branch>..<source-branch> --oneline
+```
+
+Present the changes:
+
+```
+## Promote {source} → {target}
+
+Commits to promote:
+| Commit | Message | Work Item |
+|--------|---------|-----------|
+| abc1234 | Add payment export | AB#1234 |
+| def5678 | Fix login redirect | AB#1235 |
+| ghi9012 | Update dashboard | AB#1236 |
+
+{count} commits will be promoted from {source} to {target}.
+Promote? (yes/no)
+```
+
+If there are no new commits, report that the environments are already in sync.
+
+Wait for confirmation.
+
+## Step 3: Create PR
+
+Create a PR directly from the source branch to the target branch via Azure DevOps MCP:
+
+- **sourceRefName**: `refs/heads/<source-branch>`
+- **targetRefName**: `refs/heads/<target-branch>`
+- **title**: `Promote {source} → {target}`
+- **description**: List all commits and associated work items being promoted
+
+Link any associated work items to the PR.
+
+## Step 4: Present Summary
+
+```
+Promotion PR created: {source} → {target}
+
+PR: {pr-url}
+
+{count} commits included.
+Merge the PR to trigger the CD pipeline for {target}.
+Remember to update work item states in Azure DevOps after merge.
+```
+
+Do NOT merge the PR automatically — the user or a reviewer must approve and merge.

package/templates/commands/quote.md

@@ -0,0 +1,39 @@
+Fetch a work item and display it as a formatted quote block. Usage: `/quote <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: Display the Quote
+
+Format the work item as a quote block:
+
+```
+> **AB#{id}: {title}**
+> **Type:** {type} | **State:** {state} | **Assigned To:** {assignedTo}
+>
+> {description text, stripped of HTML tags, truncated to ~500 chars if long}
+>
+> **Acceptance Criteria:**
+> {acceptance criteria, stripped of HTML tags, truncated to ~500 chars if long}
+```
+
+- Strip all HTML tags from description and acceptance criteria fields, preserving line breaks as `> ` prefixed lines
+- If description or acceptance criteria is empty, omit that section
+- If the work item has child items, append:
+
+```
+>
+> **Child Items:** {count}
+> | ID | Title | State |
+> |----|-------|-------|
+> | AB#{id} | {title} | {state} |
+```
+
+- If the work item has tags, include them: `> **Tags:** {comma-separated tags}`
+
+That's it — just display the quote. Do not modify anything.

package/templates/commands/review.md

@@ -0,0 +1,32 @@
+Review PR #$ARGUMENTS in the current project. Automatically:
+
+1. **Read the full diff** — understand every change in the PR
+2. **Read the linked work item** and verify all acceptance criteria are met
+3. **Review for:**
+   - Clean Architecture boundaries (Domain has no infrastructure dependencies)
+   - Tenant/organizationId enforcement on all database queries
+   - Missing unit or integration tests for new code
+   - `any` types in TypeScript (should be properly typed)
+   - Security issues (OWASP Top 10, hardcoded secrets, SQL/NoSQL injection)
+   - Error handling (are exceptions caught appropriately?)
+   - Naming conventions and code style consistency
+   - Breaking changes or backwards compatibility issues
+4. **Post inline comments** on all findings directly on the PR
+5. **Post a PR-level summary comment** with:
+   - Overall assessment (ready to merge / needs changes)
+   - Count of issues by severity (critical / warning / suggestion)
+   - Acceptance criteria checklist (met / not met / not applicable)
+   - Test coverage assessment
+
+Then ask me:
+```
+Review complete. Summary:
+- X critical issues
+- Y warnings
+- Z suggestions
+- Acceptance criteria: A/B met
+
+Approve, Request Changes, or skip the vote?
+```
+
+Wait for my response before submitting any vote on the PR.

package/templates/commands/rework.md

@@ -0,0 +1,158 @@
+Rework work item AB#$ARGUMENTS based on feedback received after the last pull request. Follow this workflow:
+
+## Step 1: Find the Latest Pull Request
+
+Handle `$ARGUMENTS` as either `1234` or `AB#1234` — strip the `AB#` prefix when calling the MCP API.
+
+Find the most recent PR linked to this work item:
+
+1. Read the work item via MCP and note its **relations** — look for pull request artifact links
+2. For each linked PR, fetch its details via `repo_get_pull_request_by_id` and record the **creationDate**
+3. Identify the **most recent PR** by creation date — this is the baseline for detecting new feedback
+
+Save the PR's `creationDate` as `LAST_PR_DATE` — everything after this timestamp is new feedback.
+
+## Step 2: Gather Rework Feedback
+
+### New Comments
+
+Read the work item comments via `wit_list_work_item_comments`. Filter to only comments created **after** `LAST_PR_DATE`. These contain the rework feedback.
+
+For each new comment, check for embedded images (`<img>` tags with `src` URLs pointing to Azure DevOps attachments). **Download and view every embedded image** using WebFetch — they often contain screenshots of bugs, visual issues, or annotated UI showing what needs to change.
+
+### Description & Acceptance Criteria Changes
+
+Read the work item revisions via `wit_list_work_item_revisions`. Check if the **description** or **acceptance criteria** fields were modified **after** `LAST_PR_DATE`.
+
+- If changed: extract the **current** description and acceptance criteria, and note what was added or modified
+- If unchanged: still read the current description and acceptance criteria — a comment may reference something that was in the original requirements but missing from the implementation
+
+### Always Re-read Requirements
+
+Regardless of whether description/acceptance criteria changed, **always read the full current description and acceptance criteria**. Rework comments often say things like "the original requirement for X is missing" without the description itself changing. You need the full context to understand what the feedback is referring to.
+
+## Step 3: Summarize Rework and Confirm
+
+Present a summary of the rework feedback to the user:
+
+```
+## Rework for AB#{id}: {title}
+
+**Last PR:** #{pr_id} (created {date})
+**New comments:** {count}
+
+### Rework Feedback
+{summarized feedback from new comments — numbered list}
+
+### Requirement Changes (if any)
+{description/acceptance criteria changes since last PR, or "No changes to description or acceptance criteria since last PR"}
+
+### Current Acceptance Criteria
+{full acceptance criteria — numbered list, highlight any that the feedback suggests are not yet met}
+
+Does this capture the rework correctly? Do you have any additional context?
+```
+
+**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 4: Explore & Plan
+
+1. **Explore** the codebase to map relevant files — focus on files changed in the last PR and any new areas needed
+2. **Plan** the rework approach
+
+Present the plan to the user:
+
+```
+## Rework Plan for AB#{id}
+
+### Approach
+{brief description of what needs to change to address the feedback}
+
+### 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 5: Switch to Existing Branch
+
+The work item already has a branch from the previous PR. Switch to it:
+
+1. Get the source branch name from the most recent PR
+2. Switch to that branch: `git checkout <branch-name>`
+3. Pull the latest: `git pull`
+
+If the PR was completed/merged and the branch was deleted, create a new branch from the PR's target branch following the same naming convention as `/implement` Step 4.
+
+## Step 6: Implement
+
+1. **Implement** the rework using backend and/or frontend agents according to the approved plan
+2. **Generate mockup** if there are UI changes
+
+## Step 7: 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 8: 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 9: UAT Gate
+
+### If Hot Fix:
+Skip manual UAT. Present an abbreviated confirmation:
+
+```
+Rework complete. All automated checks passed.
+
+Push changes? (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 — highlight items specific to the rework feedback]
+
+Please manually test the rework using the checklist above.
+
+Did manual testing pass?
+- If YES → reply "testing passed" and I will push the changes
+- 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 push until confirmed.
+
+## Step 10: Push and Update
+
+1. Push the changes: `git push`
+2. Add a comment on the existing PR summarizing what was changed in the rework
+3. Update the work item status in Azure DevOps if needed

package/templates/commands/rollback.md

@@ -0,0 +1,106 @@
+Roll back a deployment in an environment. Usage: `/rollback <work-item-ids-or-commit> <environment>`
+
+Parse `$ARGUMENTS` to extract:
+- **What to revert**: work item IDs (e.g., "AB#1234") or commit hashes, or "last" for the most recent deployment
+- **Target environment**: the environment to roll back (e.g., "staging", "production")
+
+## Step 1: Identify What to Revert
+
+Determine the target environment branch. Do NOT hardcode branch names.
+
+If the user specified:
+- **Work item IDs**: Find the associated commits on the environment branch using `repo_search_commits` with `includeWorkItems: true`
+- **Commit hashes**: Use those directly
+- **"last"**: Find the most recent merge commit on the environment branch via `git log --merges -1 <branch>`
+
+Present the revert plan:
+
+```
+## Rollback on {environment}
+
+Commits to revert:
+| Commit | Message | Work Item |
+|--------|---------|-----------|
+| abc1234 | Add payment export | AB#1234 |
+| def5678 | Fix login redirect | AB#1235 |
+
+This will revert {count} commit(s) on {environment}. Proceed? (yes/no)
+```
+
+Wait for confirmation.
+
+## Step 2: Create Revert Branch
+
+```bash
+git checkout <target-environment-branch>
+git pull origin <target-environment-branch>
+git checkout -b revert/<date>-on-<environment>
+```
+
+## Step 3: Revert Commits
+
+Revert each commit in reverse chronological order (newest first):
+
+```bash
+git revert --no-commit <commit-hash>
+```
+
+After all reverts are staged, create a single commit:
+
+```bash
+git commit -m "$(cat <<'EOF'
+Revert AB#1234, AB#1235 on {environment}
+
+Reverted commits:
+- abc1234: Add payment export
+- def5678: Fix login redirect
+
+Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
+EOF
+)"
+```
+
+## Step 4: Verify
+
+Run pre-flight checks on the reverted code:
+1. `dotnet build` on any .NET projects
+2. `npx tsc --noEmit` on any frontend projects
+3. If either fails, STOP and report — the revert may have introduced inconsistencies
+
+## Step 5: Push and Create PR
+
+1. Push: `git push -u origin HEAD`
+2. Create a PR via Azure DevOps MCP:
+   - **sourceRefName**: `refs/heads/revert/<date>-on-<environment>`
+   - **targetRefName**: `refs/heads/<target-environment-branch>`
+   - **title**: `Rollback: Revert AB#1234, AB#1235 on {Environment}`
+   - **description**: List reverted commits and reason
+3. Link work items to the PR
+
+## Step 6: Present Summary
+
+```
+Rollback PR created for {environment}.
+
+PR: {pr-url}
+Reverted:
+- AB#1234: Add payment export
+- AB#1235: Fix login redirect
+
+Merge the PR to trigger the CD pipeline and deploy the rollback.
+```
+
+For production rollbacks, flag urgency to the user.
+
+## Step 7: Notify Team (if Teams MCP is configured)
+
+Send a notification to the project's Teams channel via the Microsoft Teams MCP server:
+
+```
+⚠️ Rollback PR created for {environment}
+PR: {pr-url}
+Reverting: AB#1234, AB#1235
+Awaiting review and merge.
+```
+
+For production rollbacks, mark the message as urgent. If the Teams MCP server is not configured, skip this step silently.

package/templates/commands/status.md

@@ -0,0 +1,111 @@
+Check the status of a release, pipeline, or work item. Usage: `/status <target>`
+
+Parse `$ARGUMENTS` to determine what to check:
+- **Release**: "release 24" or "r24" → show release status
+- **Pipeline**: "pipeline" or "build" → show recent pipeline runs
+- **Work item**: "AB#1234" or "1234" → show work item status
+- **Environment**: "staging" or "production" → show what's deployed
+- **No argument**: show an overview of everything
+
+## If Release (e.g., `/status release 24`):
+
+Query all work items tagged `release-{N}` or in the `Release #{N}` iteration.
+
+```
+## Release #24 Status
+
+| ID | Type | Title | State | Environment |
+|----|------|-------|-------|-------------|
+| AB#4521 | User Story | Add payment export | Closed | Production |
+| AB#4522 | User Story | Bulk approval workflow | Ready for Testing | Staging |
+| AB#4530 | User Story | Dashboard trends | Ready for Testing | Staging |
+| AB#4589 | Bug | Login plus sign fix | Closed | Production |
+
+Deployed to:
+- Dev: All 4 items
+- Staging: All 4 items
+- Production: 2 of 4 items (AB#4521, AB#4589)
+```
+
+## If Pipeline (e.g., `/status pipeline` or `/status build`):
+
+Check the project's CLAUDE.md for pipeline configuration. Query recent builds for each pipeline.
+
+```
+## Recent Pipeline Runs
+
+| Pipeline | Branch | Status | Time | Build # |
+|----------|--------|--------|------|---------|
+| Compass API | main | Succeeded | 2026-03-22 14:26 | 20260322.1 |
+| Compass Client | main | Succeeded | 2026-03-22 14:27 | 20260322.1 |
+| Compass API | develop | Succeeded | 2026-03-21 10:15 | 20260321.3 |
+```
+
+## If Work Item (e.g., `/status AB#4521`):
+
+Read the work item from Azure DevOps and show its full status.
+
+```
+## AB#4521: Admin Can Export Payment History to CSV
+
+**Type:** User Story
+**State:** Ready for Testing
+**Assigned To:** Chris Waters
+**Release:** Release #24
+**Branch:** story/AB#4521-admin-can-export-payment-history
+**PR:** #287 (merged to develop)
+
+### Linked PRs
+- PR #287 → develop (merged 2026-03-20)
+- PR #291 → staging (merged 2026-03-21)
+
+### Child Tasks
+| ID | Title | State |
+|----|-------|-------|
+| AB#4525 | Add export API endpoint | Closed |
+| AB#4526 | Add CSV service | Closed |
+| AB#4527 | Add export button UI | Closed |
+```
+
+## If Environment (e.g., `/status staging`):
+
+Check the project's CLAUDE.md for the environment branch mapping. Show the last deployment and what's currently deployed.
+
+```
+## Staging Environment
+
+**Branch:** staging
+**Last deployment:** 2026-03-21 15:30 (Build #20260321.2)
+**Pipeline:** Compass API — Succeeded
+
+### Recent merges to staging:
+| Commit | Message | Date |
+|--------|---------|------|
+| a1b2c3d | Release #24 → Staging | 2026-03-21 |
+| d4e5f6a | Cherry-pick AB#4601 | 2026-03-22 |
+```
+
+## If No Argument (e.g., `/status`):
+
+Show a high-level overview.
+
+```
+## Project Status
+
+### Active Releases
+| Release | Work Items | Latest Environment |
+|---------|-----------|-------------------|
+| Release #24 | 6 items | Staging |
+| Release #23 | 4 items | Production |
+
+### Recent Pipelines
+| Pipeline | Last Run | Status |
+|----------|----------|--------|
+| Compass API | 20260322.1 | Succeeded |
+| Compass Client | 20260322.1 | Succeeded |
+
+### Open PRs
+| PR # | Title | Target |
+|------|-------|--------|
+| #292 | AB#4601: Fix bulk approval | develop |
+```

package/templates/hooks/auto-format.sh

@@ -0,0 +1,46 @@
+#!/bin/bash
+# Auto-Format Hook (PostToolUse - Edit/Write)
+# Runs the appropriate formatter on files after they're modified.
+
+INPUT=$(cat)
+
+# Extract the file path
+FILE_PATH=$(echo "$INPUT" | python3 -c "
+import sys, json
+try:
+    data = json.load(sys.stdin)
+    inp = data.get('tool_input', {})
+    print(inp.get('file_path', ''))
+except:
+    pass
+" 2>/dev/null)
+
+if [ -z "$FILE_PATH" ]; then
+    exit 0
+fi
+
+# Get file extension
+EXT="${FILE_PATH##*.}"
+
+case "$EXT" in
+    cs)
+        # .NET files — run dotnet format on the file (quiet, no restore)
+        PROJECT_DIR=$(echo "$FILE_PATH" | grep -oE '.*/src/[^/]+/')
+        if [ -n "$PROJECT_DIR" ] && [ -f "${PROJECT_DIR}*.csproj" ] 2>/dev/null; then
+            dotnet format "$PROJECT_DIR" --include "$FILE_PATH" --no-restore --verbosity quiet 2>/dev/null
+        fi
+        ;;
+    ts|tsx|js|jsx)
+        # TypeScript/JavaScript — find nearest node_modules and run eslint fix
+        DIR=$(dirname "$FILE_PATH")
+        while [ "$DIR" != "/" ]; do
+            if [ -f "$DIR/node_modules/.bin/eslint" ]; then
+                "$DIR/node_modules/.bin/eslint" --fix --quiet "$FILE_PATH" 2>/dev/null
+                break
+            fi
+            DIR=$(dirname "$DIR")
+        done
+        ;;
+esac
+
+exit 0

package/templates/hooks/protected-files.sh

@@ -0,0 +1,52 @@
+#!/bin/bash
+# Protected Files Guard (PreToolUse - Edit/Write)
+# Warns before modifying critical files. Exit code 2 = BLOCK.
+
+INPUT=$(cat)
+
+# Extract the file path
+FILE_PATH=$(echo "$INPUT" | python3 -c "
+import sys, json
+try:
+    data = json.load(sys.stdin)
+    inp = data.get('tool_input', {})
+    print(inp.get('file_path', ''))
+except:
+    pass
+" 2>/dev/null)
+
+if [ -z "$FILE_PATH" ]; then
+    exit 0
+fi
+
+# Files that should never be modified without explicit intent
+BLOCKED_FILES=(
+    "appsettings.Production.json"
+    "appsettings.Staging.json"
+)
+
+for blocked in "${BLOCKED_FILES[@]}"; do
+    if echo "$FILE_PATH" | grep -q "$blocked"; then
+        echo "BLOCKED: Cannot modify production/staging config: $blocked"
+        echo "If you need to change production settings, do it in Azure App Configuration or Key Vault."
+        exit 2
+    fi
+done
+
+# Files that trigger a warning (but allow the edit)
+WARN_FILES=(
+    "CLAUDE.md"
+    ".gitignore"
+    "azure-pipelines.yml"
+    "staticwebapp.config.json"
+    "Program.cs"
+    "DependencyInjection.cs"
+)
+
+for warn in "${WARN_FILES[@]}"; do
+    if echo "$FILE_PATH" | grep -q "$warn"; then
+        echo "WARNING: Modifying critical file: $warn — make sure this change is intentional."
+    fi
+done
+
+exit 0

package/templates/hooks/secret-blocker.sh

@@ -0,0 +1,68 @@
+#!/bin/bash
+# Secret Blocker Hook (PreToolUse - Write/Edit)
+# Blocks file writes that contain hardcoded secrets, API keys, or credentials.
+# Exit code 2 = BLOCK the action.
+
+# Read the tool input from stdin
+INPUT=$(cat)
+
+# Extract the file content being written (new_string for Edit, content for Write)
+CONTENT=$(echo "$INPUT" | python3 -c "
+import sys, json
+try:
+    data = json.load(sys.stdin)
+    tool = data.get('tool_name', '')
+    inp = data.get('tool_input', {})
+    if tool == 'Write':
+        print(inp.get('content', ''))
+    elif tool == 'Edit':
+        print(inp.get('new_string', ''))
+except:
+    pass
+" 2>/dev/null)
+
+if [ -z "$CONTENT" ]; then
+    exit 0
+fi
+
+# Patterns that indicate hardcoded secrets
+BLOCKED=false
+REASON=""
+
+# MongoDB connection strings with credentials
+if echo "$CONTENT" | grep -qE 'mongodb\+srv://[^$\{]+:[^$\{]+@'; then
+    BLOCKED=true
+    REASON="Hardcoded MongoDB connection string with credentials"
+fi
+
+# AWS keys
+if echo "$CONTENT" | grep -qE 'AKIA[0-9A-Z]{16}'; then
+    BLOCKED=true
+    REASON="AWS access key detected"
+fi
+
+# Stripe secret keys (not env var references)
+if echo "$CONTENT" | grep -qE 'sk_live_[a-zA-Z0-9]{20,}'; then
+    BLOCKED=true
+    REASON="Stripe live secret key detected"
+fi
+
+# Private keys
+if echo "$CONTENT" | grep -qE 'BEGIN (RSA |EC |DSA )?PRIVATE KEY'; then
+    BLOCKED=true
+    REASON="Private key detected"
+fi
+
+# Generic password assignments (but not placeholder patterns)
+if echo "$CONTENT" | grep -qiE '"(password|secret|apikey|api_key|token)"\s*:\s*"[^$\{\}][^"]{8,}"' | grep -vqE 'Admin123!|Test123|placeholder|your-.*-here|xxx'; then
+    BLOCKED=true
+    REASON="Possible hardcoded credential"
+fi
+
+if [ "$BLOCKED" = true ]; then
+    echo "BLOCKED: $REASON"
+    echo "Use environment variables or Azure Key Vault instead of hardcoding secrets."
+    exit 2
+fi
+
+exit 0

package/templates/hooks/self-improve.sh

@@ -0,0 +1,7 @@
+#!/bin/bash
+# Self-Improvement Hook
+# Fires on Stop to remind Claude to save learnings from the session.
+# This creates a feedback loop where each session makes the next one better.
+
+echo "📝 Before ending: Did you learn anything new about Chris's preferences, project decisions, or workflow patterns? If so, save it to memory (feedback or project type)."
+echo "📋 Check if project_current_priorities.md needs updating based on work completed this session."