@chris1807/claude-kit 2.1.53 → 2.1.54

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.53",
+  "version": "2.1.54",
   "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

@@ -55,6 +55,24 @@ Scan the user's response for:
 
 For each image found, plan to embed it in the final description as an `<img src="{url}">` tag, with the user's surrounding text preserved as context. For non-image links (docs, PRs, related work items), preserve them as `<a href="{url}">{url}</a>` in the relevant section of the draft. Do not strip these — they are often the only ground truth for the requirement.
 
+### Check for prior art (required — do this before drafting)
+
+**Before writing the draft, look for the same process already built somewhere else in the product.** This is not the duplicate check — a duplicate is *the same work already ticketed*. Prior art is *the same process already solved for a different entity, role, or screen*, which the new item should reuse rather than rebuild. The classic shape is "we built X for A; now we want X for B":
+
+> The digital W-9 was built for the **Facility Owner** (AB#3888 → AB#3860), then reused for the **Applicant** (AB#4189) through a shared component set at `Client/src/components/w9/` with a `mode` prop. A later story to give **CDA Trainers** a fillable W-9 (AB#5424) said only "similar process to the facility W-9 process" — naming no work item, no component, no endpoint. That story is a third consumer of an existing wizard whose `W9EntityType` enum already lists `Trainer` on both sides of the stack, but nothing in the item says so, so it reads like a build-from-scratch.
+
+Do all three passes — each finds things the others miss:
+
+1. **The codebase** — search for the noun and the verb in the requirement (`W-9`, `notes`, `export`, `bulk assign`). A `components/` or `shared/` directory, a `mode`/`variant` prop, or an enum listing the new entity alongside existing ones all mean the pattern is already generalized. Say so.
+2. **Work items** — `mcp__azure-devops__search_workitem` for the same process against the other entity. Closed items are the useful ones; they name the components and the decisions.
+3. **Commits** — `repo_search_commits` for the feature name, to find the PR that landed the original.
+
+Record what you find and carry it into the draft's **Prior Art** section (Step 3). Be specific — work item id, file path, component or endpoint name. "Similar to the facility process" is the failure mode this step exists to prevent; it tells the implementer nothing they can act on.
+
+If you find nothing, say so in one line rather than omitting the section — "no prior art found; this is the first {process} in the product" is itself useful, and it tells the reader the search was actually run.
+
+**Prior art also changes the estimate.** A third consumer of a shared component is a fraction of the first one. Carry the finding into Step 4 and say it in the rationale.
+
 ## Step 3: Develop the Plan
 
 Translate the user's free-form requirements into a structured work item draft. The shape depends on the type:
@@ -85,6 +103,11 @@ A Feature is a container — describe the outcome, not the implementation.}
 1. {observable, feature-level outcome that proves the capability landed}
 2. ...
 
+### Prior Art
+- {the same process already built elsewhere — work item id, component/file path,
+  endpoint — and what should be reused vs. built new. One line of "none found"
+  if the Step 2 search came up empty.}
+
 ### Open Questions
 - {anything ambiguous that you couldn't infer}
 ```
@@ -110,6 +133,11 @@ business or user value. Avoid implementation detail — that lives in tasks.}
 ### Out of Scope
 - {anything the user mentioned but that shouldn't block this story}
 
+### Prior Art
+- {the same process already built elsewhere — work item id, component/file path,
+  endpoint — and what should be reused vs. built new. One line of "none found"
+  if the Step 2 search came up empty.}
+
 ### Open Questions
 - {anything ambiguous that you couldn't infer — list as questions, not assumptions}
 ```
@@ -144,6 +172,12 @@ business or user value. Avoid implementation detail — that lives in tasks.}
 ### Environment / Scope
 - {where the bug occurs — browser, environment, role, data condition}
 
+### Prior Art
+- {the same defect already fixed elsewhere, or the same process working correctly
+  for another entity — work item id, component/file path. On a bug this is often
+  the fix itself: "the equivalent path for X was fixed in AB#nnnn." One line of
+  "none found" if the Step 2 search came up empty.}
+
 ### Open Questions
 - {anything you couldn't infer}
 ```
@@ -338,14 +372,14 @@ Verify with `mcp__azure-devops__wit_work_item` (`action: get_type`) rather than
 
 | Draft section | Goes to |
 |---|---|
-| `### Description` | `System.Description` — plus the mockup `<img>`, user-supplied images, `Out of Scope`, `Open Questions` |
+| `### Description` | `System.Description` — plus the mockup `<img>`, user-supplied images, `Out of Scope`, `Prior Art`, `Open Questions` |
 | `### Acceptance Criteria` | `Microsoft.VSTS.Common.AcceptanceCriteria` — **never** also in the description |
 
 **Bug** — its form renders only **Repro Steps** and **System Info**. It has **no Acceptance Criteria field**, and `System.Description` has **no control on the Bug form**, so anything routed there is invisible to a human reader:
 
 | Draft section | Goes to |
 |---|---|
-| `### Description`, `### Steps to Reproduce`, `### Expected Behavior`, `### Actual Behavior`, `### Acceptance Criteria`, `### Open Questions` | `Microsoft.VSTS.TCM.ReproSteps` — composed into one document, each under its own `<h3>`, in that order |
+| `### Description`, `### Steps to Reproduce`, `### Expected Behavior`, `### Actual Behavior`, `### Acceptance Criteria`, `### Prior Art`, `### Open Questions` | `Microsoft.VSTS.TCM.ReproSteps` — composed into one document, each under its own `<h3>`, in that order |
 | `### Environment / Scope` | `Microsoft.VSTS.TCM.SystemInfo` |
 | (the same composed body) | `System.Description` — a labelled **duplicate**, for tools that read it without checking the type. Never unique content. |
 
@@ -355,7 +389,7 @@ Do **not** send `Microsoft.VSTS.Common.AcceptanceCriteria` on a Bug. Still *writ
 
 | Draft section | Goes to |
 |---|---|
-| `### Description`, `### Production Impact`, `### Open Questions` | `System.Description` |
+| `### Description`, `### Production Impact`, `### Prior Art`, `### Open Questions` | `System.Description` |
 | `### Steps to Reproduce`, `### Expected Behavior`, `### Actual Behavior`, `### Environment / Scope` | `Microsoft.VSTS.TCM.ReproSteps` |
 
 **Omit an empty section entirely** — never emit a bare `<h3>` with nothing under it. A heading with no body reads as content that went missing.

package/templates/commands/edit-work-item.md

@@ -79,6 +79,17 @@ links; they'll be preserved.
 
 Scan the response for images and links and preserve them exactly as `/create-work-item` Step 2 describes — an edit must never silently strip an image, attachment URL, or reference link that is already in the description.
 
+### Check for prior art — on newly added scope only
+
+If the change request **adds** scope — a new behavior, a new entity, a new screen, a new role — run the prior-art search from `/create-work-item` Step 2 against **the added part**, and carry the finding into the change set. That file is the authority on how to search and what counts; the short version is three passes (codebase, work items, commits) looking for the same *process* already solved for a different entity, which the item should reuse rather than rebuild.
+
+Two things are different here:
+
+- **Scope the search to the delta, not the item.** An edit that tightens AC 3, fixes a typo, or bumps severity gets no prior-art pass — there is no new work to have precedent. Re-auditing the whole item on every edit is noise, and it buries the one finding that matters when there is one.
+- **Widening scope is exactly when prior art gets missed.** The original draft was searched against the original requirement. "It should also cover CDA trainers" is a *new* requirement that has never been searched, and it arrives as an amendment rather than a new item — so nothing re-runs the check unless this step does.
+
+Fold the result into Step 4's diff as an edit to the description's `### Prior Art` section — **adding that section if the item doesn't have one**, since items created before this rule existed won't. Keep any prior-art lines already there; append rather than replace, the same way every other field on an edit is preserved rather than regenerated.
+
 ## Step 4: Draft the Change Set
 
 Produce a **field-level diff**, not a rewritten item. For every field you propose to touch, show before and after. Fields not listed are not touched.
@@ -108,6 +119,7 @@ Rules for the draft:
 
 - **Preserve, don't regenerate.** Keep existing wording that the change request doesn't touch. Never drop existing `<img>` tags, attachment URLs, or reference links.
 - **Points follow the `/quote` rubric** — modified Fibonacci (`1, 2, 3, 5, 8, 13, 21`), calibrated for a senior developer working with Claude assistance. Only propose a change if the scope actually moved. If the revised item now looks bigger than 21 points, recommend splitting it into a Feature instead of writing the number.
+- **Prior art moves the number too, and it can move it *down*.** Added scope normally raises points, but scope that turns out to be a second or third consumer of something already built often costs less than the first one did — sometimes less than the raise it would otherwise earn. If the Step 3 search found precedent, say so in the points rationale rather than pricing the addition as new work.
 - **Never point a Feature** and never change a Feature's `System.State`.
 - **Prefix rule holds** — if the title changes, it keeps its `PREFIX - ` prefix from the project's CLAUDE.md table.
 
@@ -205,9 +217,9 @@ Render every Markdown section to HTML first — Azure DevOps description and acc
 
 **On a User Story:** acceptance criteria go in `Microsoft.VSTS.Common.AcceptanceCriteria`, never in `System.Description`. Write the criteria list alone into that field — no `<h3>Acceptance Criteria</h3>` wrapper — and make sure the description carries no copy of them.
 
-**On a Bug:** there is no Acceptance Criteria field and no Description control on the form. The whole write-up — description, steps, expected, actual, criteria — belongs in `Microsoft.VSTS.TCM.ReproSteps`, the environment in `Microsoft.VSTS.TCM.SystemInfo`, and `System.Description` holds only a labelled duplicate of the body.
+**On a Bug:** there is no Acceptance Criteria field and no Description control on the form. The whole write-up — description, steps, expected, actual, criteria, prior art — belongs in `Microsoft.VSTS.TCM.ReproSteps`, the environment in `Microsoft.VSTS.TCM.SystemInfo`, and `System.Description` holds only a labelled duplicate of the body.
 
-**On a Hot Fix:** the narrative stays in `System.Description`; steps, expected, actual and environment go to `Microsoft.VSTS.TCM.ReproSteps`. There is no System Info field on this type.
+**On a Hot Fix:** the narrative and prior art stay in `System.Description`; steps, expected, actual and environment go to `Microsoft.VSTS.TCM.ReproSteps`. There is no System Info field on this type.
 
 **Repair misfiled content when you find it.** If Step 2 found content in a field its type does not render, fix it as part of this edit even when the user didn't ask — it is the same content, moved to where a reader will actually see it: