@chris1807/claude-kit 2.1.10 → 2.1.12

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.10",
+  "version": "2.1.12",
   "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/plan-backlog.md

@@ -99,19 +99,21 @@ Fetch the work item again (Description and Acceptance Criteria fields) if not al
 
 ### 5b. Map Story Points → total hour budget
 
-Use this rough mapping (calibrated to ~6 productive hours per day):
+> **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.
+
+Use this mapping (calibrated for a senior developer at ~6 productive hours per day):
 
 | Points | Hour budget | Notes |
 |--------|-------------|-------|
-| 1  |  4 hrs  | trivial change |
-| 2  |  8 hrs  | small, one-layer change |
-| 3  | 14 hrs  | one feature slice, modest tests |
-| 5  | 24 hrs  | cross-layer or new component |
-| 8  | 40 hrs  | multi-area, real unknowns |
-| 13 | 64 hrs  | large feature — should probably be split |
-| 21 | 100 hrs | very large — almost certainly split |
+| 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 |
+| 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 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.
 
 ### 5c. Tailor the task list (hybrid template)
 
@@ -180,6 +182,7 @@ For each approved task, call `mcp__azure-devops__wit_create_work_item` with:
   - `Microsoft.VSTS.Scheduling.RemainingWork` — the same hour estimate
   - `System.IterationPath` — copy from the parent (which is the root)
   - `System.AreaPath` — copy from the parent
+  - `System.AssignedTo` — copy from the parent (pass the parent's `uniqueName` / email if its `System.AssignedTo` value is an identity object). If the parent is unassigned, leave this field unset rather than failing.
 
 Then link the new task as a child of the parent with `mcp__azure-devops__wit_add_child_work_items` (or fall back to `wit_work_items_link` with link type `System.LinkTypes.Hierarchy-Forward` from parent → task).
 

package/templates/commands/quote.md

@@ -14,7 +14,9 @@ Capture: title, type, description, acceptance criteria, attached child items, an
 
 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):
+> **Assume a senior developer 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.
+
+Rough sizing rubric (calibrated for a senior developer working in a codebase they know):
 
 | Points | Looks like |
 |--------|-----------|
@@ -22,13 +24,13 @@ Rough sizing rubric (calibrate against what you can see in the repo, not abstrac
 | **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. |
+| **8** | Multi-area change with meaningful new logic, migrations, or non-trivial edge cases. Unknowns a senior can resolve but that still take real wall-time. |
+| **13** | Large feature, several moving parts, or significant unknowns even for a senior. 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.
+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.
 
 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).
 

package/templates/commands/rework.md

@@ -149,6 +149,7 @@ If the user provided hours (suggested or overridden):
      - `Microsoft.VSTS.Scheduling.RemainingWork` — the agreed hours
      - `System.AreaPath` — same as the parent
      - `System.IterationPath` — same as the parent
+     - `System.AssignedTo` — same as the parent (copy the parent's `System.AssignedTo` value; pass the `uniqueName` / email if the parent's value is an identity object). If the parent is unassigned, leave this field unset rather than failing.
 
 2. Link the new Task as a child of the parent work item via `wit_work_items_link`:
    - **type**: `Child` (the parent → child link from the parent's perspective; equivalent to `Parent` from the task's perspective)