@chris1807/claude-kit 2.1.3 → 2.1.5

package/package.json

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

package/templates/commands/quote.md

@@ -1,4 +1,4 @@
-Fetch a work item and display it as a formatted quote block. Usage: `/quote <work-item-id>`
+Fetch a work item and estimate the effort in story points. Usage: `/quote <work-item-id>`
 
 Parse `$ARGUMENTS` to extract the work item ID. Accept formats like `AB#1234`, `#1234`, or just `1234`.
 
@@ -8,32 +8,62 @@ Read the work item from Azure DevOps using the project from the current repo's C
 
 If the work item is not found, report the error and stop.
 
-## Step 2: Display the Quote
+Capture: title, type, description, acceptance criteria, attached child items, any existing `Story Points` / `Effort` field value, and any tags that hint at scope (e.g. `spike`, `research`, `infra`).
 
-Format the work item as a quote block:
+## Step 2: Size the Work
+
+Use the **modified Fibonacci scale** for story points: `1, 2, 3, 5, 8, 13, 21`. Anything that feels larger than 21 should be flagged as "needs to be split" rather than given a number.
+
+Rough sizing rubric (calibrate against what you can see in the repo, not abstract complexity):
+
+| Points | Looks like |
+|--------|-----------|
+| **1** | Trivial change — copy tweak, single config value, one-line fix. No new tests needed. |
+| **2** | Small, well-understood change in one file or one layer. Existing patterns cover it. |
+| **3** | Touches a couple of files / one feature slice. Some new tests. No architectural questions. |
+| **5** | Crosses layers (e.g. API + UI), or introduces a new component/endpoint following existing patterns. Real test coverage needed. |
+| **8** | Multi-area change with meaningful new logic, migrations, or non-trivial edge cases. Some unknowns the implementer will need to resolve. |
+| **13** | Large feature, several moving parts, or significant unknowns. Likely benefits from being split. |
+| **21** | Very large / high uncertainty. Should almost certainly be split into multiple stories. |
+
+Adjust upward for: unclear acceptance criteria, missing UX, data migrations, cross-team coordination, security/compliance review, or anything tagged `spike`/`research`.
+
+Adjust downward for: pure config changes, mechanical refactors with good test coverage, or work that mirrors an existing implementation.
+
+If the item has child items, size each child as well and present the parent's total as the sum (rounded to the nearest Fibonacci number).
+
+## Step 3: Display the Estimate
+
+Output a compact estimate — not a quote block. Format:
 
 ```
-> **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}
+**AB#{id}: {title}**
+**Estimate:** {points} story points{ — confidence: low/medium/high}
+
+**Reasoning:**
+- {bullet on scope / files / layers touched}
+- {bullet on unknowns or risk}
+- {bullet on test/doc burden}
+
+**Comparable to:** {one-line analogy to a similar past story, or "no obvious comparable in recent work"}
 ```
 
-- 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:
+If child items were sized, append:
 
 ```
->
-> **Child Items:** {count}
-> | ID | Title | State |
-> |----|-------|-------|
-> | AB#{id} | {title} | {state} |
+**Child breakdown:**
+| AB# | Title | Points |
+|-----|-------|--------|
+| ... | ...   | ...    |
+| **Total** |  | **{sum}** |
 ```
 
-- If the work item has tags, include them: `> **Tags:** {comma-separated tags}`
+If an existing `Story Points` value is already set on the work item and your estimate differs, call that out explicitly: `**Existing estimate:** {n} (yours differs — {why})`.
+
+If the work looks larger than 21 points, do not assign a number — instead report `**Estimate:** needs to be split` and suggest 2–4 candidate split points based on the acceptance criteria.
+
+## Step 4: Offer to Persist
+
+After displaying the estimate, ask the user: *"Want me to set Story Points = {n} on AB#{id}?"*
 
-That's it — just display the quote. Do not modify anything.
+Only update the work item if the user explicitly says yes. Do not modify anything otherwise.

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?
 ```