@chris1807/claude-kit 2.1.20 → 2.1.22

package/README.md

@@ -28,7 +28,7 @@ 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`, `/resolve-feedback`, `/deploy`, `/create-release`, `/deploy-release`, `/add-to-release`, `/cherry-pick`, `/promote`, `/rollback`, `/status`, `/cleanup-branches`, `/quote`, `/explain` |
+| **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`, `/close-orphan-tasks`, `/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 |
@@ -220,6 +220,7 @@ your-project/                      ← Project-specific
 │   │   ├── add-to-release.md      # /add-to-release 24 AB#4599
 │   │   ├── status.md              # /status release 24
 │   │   ├── cleanup-branches.md    # /cleanup-branches
+│   │   ├── close-orphan-tasks.md  # /close-orphan-tasks
 │   │   ├── quote.md               # /quote AB#1234
 │   │   └── explain.md             # /explain AB#1234
 │   │
@@ -629,6 +630,7 @@ Claude reviews for:
 | `/quote` | `/quote AB#1234` | Display a work item as a formatted blockquote |
 | `/explain` | `/explain AB#1234` | Summarize and explain a work item in plain language |
 | `/cleanup-branches` | `/cleanup-branches` | Delete merged feature/work branches |
+| `/close-orphan-tasks` | `/close-orphan-tasks --dry-run` | Close open Tasks whose parent is Ready to Deploy / Deployed / Closed |
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.20",
+  "version": "2.1.22",
   "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/reviewer.md

@@ -74,7 +74,20 @@ Check `*.csproj` files for incorrect `<ProjectReference>` entries.
 | Empty states | Components handle no-data scenarios with messages, not blank screens |
 | Accessibility | Semantic HTML, ARIA labels, keyboard navigation |
 
-### 6. Testing
+### 6. Environment Configuration Parity
+
+When the diff adds or modifies keys in any **backend `appsettings.*.json`** or **React `.env*`** file, every parallel environment file should have a corresponding entry (real value, placeholder, or explicit empty) so the app does not silently break in another environment.
+
+| File family | Parallel files to check |
+|-------------|------------------------|
+| `appsettings.json` | `appsettings.Development.json`, `appsettings.Staging.json`, `appsettings.QA.json`, `appsettings.Production.json` — whichever exist in the repo |
+| `.env` | `.env.development`, `.env.staging`, `.env.qa`, `.env.production`, `.env.local`, `.env.example` — whichever exist in the repo |
+
+For each new/changed key, list which environment files have it and which are missing it. Flag any missing entry as a **CRITICAL** issue — the PR should not merge until every environment file is accounted for, even if the value is a placeholder or intentionally blank. If a key is intentionally environment-specific (e.g., only relevant in Production), the diff should still leave a comment in the other files explaining why, or the omission should be called out explicitly in the PR description.
+
+Pipeline variable groups, Key Vault references, and Azure App Configuration entries count as valid sources for an environment — if a key is wired up there for a given environment, the file does not need to repeat it, but the reviewer should verify the wiring exists rather than assume it.
+
+### 7. Testing
 
 | Check | Expectation |
 |-------|-------------|

package/templates/agents/project/deployer.md

@@ -19,6 +19,14 @@ You deploy code changes to Azure environments. Follow the standard sequence for
 1. Run `dotnet build` on any modified .NET projects to verify compilation
 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
+4. **Environment configuration parity** — if `git diff` shows changes to any `appsettings.*.json` or `.env*` file, verify every key added or modified has a corresponding entry in each parallel environment file that exists in the repo:
+
+   | File family | Parallel files to check |
+   |-------------|------------------------|
+   | `appsettings.json` | `appsettings.Development.json`, `appsettings.Staging.json`, `appsettings.QA.json`, `appsettings.Production.json` |
+   | `.env` | `.env.development`, `.env.staging`, `.env.qa`, `.env.production`, `.env.local`, `.env.example` |
+
+   Present a (key × environment) table to the user. For any missing cell, prompt the user to supply a value (real, placeholder, or empty) before pushing, or to confirm the omission is intentional because the key is wired through a pipeline variable group, Key Vault, or App Configuration for that environment. Do NOT push until every missing entry is either filled in or explicitly skipped by the user.
 
 ### Step 2: Commit
 

package/templates/commands/close-orphan-tasks.md

@@ -0,0 +1,86 @@
+Close orphaned tasks — open Tasks whose parent has already moved to a deploy/done state. Usage: `/close-orphan-tasks [scope] [--dry-run]`
+
+An **orphaned task** here means a child Task that is still open while its parent work item has already reached one of these states:
+
+- `Ready to Deploy`
+- `Deployed`
+- `Closed`
+
+When a parent is deployed or closed, leftover open child Tasks just add noise to the board. This command finds them and closes them in a single pass.
+
+Parse `$ARGUMENTS`:
+- If it contains `dry-run` or `--dry-run`, only list the orphaned tasks — do **not** close anything.
+- Any other text is an optional **scope** filter — an Area Path, product prefix (`COM`, `PAY`, …), or iteration to narrow the search. With no scope, search the whole project.
+
+All work items live in the **CSI Development** Azure DevOps project (see CLAUDE.md). Target that project unless the repo's CLAUDE.md says otherwise.
+
+## Step 1: Find Orphaned Tasks
+
+Use the Azure DevOps MCP `wit_query_by_wiql` with a hierarchy link query. The Source is the parent, the Target is the child Task:
+
+```sql
+SELECT [System.Id]
+FROM WorkItemLinks
+WHERE
+  ([Source].[System.State] IN ('Ready to Deploy', 'Deployed', 'Closed'))
+  AND ([System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward')
+  AND ([Target].[System.WorkItemType] = 'Task')
+  AND ([Target].[System.State] NOT IN ('Closed', 'Removed', 'Done'))
+MODE (MustContain)
+```
+
+If a **scope** was given, add the matching constraint to the `[Target]` clause (e.g. `AND [Target].[System.AreaPath] UNDER 'CSI Development\\Compass'`, or `AND [Target].[System.Title] CONTAINS 'PAY'`).
+
+> **Note on state names:** Process templates vary. Some projects close tasks to `Done` instead of `Closed`, or use `Resolved`. If the query returns nothing or errors on an unknown state, first confirm the valid states for the Task type via `wit_get_work_item_type`, then adjust the `NOT IN` list and the close target in Step 3 accordingly.
+
+If the link query is unsupported or returns no usable pairs, fall back to: query all open Tasks in scope with a flat WIQL, fetch each task's parent via `relations`, and keep only those whose parent state is in the three target states.
+
+Fetch the matched tasks (and their parents) in a batch via `wit_get_work_items_batch_by_ids` to get titles, states, assignees, and parent context.
+
+## Step 2: Present the Candidates
+
+```
+## Orphaned Tasks ({count})
+
+| Task | Title | State | Parent | Parent State |
+|------|-------|-------|--------|--------------|
+| AB#4710 | Add export endpoint | Active | AB#4521 | Deployed |
+| AB#4711 | Wire up CSV service | New | AB#4521 | Deployed |
+| AB#4733 | Fix null check | Active | AB#4598 | Closed |
+
+These tasks will be set to **Closed** with a comment noting the parent's state.
+
+Close {count} orphaned tasks? (yes/no)
+```
+
+If `--dry-run`, show the table but do **not** ask for confirmation and do **not** close anything. Stop here.
+
+Otherwise, wait for explicit confirmation before proceeding. Never close tasks without a yes.
+
+## Step 3: Close the Tasks
+
+For each confirmed task, use `wit_update_work_items_batch`:
+- **path**: `/fields/System.State`
+- **value**: `Closed` (or the project's terminal Task state confirmed in Step 1)
+
+Then add a comment on each via `wit_add_work_item_comment` so the auto-close is traceable:
+
+> Auto-closed by `/close-orphan-tasks` — parent AB#{parentId} is in state "{parentState}".
+
+Do not modify the parent items. Do not touch tasks whose parent is in any other state.
+
+## Step 4: Report
+
+```
+Closed {count} orphaned tasks.
+
+| Task | Title | Parent | Parent State |
+|------|-------|--------|--------------|
+| AB#4710 | Add export endpoint | AB#4521 | Deployed |
+| AB#4711 | Wire up CSV service | AB#4521 | Deployed |
+| AB#4733 | Fix null check | AB#4598 | Closed |
+
+Skipped: {n} (state transition not permitted — list any that the board rejected)
+```
+
+If any update was rejected (e.g. a required field or an invalid state transition), list it under **Skipped** with the reason rather than silently dropping it.

package/templates/commands/deploy.md

@@ -7,6 +7,28 @@ Commit, push, and deploy the current changes. Usage: `/deploy [message]`
 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
+4. **Environment configuration parity** — if `git diff` shows changes to any `appsettings.*.json` or `.env*` file, check that every key added or modified in one file has a corresponding entry in every parallel environment file that exists in the repo:
+
+   | File family | Parallel files to check |
+   |-------------|------------------------|
+   | `appsettings.json` | `appsettings.Development.json`, `appsettings.Staging.json`, `appsettings.QA.json`, `appsettings.Production.json` |
+   | `.env` | `.env.development`, `.env.staging`, `.env.qa`, `.env.production`, `.env.local`, `.env.example` |
+
+   Present a table of new/changed keys and which environment files contain them. If any are missing, STOP and prompt:
+
+   ```
+   ⚠ The following keys are missing from one or more environment files:
+
+   | Key | Dev | Staging | QA | Prod |
+   |-----|-----|---------|----|----- |
+   | Foo:Bar | ✅ | ❌ | ❌ | ❌ |
+
+   Add values (real, placeholder, or empty) for the missing environments before pushing?
+   - "add" → I'll prompt for each missing value and update the files
+   - "skip" → confirm the omission is intentional (e.g., key is wired through a pipeline variable group / Key Vault / App Configuration) and continue
+   ```
+
+   If the user picks "add", walk each missing cell, prompt for a value, and write it. If "skip", continue but note the skipped keys in the deploy summary.
 
 ## Step 2: Review Changes
 

package/templates/commands/implement.md

@@ -131,6 +131,14 @@ Run a build check **before** any other quality checks. Use the `build-validator`
 
 1. **Run the full test suite** — every unit test in the repo, plus integration tests. Not just the tests added in this change. A failure in an unrelated test means this change broke something else; treat it as a regression, fix it, and re-run until the entire suite is green
 2. **Run lint** — ESLint and dotnet format
+3. **Environment configuration parity** — if the implementation added or changed any key in `appsettings.*.json` or `.env*`, verify every parallel environment file has a corresponding entry:
+
+   | File family | Parallel files to check |
+   |-------------|------------------------|
+   | `appsettings.json` | `appsettings.Development.json`, `appsettings.Staging.json`, `appsettings.QA.json`, `appsettings.Production.json` |
+   | `.env` | `.env.development`, `.env.staging`, `.env.qa`, `.env.production`, `.env.local`, `.env.example` |
+
+   Present a (key × environment) table. For every missing cell, prompt the user for a value (real, placeholder, or empty) **before creating the PR**. The PR should not be opened until every environment file is accounted for, or the user explicitly confirms the omission is intentional (e.g., the key is supplied via a pipeline variable group, Key Vault, or App Configuration for that environment).
 
 ## Step 8: Code Review
 

package/templates/commands/review.md

@@ -33,6 +33,7 @@ Review PR #$ARGUMENTS in the current project. Automatically:
    - Error handling (are exceptions caught appropriately?)
    - Naming conventions and code style consistency
    - Breaking changes or backwards compatibility issues
+   - **Environment configuration parity** — if the diff adds or changes any key in `appsettings.*.json` or `.env*`, every parallel environment file (Development/Staging/QA/Production for backend; `.env.development`/`.env.staging`/`.env.production`/`.env.example` for React) must have a corresponding entry, or the omission must be called out in the PR description. Build a table of (key × environment) and flag any missing cell as **critical**. Pipeline variable groups, Key Vault, or App Configuration wiring counts as a valid source for a given environment — verify it exists rather than assume it.
    - **Rework-specific (if applicable):** does this diff fully address every item in the rework feedback? Does it regress anything that prior merged PRs delivered?
 
 6. **Draft (do not post yet) the inline comments** for every finding. For each, capture: file path, line number, severity, and the exact comment body you intend to post.

package/templates/commands/rework.md

@@ -220,7 +220,8 @@ Run a build check **before** any other quality checks. Use the `build-validator`
 
 1. **Run the full test suite** — every unit test in the repo, plus integration tests. Not just the tests added in this rework. A failure in an unrelated test means this rework broke something else; treat it as a regression, fix it, and re-run until the entire suite is green
 2. **Run lint** — ESLint and dotnet format
-3. **Acceptance Criteria check** — re-read the work item's full Acceptance Criteria (the same list captured in Step 3). For each AC, identify the test or piece of code that proves it's met. If any AC has no covering test or visible code path, flag it before moving on:
+3. **Environment configuration parity** — if the rework added or changed any key in `appsettings.*.json` or `.env*`, verify every parallel environment file (Development/Staging/QA/Production for backend; `.env.development`/`.env.staging`/`.env.production`/`.env.example` for React — whichever exist in the repo) has a corresponding entry. Present a (key × environment) table. Prompt the user to fill in any missing values (real, placeholder, or empty) **before pushing**, or to explicitly confirm the omission is intentional (e.g., supplied via a pipeline variable group, Key Vault, or App Configuration).
+4. **Acceptance Criteria check** — re-read the work item's full Acceptance Criteria (the same list captured in Step 3). For each AC, identify the test or piece of code that proves it's met. If any AC has no covering test or visible code path, flag it before moving on:
 
    ```
    ⚠ AC #{n} ({short form}) has no covering test or clear code path.

package/templates/infrastructure/CLAUDE-WORKFLOW.md

@@ -213,6 +213,7 @@ All deployment and release operations are available as slash commands:
 | `/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 |
+| `/close-orphan-tasks` | `/close-orphan-tasks [scope] [--dry-run]` | Close open Tasks whose parent is Ready to Deploy / Deployed / Closed |
 
 The CD pipeline is only triggered manually when pushing directly to an environment branch. For feature/work branches, the pipeline triggers on PR merge.