@chris1807/claude-kit 2.1.49 → 2.1.50

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.49",
+  "version": "2.1.50",
   "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/commands/create-work-item.md

@@ -195,6 +195,8 @@ For a **Bug**, **User Story**, or **Hot Fix**, every work item this command crea
 
 Estimate using the same rubric as `/quote`: the **modified Fibonacci scale** (`1, 2, 3, 5, 8, 13, 21`), calibrated for a **senior developer working with Claude assistance** in a codebase they know. Don't pad for ramp-up, routine architectural decisions, or stack familiarity — only for things a senior cannot shortcut: genuinely novel work, unresolved open questions, cross-team coordination, external dependencies. If the work looks larger than 21 points, recommend splitting the item instead of proposing a number.
 
+Repetition and boilerplate are assisted work — price them near the bottom of the range and size the item by its hardest distinct problem, not by how many files it touches. The full assisted / not-assisted breakdown lives in `/quote` Step 2; that file is the authority if the two ever drift.
+
 Present the estimate:
 
 ```

package/templates/commands/implement.md

@@ -194,9 +194,9 @@ Propose the hours from the parent's Story Points (this mirrors `/plan-backlog` S
 | 13 | 48 hrs  |
 | 21 | 75 hrs  |
 
-Calibrated for a **senior developer** at ~6 productive hours per day — the discount is already in the numbers, so don't apply a second one. Round non-Fibonacci point values up to the nearest row. Add 20–30% for `spike` / `research` / `unknown-stack` tags.
+Calibrated for a **senior developer working with Claude assistance** at ~6 productive hours per day — both discounts are already in the numbers, so don't apply a second one. Boilerplate, tests for specified behavior, and mechanical refactors are assisted work; the hours that remain are the human ones (novel decisions, verification, review, UAT). Round non-Fibonacci point values up to the nearest row. Add 20–30% for `spike` / `research` / `unknown-stack` tags.
 
-If the work item has **no Story Points**, estimate the hours from the plan just approved in Step 3 — files to create and modify, plus the unit tests listed — using the same senior calibration. Say which basis you used.
+If the work item has **no Story Points**, estimate the hours from the plan just approved in Step 3 — files to create and modify, plus the unit tests listed — using the same senior-with-Claude calibration. Say which basis you used.
 
 Show the proposal and **wait for the user**:
 

package/templates/commands/plan-backlog.md

@@ -108,21 +108,23 @@ Fetch the work item again (Description and Acceptance Criteria fields) if not al
 
 ### 5b. Map Story Points → total hour budget
 
-> **Assume a senior developer is the implementer.** The hour budget below already discounts for senior-level speed — no ramp-up time, no time spent learning the stack, routine cross-layer work is fast. Do not add a separate "experience" discount on top of these numbers.
+> **Assume a senior developer working with Claude assistance is the implementer.** The hour budget below already discounts for both — no ramp-up time, no time spent learning the stack, routine cross-layer work is fast, and boilerplate/tests/mechanical refactors are assisted. Do not add a separate "experience" or "Claude" discount on top of these numbers.
+>
+> The hours that survive the assist are the human ones: understanding the requirement, the genuinely novel decisions, verification, review turnaround, and UAT. If a budget looks large only because the story touches many files, it's too large.
 
-Use this mapping (calibrated for a senior developer at ~6 productive hours per day):
+Use this mapping (calibrated for a senior developer with Claude assistance, at ~6 productive hours per day):
 
 | Points | Hour budget | Notes |
 |--------|-------------|-------|
 | 1  |  3 hrs  | trivial change |
 | 2  |  6 hrs  | small, one-layer change |
 | 3  | 10 hrs  | one feature slice, modest tests |
-| 5  | 16 hrs  | cross-layer or new component (routine for a senior) |
-| 8  | 28 hrs  | multi-area, real unknowns even for a senior |
+| 5  | 16 hrs  | cross-layer or new component (routine for an assisted senior) |
+| 8  | 28 hrs  | multi-area, real unknowns the assist doesn’t remove |
 | 13 | 48 hrs  | large feature — should probably be split |
 | 21 | 75 hrs  | very large — almost certainly split |
 
-If the points value isn't on the Fibonacci scale, round to the nearest entry above. If the story has tags like `spike`, `research`, or `unknown-stack`, add 20–30% on top — those are the cases where seniority doesn't help.
+If the points value isn't on the Fibonacci scale, round to the nearest entry above. If the story has tags like `spike`, `research`, or `unknown-stack`, add 20–30% on top — those are the cases where neither seniority nor the assist helps.
 
 ### 5c. Draft the single task
 

package/templates/commands/plan-sprint.md

@@ -125,21 +125,23 @@ Fetch the work item again (Description and Acceptance Criteria fields — Repro
 
 ### 6b. Derive the hour budget
 
-> **Assume a senior developer is the implementer.** The hour budget below already discounts for senior-level speed — no ramp-up time, no time spent learning the stack, routine cross-layer work is fast. Do not add a separate "experience" discount on top of these numbers.
+> **Assume a senior developer working with Claude assistance is the implementer.** The hour budget below already discounts for both — no ramp-up time, no time spent learning the stack, routine cross-layer work is fast, and boilerplate/tests/mechanical refactors are assisted. Do not add a separate "experience" or "Claude" discount on top of these numbers.
+>
+> The hours that survive the assist are the human ones: understanding the requirement, the genuinely novel decisions, verification, review turnaround, and UAT. If a budget looks large only because the story touches many files, it's too large.
 
-**If the item has Story Points**, use this mapping (calibrated for a senior developer at ~6 productive hours per day):
+**If the item has Story Points**, use this mapping (calibrated for a senior developer with Claude assistance, at ~6 productive hours per day):
 
 | Points | Hour budget | Notes |
 |--------|-------------|-------|
 | 1  |  3 hrs  | trivial change |
 | 2  |  6 hrs  | small, one-layer change |
 | 3  | 10 hrs  | one feature slice, modest tests |
-| 5  | 16 hrs  | cross-layer or new component (routine for a senior) |
-| 8  | 28 hrs  | multi-area, real unknowns even for a senior |
+| 5  | 16 hrs  | cross-layer or new component (routine for an assisted senior) |
+| 8  | 28 hrs  | multi-area, real unknowns the assist doesn’t remove |
 | 13 | 48 hrs  | large feature — should probably be split |
 | 21 | 75 hrs  | very large — almost certainly split |
 
-If the points value isn't on the Fibonacci scale, round to the nearest entry above. If the item has tags like `spike`, `research`, or `unknown-stack`, add 20–30% on top — those are the cases where seniority doesn't help.
+If the points value isn't on the Fibonacci scale, round to the nearest entry above. If the item has tags like `spike`, `research`, or `unknown-stack`, add 20–30% on top — those are the cases where neither seniority nor the assist helps.
 
 **If the item has no Story Points**, estimate the hours directly from the description, acceptance criteria, and repro steps — judge which row of the table the work most resembles and use that hour budget. Mark the proposal `(no points — estimated from description)` and suggest `/quote AB#{id}` in the final summary. Do **not** set Story Points on the item — that's the user's call.
 

package/templates/commands/quote-backlog.md

@@ -182,7 +182,11 @@ This is read-only reconnaissance. Skip it for non-technical items or when the co
 
 Use the **modified Fibonacci scale**: `1, 2, 3, 5, 8, 13, 21`. Anything larger than 21 is flagged as "needs to be split" rather than given a number.
 
-> **Assume a senior developer working with Claude assistance is the implementer.** Don't pad for ramp-up, routine architectural decisions, or familiarity with the stack — that's already priced into the rubric. Only pad for things a senior *cannot* shortcut: genuinely novel work, missing AC, cross-team coordination, or external dependencies. Do not apply a second seniority discount on top of the rubric.
+> **Assume a senior developer working with Claude assistance is the implementer.** Don't pad for ramp-up, routine architectural decisions, or familiarity with the stack — that's already priced into the rubric. Only pad for things a senior *cannot* shortcut: genuinely novel work, missing AC, cross-team coordination, or external dependencies. Do not apply a second seniority discount, or a second Claude-assistance discount, on top of the rubric.
+
+**Assisted work — price near the bottom of the range:** boilerplate and scaffolding, tests for already-specified behavior, mechanical refactors, applying a known pattern across many files, CRUD/forms/screens that mirror something already in the repo. Repetition is cheap — size the item by its hardest distinct problem, not by how many files it touches.
+
+**Not assisted — never discount:** thin or missing AC, novel design with no precedent, third-party integrations, cross-team dependencies, production data migrations, security/compliance review, hand-verified infra or pipeline work, and human wall-time for review/UAT/deploy gates. These are what justify 8 points and above.
 
 | Points | Looks like |
 |--------|-----------|

package/templates/commands/quote.md

@@ -16,6 +16,29 @@ Use the **modified Fibonacci scale** for story points: `1, 2, 3, 5, 8, 13, 21`.
 
 > **Assume a senior developer working with Claude assistance is the implementer.** Don't pad for ramp-up, routine architectural decisions, or familiarity with the stack. A senior is expected to read the codebase, find existing patterns, and resolve ordinary unknowns without help — that effort is already priced into the rubric below. Only pad for things a senior *cannot* shortcut: genuinely novel work, missing AC, cross-team coordination, or external dependencies.
 
+**Claude assistance is part of the baseline, so price these near the bottom of their range** — the rubric already assumes them, don't discount a second time:
+
+- Boilerplate and scaffolding — DTOs, mappers, interfaces, request/response models, registrations.
+- Writing tests for behavior that's already specified.
+- Mechanical refactors, renames, and applying a known pattern across many files.
+- CRUD endpoints, forms, tables, and screens that mirror something already in the repo.
+- Migrations and scripts with an obvious shape.
+
+**Volume of similar code is cheap.** A story whose size comes mostly from repetition — six more fields, four more columns, another slice of an existing pattern — should not earn points for its file count. Size it by the hardest distinct problem in it, not by how much typing it implies.
+
+**Claude assistance does not compress these — never discount them:**
+
+- Ambiguous, thin, or missing acceptance criteria (see the *not estimable* rule below).
+- Genuinely novel design decisions with no precedent in the codebase.
+- Third-party integrations, external APIs, and anything gated on another system's behavior.
+- Cross-team coordination, sign-off, or a dependency on someone else's work landing first.
+- Data migrations against production data, and anything needing a rollback plan.
+- Security, compliance, or privacy review.
+- Infrastructure, pipeline, and environment work that has to be verified by hand.
+- Human wall-time: code review turnaround, UAT, and deploy gates.
+
+These are what dominate an estimate at 8 points and above. If a big number is driven purely by code volume rather than by items on this list, the estimate is probably too high.
+
 Rough sizing rubric (calibrated for a senior developer, assisted by Claude, working in a codebase they know):
 
 | Points | Looks like |
@@ -30,7 +53,9 @@ Rough sizing rubric (calibrated for a senior developer, assisted by Claude, work
 
 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, work that mirrors an existing implementation, or anything where the senior will recognize the pattern immediately.
+Adjust downward for: pure config changes, mechanical refactors with good test coverage, work that mirrors an existing implementation, repetition of an established pattern, or anything where the senior will recognize the pattern immediately.
+
+State the assist in the reasoning when it moved the number — e.g. "5 rather than 8: the three new endpoints follow `PaymentsController` exactly, so the volume is assisted work; the only real unknown is the reconciliation rule." That makes the estimate reviewable instead of asserted.
 
 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).