@chris1807/claude-kit 2.1.20 → 2.1.21

package/package.json

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