@chris1807/claude-kit 2.1.1 → 2.1.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.1",
+  "version": "2.1.3",
   "description": "Claude Code starter kit — agents, hooks, MCP servers, slash commands, and workflow automation",
   "type": "module",
   "bin": {

package/templates/commands/implement.md

@@ -63,6 +63,12 @@ Present the plan to the user:
 ### Files to Delete (if any)
 - `path/to/old/file.cs` — {why it's being removed}
 
+### Unit Tests
+- `path/to/new.tests.cs` — covers {scenario 1}, {scenario 2}, {edge case}
+- `path/to/existing.tests.cs` — adds cases for {new behavior}
+
+List every test file you will add or modify and the scenarios each covers (happy path, error paths, edge cases, regression guards). If a change in this plan has no test coverage, justify why here.
+
 ### Agents
 - **backend**: {what it will do}
 - **frontend**: {what it will do}
@@ -111,7 +117,8 @@ 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
+2. **Write the unit tests** listed in the plan's "Unit Tests" section alongside the implementation — not after
+3. **Generate mockup** if there are UI changes
 
 ## Step 6: Build Validation
 
@@ -123,7 +130,7 @@ Run a build check **before** any other quality checks. Use the `build-validator`
 ## Step 7: Quality Checks
 
 1. **Review** code for quality, security, and Clean Architecture compliance
-2. **Run tests** — unit, integration, and build validation
+2. **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
 3. **Run lint** — ESLint and dotnet format
 
 ## Step 8: UAT Gate

package/templates/commands/rework.md

@@ -79,6 +79,12 @@ Present the plan to the user:
 ### Files to Delete (if any)
 - `path/to/old/file.cs` — {why it's being removed}
 
+### Unit Tests
+- `path/to/new.tests.cs` — covers {scenario the rework adds or fixes}
+- `path/to/existing.tests.cs` — updates assertions for {changed behavior}
+
+List every test file you will add or modify and the scenarios each covers. Rework feedback often reveals missing test coverage on the original implementation — add regression tests that would have caught the original issue. If a rework change in this plan has no test coverage, justify why here.
+
 ### Agents
 - **backend**: {what it will do}
 - **frontend**: {what it will do}
@@ -104,7 +110,8 @@ If the PR was completed/merged and the branch was deleted, create a new branch f
 ## 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
+2. **Write the unit tests** listed in the plan's "Unit Tests" section alongside the implementation — not after. Include any regression test that would have caught the original issue
+3. **Generate mockup** if there are UI changes
 
 ## Step 7: Build Validation
 
@@ -116,7 +123,7 @@ Run a build check **before** any other quality checks. Use the `build-validator`
 ## Step 8: Quality Checks
 
 1. **Review** code for quality, security, and Clean Architecture compliance
-2. **Run tests** — unit, integration, and build validation
+2. **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
 3. **Run lint** — ESLint and dotnet format
 
 ## Step 9: UAT Gate

package/templates/commands/where.md

@@ -0,0 +1,87 @@
+Show which environments a work item is currently deployed to. Usage: `/where <work-item-id>`
+
+Parse `$ARGUMENTS` to extract the work item ID. Accept formats like `AB#1234`, `#1234`, or just `1234`. If no ID is provided, report the error and stop.
+
+## 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` so PR links are included.
+
+If the work item is not found, report the error and stop.
+
+Capture: id, title, type, state, and any linked Pull Request artifacts from `relations`.
+
+## Step 2: Resolve the Environment Chain
+
+Read the **Pipeline Configuration** table from the current repo's `CLAUDE.md`. The table rows define the environment branches in promotion order (top → bottom). Example:
+
+```
+| Branch | Environment | Pipeline(s) |
+|--------|------------|-------------|
+| develop | Dev | ... |
+| staging | Staging | ... |
+| main | Production | ... |
+```
+
+If the table is missing, report that the project has no pipeline configuration in `CLAUDE.md` and stop.
+
+For each environment branch, run `git fetch origin <branch>` first so the local view is current.
+
+## Step 3: Find the Commits for This Work Item
+
+Locate the commits associated with the work item using these signals (combine results, dedupe by SHA):
+
+1. **Linked PRs** — for each linked PR from Step 1, get the merge commit on the target branch (Azure DevOps API: `lastMergeCommit`).
+2. **Commit message search** — `git log --all --grep="AB#<id>\b" --grep="#<id>\b" -i --format=%H` to catch commits whose messages reference the ID.
+3. **Branch name** — `git log --all --format=%H` filtered to commits whose source branch matched `*AB#<id>-*` (use `git for-each-ref` + reflog if needed; skip if not resolvable).
+
+If no commits are found, report:
+```
+AB#<id>: <title>
+No commits found referencing this work item — not deployed to any environment.
+```
+and stop.
+
+## Step 4: Check Each Environment
+
+For each branch in the Pipeline Configuration table, determine whether **any** of the work item's commits is reachable from `origin/<branch>`:
+
+```
+git merge-base --is-ancestor <commit> origin/<branch>
+```
+
+A work item is "in" an environment if at least one of its commits is an ancestor of that environment's branch tip. Track which specific commits landed in which environment so partial deployments are visible.
+
+## Step 5: Display the Result
+
+Output a concise summary in plain language followed by a details block.
+
+```
+AB#<id>: <title>
+<type> · <state>
+
+This work item is in <env list joined with " and ">.
+```
+
+Where `<env list>` is the environments where the work item is present, in promotion order. If none, say "not deployed to any environment yet."
+
+Then a details table:
+
+```
+| Environment | Branch  | Deployed | Commits |
+|-------------|---------|----------|---------|
+| Dev         | develop | Yes      | 2 of 2  |
+| Staging     | staging | Yes      | 2 of 2  |
+| Production  | main    | No       | 0 of 2  |
+```
+
+- **Deployed**: Yes if at least one commit is reachable from the branch tip; No otherwise.
+- **Commits**: how many of the work item's commits are present on that branch (e.g. `1 of 2` flags a partial cherry-pick).
+
+If any linked PRs are still open (not merged), append:
+
+```
+Open PRs:
+- PR #<n> → <target branch> (<status>)
+```
+
+That's it — read-only. Do not modify branches, push, or create PRs.