@chris1807/claude-kit 2.1.2 → 2.1.4

package/package.json

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

package/templates/commands/review.md

@@ -1,8 +1,30 @@
 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:**
+1. **Read the full diff** — understand every change in the PR.
+
+2. **Read the linked work item** and gather the full acceptance criteria.
+
+3. **Detect rework context — do this BEFORE judging acceptance criteria.**
+
+   A small diff does not mean a small feature. The PR you are reviewing may be a rework that only addresses targeted feedback, while the bulk of the implementation already shipped in earlier PRs. Judging acceptance criteria against the current diff alone will produce false "not met" findings.
+
+   For each PR linked to the work item (via `relations` / artifact links), fetch its details and classify:
+   - **This PR** — the one being reviewed.
+   - **Prior merged PRs** — `status: completed` and merged before this PR was created. Their changes are already in the target branch.
+   - **Prior abandoned PRs** — ignore for acceptance-criteria coverage; their code is not in the target branch.
+
+   Also scan the work item comments for rework feedback posted after the most recent prior merged PR. That feedback is what the current PR is expected to address.
+
+   Treat the PR as a **rework** if any prior merged PR exists for this work item, OR if the work item has rework feedback comments dated after a prior PR. Otherwise treat it as an **initial PR**.
+
+4. **Evaluate acceptance criteria against the cumulative work, not just this diff.**
+
+   - **Initial PR**: evaluate every acceptance criterion against this PR's diff.
+   - **Rework PR**: evaluate every acceptance criterion against (prior merged PRs' changes already in the target branch) + (this PR's diff). For criteria already satisfied by prior merged PRs, do not flag them as missing — mark them as **previously delivered** and only re-check them if this PR's diff touches the same area in a way that could regress the prior implementation.
+
+   When a rework PR's diff is small, the right question is **"does this diff correctly address the rework feedback, and does it avoid regressing the prior implementation?"** — not "does this diff implement every acceptance criterion from scratch?"
+
+5. **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
@@ -11,20 +33,51 @@ 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
-4. **Post inline comments** on all findings directly on the PR
-5. **Post a PR-level summary comment** with:
+   - **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.
+
+7. **Draft (do not post yet) the PR-level summary comment** with:
+   - **PR type**: Initial PR or Rework (and if rework, list the prior merged PR numbers and the rework feedback being addressed)
    - Overall assessment (ready to merge / needs changes)
    - Count of issues by severity (critical / warning / suggestion)
-   - Acceptance criteria checklist (met / not met / not applicable)
+   - **Acceptance criteria checklist**, with each item marked as one of:
+     - **met (this PR)** — satisfied by changes in this diff
+     - **met (prior PR #N)** — already delivered in a prior merged PR; not in this diff
+     - **not met** — not satisfied by any merged or pending change
+     - **not applicable** — out of scope for this work item
+   - **Rework feedback checklist** (rework PRs only) — each feedback item marked addressed / not addressed
    - Test coverage assessment
 
-Then ask me:
+8. **Preview every comment to me and wait for approval before posting anything to the PR.** Show:
+
+   ```
+   Review drafted — nothing has been posted to PR #{id} yet.
+
+   ## Inline comments ({count})
+   1. {file}:{line} [{severity}] — {comment body}
+   2. ...
+
+   ## PR summary comment
+   {full summary body as it will appear on the PR}
+
+   Reply with one of:
+   - "approve" → post all inline comments and the summary exactly as shown above
+   - "skip"    → post nothing
+   - "edit <number>: <new text>" or "skip <numbers>" → revise/drop specific items, then I'll re-preview before posting
+   ```
+
+   **Wait for my response. Never post any comment to the PR until I reply "approve".** If I edit or skip individual items, apply the changes and re-preview the full set before asking again. "skip" with no numbers means post nothing at all — move directly to step 9 without posting.
+
+9. If I approved, post the inline comments and the summary to the PR. If I skipped, post nothing. Either way, then ask me:
 ```
-Review complete. Summary:
+{Comments posted to PR #{id}. | No comments posted (skipped).}
+- PR type: {Initial | Rework of prior PR(s) #N, #M}
 - X critical issues
 - Y warnings
 - Z suggestions
-- Acceptance criteria: A/B met
+- Acceptance criteria: A met this PR, B met in prior PRs, C not met
+- Rework feedback (if rework): D/E addressed
 
 Approve, Request Changes, or skip the vote?
 ```

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.