npm - @chris1807/claude-kit - Versions diffs - 2.1.47 → 2.1.48 - Mend

@chris1807/claude-kit 2.1.47 → 2.1.48

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (6) hide show

package/README.md +3 -3
package/package.json +1 -1
package/templates/commands/create-work-item.md +27 -15
package/templates/commands/quote-backlog.md +98 -50
package/templates/commands/quote.md +31 -11
package/templates/infrastructure/CLAUDE-WORKFLOW.md +11 -5

package/README.md CHANGED Viewed

@@ -255,7 +255,7 @@ Kit operations that benefit from ultracode when it's on:
 |-----------|--------------|
 | `/plan-backlog` | one agent per Dev Ready story — analyze, point, and propose tasks in parallel |
 | `/plan-sprint` | one agent per sprint item — analyze and propose tasks in parallel |
-| `/quote-backlog` | one agent per Design Approved item — completeness review, duplicate check, estimate in parallel |
+| `/quote-backlog` | one agent per swept item (stories in Design Approved, bugs in New) — completeness review, duplicate check, estimate in parallel |
 | Backlog / board audits | one agent per work item — find stale, mislabeled, orphaned, or unestimated items |
 | Multi-file or cross-layer review | one agent per file/dimension, then adversarial verify before reporting |
 | Repo-wide sweeps (rename, dependency bump, pattern migration) | one agent per site, worktree-isolated |
@@ -649,10 +649,10 @@ Claude reviews for:
 | `/status` | `/status release 24` | Check status of a release, pipeline, work item, or environment |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose one child task with hours per story |
 | `/plan-sprint` | `/plan-sprint [project]` | Sweep the current sprint for stories/bugs with no child tasks → propose one child task with hours per item |
-| `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for Design Approved items without points → review completeness, check for duplicates, suggest rewrites, propose points + creator comments (10 at a time, approval-gated) |
+| `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for unpointed items ready to estimate — stories in `Design Approved`, bugs in `New` (bugs have no design states) → review completeness, check for duplicates, suggest rewrites, propose points + creator comments (10 at a time, approval-gated) |
 | `/quote` | `/quote AB#1234` | Estimate a work item in story points (senior-calibrated Fibonacci rubric) |
 | `/explain` | `/explain AB#1234` | Summarize and explain a work item in plain language |
-| `/create-work-item` | `/create-work-item [description]` | Interactively draft and create a Feature, Bug, or User Story — proposes story points (user must agree), creates pointed items in Dev Ready; on a Feature, also drafts its child stories with `Custom.Order` waves |
+| `/create-work-item` | `/create-work-item [description]` | Interactively draft and create a Feature, Bug, User Story, or Hot Fix — proposes story points (user must agree), creates pointed items in Dev Ready; on a Feature, also drafts its child stories with `Custom.Order` waves |
 | `/edit-work-item` | `/edit-work-item AB#1234 [what to change]` | Revise an existing work item field-by-field. On a Feature, cascades into its child stories — updates, adds, retires, and re-sequences `Custom.Order` waves — with a safety gate on anything already past Dev Ready |
 | `/cleanup-branches` | `/cleanup-branches` | Delete merged feature/work branches |
 | `/close-orphan-tasks` | `/close-orphan-tasks --dry-run` | Close open Tasks whose parent is Ready to Deploy / Deployed / Closed |

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@chris1807/claude-kit",
-  "version": "2.1.47",
+  "version": "2.1.48",
   "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 CHANGED Viewed

@@ -1,6 +1,6 @@
 Create a new Azure DevOps work item interactively. Usage: `/create-work-item`
-This command walks the user through creating a Feature, Bug, or User Story, develops an acceptance-criteria-ready plan, optionally embeds a UI mockup in the description, and creates the item in the chosen Azure DevOps project. For a Feature it can also draft and create the child User Stories that make the Feature implementable.
+This command walks the user through creating a Feature, Bug, User Story, or Hot Fix, develops an acceptance-criteria-ready plan, optionally embeds a UI mockup in the description, and creates the item in the chosen Azure DevOps project. For a Feature it can also draft and create the child User Stories that make the Feature implementable.
 Treat `$ARGUMENTS` as an optional rough description that the user may have typed inline (e.g. `/create-work-item users should be able to export payments`). If provided, skip the initial "describe your requirements" prompt in Step 2 and use it as the starting requirements text — but still confirm with the user before proceeding.
@@ -14,20 +14,23 @@ What type of work item do you want to create?
   1. Bug          — something deployed is behaving wrong
   2. User Story   — one shippable slice of user-facing behavior
   3. Feature      — a container for several related user stories
+  4. Hot Fix      — a production defect that can't wait for the normal queue
-Reply with 1, 2, 3, "bug", "user story", or "feature".
+Reply with 1, 2, 3, 4, "bug", "user story", "feature", or "hot fix".
 ```
-**Wait for the user's response.** Map the answer to `Bug`, `User Story`, or `Feature`. If the user types something else, ask again — do not guess.
+**Wait for the user's response.** Map the answer to `Bug`, `User Story`, `Feature`, or `Hot Fix`. The Azure DevOps type name is **`Hot Fix`** — two words, that exact casing. (The branch prefix and PR label are `hotfix`, one word — that's a `/implement` concern, not a field value.) If the user types something else, ask again — do not guess.
 If the requirements clearly span several independently shippable slices, say so and recommend `Feature` — but the type is still the user's call.
+**Bug vs. Hot Fix.** Both describe broken behavior; the difference is urgency, not shape. A Hot Fix ships out-of-band — it targets the production branch directly and skips manual UAT in `/implement`. If the user picks `Hot Fix` for something that reads as a normal-priority defect, say so once and let them decide. If they pick `Bug` for something they describe as production-down, offer `Hot Fix` once and let them decide.
 ## Step 2: Gather Requirements
 Ask the user to describe the requirements:
 ```
-Describe the {feature | bug | user story} in your own words. Include:
+Describe the {feature | bug | user story | hot fix} in your own words. Include:
 - What the user is trying to do (or what is broken)
 - Why it matters / who is affected
@@ -111,12 +114,12 @@ business or user value. Avoid implementation detail — that lives in tasks.}
 - {anything ambiguous that you couldn't infer — list as questions, not assumptions}
 ```
-### For a Bug:
+### For a Bug or Hot Fix:
 ```
 ## Draft: {Prefix} - {proposed title}
-**Type:** Bug
+**Type:** {Bug | Hot Fix}
 **Priority:** {1 | 2 | 3 | 4}
 **Severity:** {1 - Critical | 2 - High | 3 - Medium | 4 - Low}
@@ -145,7 +148,12 @@ business or user value. Avoid implementation detail — that lives in tasks.}
 - {anything you couldn't infer}
 ```
-**Inferring Priority and Severity for Bugs:**
+A Hot Fix uses the same draft shape as a Bug. Two differences:
+- **Severity and Priority are constrained.** A Hot Fix is by definition urgent — propose Priority `1` (or `2` at the loosest) and Severity `1 - Critical` or `2 - High`. If the requirements don't support that, the item is probably a Bug; say so before drafting.
+- **Add a `### Production Impact` section** naming what is broken right now, which environment, and roughly who is affected. This is the section the reviewer reads first on an out-of-band change.
+**Inferring Priority and Severity for Bugs and Hot Fixes:**
 Propose initial values based on the requirements, then let the user override during approval. Use this rubric:
@@ -183,7 +191,7 @@ Approve this draft? (yes / suggest changes / cancel)
 **Skip this step entirely for a Feature.** A Feature's size is the sum of its child stories — the Feature itself gets no `StoryPoints` value and stays in `New`. Its stories are pointed in Step 9. Go to Step 5.
-For a **Bug** or **User Story**, every work item this command creates gets a story point estimate — proposed automatically, applied only with the user's agreement.
+For a **Bug**, **User Story**, or **Hot Fix**, every work item this command creates gets a story point estimate — proposed automatically, applied only with the user's agreement.
 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.
@@ -204,7 +212,7 @@ Agree? (yes / different number / skip)
 Points are never written without the user's explicit agreement.
-## Step 5: Offer a Mockup (User Stories and Features — skip for Bugs)
+## Step 5: Offer a Mockup (User Stories and Features — skip for Bugs and Hot Fixes)
 If the work item type is **User Story** or **Feature** and the requirements appear to involve UI (a screen, a form, a button, a workflow), ask:
@@ -259,12 +267,15 @@ Before creating anything in Azure DevOps, present a final summary and ask for on
 ## Ready to Create
 **Title:**     {Prefix} - {title}
-**Type:**      {Feature | Bug | User Story}
+**Type:**      {Feature | Bug | User Story | Hot Fix}
 **Project:**   {project}
-{for Bugs:}
+{for Bugs and Hot Fixes:}
 **Priority:**  {n}
 **Severity:**  {n - Label}
-{end for Bugs}
+{end for Bugs and Hot Fixes}
+{for Hot Fixes:}
+**Production Impact:** {one line}
+{end for Hot Fixes}
 {for Features:}
 **Scope items:** {count} — offered as child stories after creation
 {end for Features}
@@ -318,7 +329,7 @@ Apply this pass to every section (Description, Acceptance Criteria, Steps to Rep
 Call `mcp__azure-devops__wit_create_work_item` with:
 - **project**: the chosen project
-- **workItemType**: `Feature`, `Bug`, or `User Story`
+- **workItemType**: `Feature`, `Bug`, `User Story`, or `Hot Fix` (two words, exact casing)
 - **title**: the approved title (with prefix)
 - **fields**: a JSON Patch document setting:
   - `System.Description` — the rendered HTML description (with embedded mockup `<img>` and any user-supplied images)
@@ -328,8 +339,9 @@ Call `mcp__azure-devops__wit_create_work_item` with:
     - Render `Business Value`, `Scope`, `Out of Scope`, and `Success Criteria` into the description. Put `Success Criteria` in `Microsoft.VSTS.Common.AcceptanceCriteria` **only if** the process template exposes that field on Feature — if the create call rejects it, fold the block into the description and retry rather than dropping it.
     - `Microsoft.VSTS.Common.BusinessValue` — only if the user supplied a number. Never invent one.
     - Omit `Microsoft.VSTS.Scheduling.StoryPoints` entirely.
-  - For Bugs:
-    - `Microsoft.VSTS.TCM.ReproSteps` — the rendered HTML repro steps (Azure DevOps puts repro steps in this field for the Bug template; if the project uses the Agile template instead, fold repro steps into Description)
+  - For Bugs and Hot Fixes:
+    - `Microsoft.VSTS.TCM.ReproSteps` — the rendered HTML repro steps (Azure DevOps puts repro steps in this field for the Bug template; if the project uses the Agile template instead, fold repro steps into Description). If the `Hot Fix` type in this process template doesn't expose `ReproSteps`, fold the repro steps into `System.Description` rather than dropping them.
+    - For Hot Fixes, render the `Production Impact` section into the description as an `<h3>` block above the repro steps.
     - `Microsoft.VSTS.Common.Priority` — the chosen Priority (1–4)
     - `Microsoft.VSTS.Common.Severity` — the chosen Severity (`1 - Critical`, `2 - High`, `3 - Medium`, `4 - Low`)

package/templates/commands/quote-backlog.md CHANGED Viewed

@@ -1,8 +1,17 @@
-Sweep an Azure DevOps backlog for Design Approved stories without Story Points, review each for completeness and duplicate implementation, then — after user approval — set points and leave feedback comments for the item's creator. Usage: `/quote-backlog [project]`
+Sweep an Azure DevOps backlog for unpointed User Stories (`Design Approved`) and Bugs (`New`), review each for completeness and duplicate implementation, then — after user approval — set points and leave feedback comments for the item's creator. Usage: `/quote-backlog [project]`
-This command walks the **backlog** of a chosen Azure DevOps project, finds user stories and bugs in **Design Approved** state that **have no Story Points yet**, and for each one:
+This command walks the **backlog** of a chosen Azure DevOps project and finds items that **have no Story Points yet**, in whichever state means "ready to estimate" *for that item's type*:
-1. **Reviews the work item for completeness** — description, acceptance criteria, title prefix, design links.
+| Type | Swept in state | Why |
+|------|----------------|-----|
+| **User Story** | `Design Approved` | Stories go through a design stage; `Design Approved` is the last state before estimation |
+| **Bug** | `New` | Bugs have **no design states** — the Bug workflow is `New` → `Dev Ready` → `Active` → …, so `New` is the only pre-estimate state |
+**Types do not share a state list — verify before running against an unfamiliar project.** WIQL does not validate state names: a query filtering on a state the type doesn't have returns **zero rows instead of an error**, so a wrong state name makes the sweep look empty rather than broken. Confirm a type's real states with `mcp__azure-devops__wit_work_item` (`action: get_type`, `workItemType: Bug`) and read the `states` array. In the CSI Development process template, `Bug` and `Hot Fix` have neither `Design Review` nor `Design Approved` — only `User Story` does.
+For each qualifying item:
+1. **Reviews the work item for completeness** — description, title prefix, and acceptance criteria + design links (stories) or repro steps (bugs).
 2. **Checks whether the work is already implemented** — in the codebase, in commits, or under another ticket.
 3. **Looks at the code when it makes sense** — to validate the described approach and suggest changes.
 4. **Proposes a story point estimate** — using the same senior-calibrated rubric as `/quote`.
@@ -13,10 +22,11 @@ This command walks the **backlog** of a chosen Azure DevOps project, finds user
 **Hard batch limit: 10 items per run.** If more qualify, process the first 10 (by backlog rank) and report how many remain.
-**Nothing is written to Azure DevOps — no points, no comments — until the user has seen the full batch and approved.** This command never modifies code and never reassigns items. It makes exactly two kinds of state change, both in Step 5:
+**Nothing is written to Azure DevOps — no points, no comments — until the user has seen the full batch and approved.** This command never modifies code and never reassigns items. It makes exactly three kinds of change, all in Step 5:
 - an item that **gets points** moves to **Dev Ready**;
-- an item that **can't be quoted** because information is missing moves back to **Design Review**, so the next sweep doesn't pick it up again while the creator is still working on it.
+- a **User Story** that **can't be quoted** because information is missing moves back to **Design Review**, so the next sweep doesn't pick it up again while the creator is still working on it;
+- a **Bug** that can't be quoted gets a **`needs-info` tag** instead — its state stays `New`. `New` is the bottom of the Bug workflow, so there is no earlier state to send it back to; the tag is what drops it out of the next sweep. The Step 2 query excludes tagged items, and removing the tag re-queues the bug.
 Treat `$ARGUMENTS` as an optional project name (e.g. `/quote-backlog CSI Development`). If provided, skip the project prompt in Step 1.
@@ -26,7 +36,7 @@ If `$ARGUMENTS` contains `--help` or `-h`, print everything between the two rule
 ---
-**`/quote-backlog [project]`** — sweep a backlog for Design Approved items with no Story Points.
+**`/quote-backlog [project]`** — sweep a backlog for unpointed items that are ready to estimate: User Stories in `Design Approved`, Bugs in `New` (Bugs have no design states).
 Reviews each item for completeness and duplicate work, proposes points, and drafts feedback for the item's creator. Max 10 items per run, in backlog-rank order.
@@ -37,15 +47,16 @@ Nothing is written to Azure DevOps until you approve the batch — every option
 | `all` | Everything proposed gets applied |
 | `1,2,4` | Only those numbered items get applied; the rest are recorded as skipped |
 | `edit N` | I pause on item N so you can change my proposal, then re-show it |
-| `skip N` | Item N is dropped from the batch — nothing written, so it stays in Design Approved and shows up again next sweep |
+| `skip N` | Item N is dropped from the batch — nothing written, so it keeps its current state and shows up again next sweep |
 | `apply rewrite N` | Item N's rewrite is written **onto the work item** instead of only suggested |
 | `cancel` | Stop with zero changes |
 Numbers refer to the `#` column of the summary table, not to AB# ids — so `1,2,10` acts on items 1, 2 and 10 of the batch and leaves everything else untouched.
 **What approval writes:**
-- **Story Points** on items that got a number — each also moves from Design Approved to **Dev Ready**
-- **Design Review** on items that couldn't be quoted — anything blocked on missing information goes back to the creator's queue so the next sweep skips it
+- **Story Points** on items that got a number — each also moves to **Dev Ready**
+- **Design Review** on **User Stories** that couldn't be quoted — anything blocked on missing information goes back to the creator's queue so the next sweep skips it
+- A **`needs-info` tag** on **Bugs** that couldn't be quoted — a Bug has no design state to return to, so the tag is what keeps the next sweep off it. Existing tags are preserved; the state stays `New`
 - **Comments** to the creators of items where something was found
 - **Rewrites** — description, and a tightened version of AC that already exist — only for items you explicitly marked `apply rewrite N`
@@ -85,27 +96,38 @@ SELECT [System.Id], [System.Title], [System.State],
        [System.CreatedBy]
 FROM WorkItems
 WHERE [System.TeamProject] = '{project}'
-  AND [System.WorkItemType] IN ('User Story', 'Bug')
-  AND [System.State] = 'Design Approved'
   AND [Microsoft.VSTS.Scheduling.StoryPoints] = ''
   AND [System.IterationPath] = '{project}'
+  AND [System.Tags] NOT CONTAINS 'needs-info'
+  AND (
+        ([System.WorkItemType] = 'User Story' AND [System.State] = 'Design Approved')
+     OR ([System.WorkItemType] = 'Bug'        AND [System.State] = 'New')
+      )
 ORDER BY [Microsoft.VSTS.Common.StackRank] ASC
 ```
+> **The state predicate is per-type on purpose — do not collapse it.** `[System.WorkItemType] IN ('User Story', 'Bug') AND [System.State] = 'Design Approved'` is the tempting one-liner and it is **silently wrong**: `Bug` has no `Design Approved` state, so that form returns User Stories only and never surfaces a single bug. It produces no error, just a short result set.
+>
+> The `[System.Tags] NOT CONTAINS 'needs-info'` clause excludes bugs that a previous run sent back to their creator (Step 5.3). Removing the tag re-queues the bug.
+>
 > The `[System.IterationPath] = '{project}'` clause restricts results to the **root** iteration — items not yet placed in a sprint. If a project uses a different convention (e.g. an explicit "Backlog" iteration), ask the user to confirm before proceeding.
 >
 > If the server rejects the empty-value comparison on Story Points, drop that clause, fetch the results, and filter out already-pointed items client-side.
+>
+> If the project's `Bug` type *does* have design states (a different process template), use `Design Approved` for bugs too and say so in the batch header — but confirm with `get_type` first rather than assuming either way.
 **Take at most the first 10 items** (backlog-rank order). If the query returned more, note the overflow — it goes in the Step 4 header and the final summary.
 If the query returns zero items, report:
 ```
-No Design Approved items without Story Points were found on the backlog of {project}.
-Nothing to quote.
+Nothing to quote on the backlog of {project}.
+  User Stories in Design Approved without points: 0
+  Bugs in New without points:                    0
+  (items tagged needs-info are excluded — remove the tag to re-queue one)
 ```
-and stop.
+and stop. **If the user expected items to be there**, confirm the state names with `get_type` before concluding the backlog is clean — an empty result is what a wrong state name looks like.
 ## Step 3: Analyze Each Item (max 10)
@@ -124,7 +146,8 @@ Score the item against this checklist:
 | **Title prefix** | Follows the project's `PREFIX - Title` convention (e.g. `COM -`, `PAY -`) |
 | **Description** | States what is being built and why — not just a one-line restatement of the title |
 | **Acceptance criteria** | Present, testable, unambiguous. Each AC could become a UAT step. Record whether the field is **empty** or merely **weak** — that distinction decides whether AC can be rewritten (3g) or must go back to the creator (3f) |
-| **Design artifacts** | For UI work: a mockup, screenshot, or design link is attached or referenced (the item is Design Approved — the design should be findable) |
+| **Design artifacts** (User Story) | For UI work: a mockup, screenshot, or design link is attached or referenced (the story is Design Approved — the design should be findable) |
+| **Repro steps** (Bug) | The steps to reproduce, the expected result, and the actual result are all present. A bug swept at `New` has had no design pass, so this is the row that decides whether it's estimable — **a bug with no repro steps is a blocking gap** |
 | **Scope** | Small enough to point (would land at ≤ 21); no hidden second feature buried in the AC |
 | **Dependencies** | External dependencies or blockers are named, not implied |
@@ -173,11 +196,16 @@ Use the **modified Fibonacci scale**: `1, 2, 3, 5, 8, 13, 21`. Anything larger t
 Fold in what 3d found — code reconnaissance that shrinks or grows the work changes the number. For items classified **Blocking gaps** or **appears already implemented**, propose **no points** — the comment is the deliverable for those.
-**An item that gets no points goes back to Design Review.** Whenever the reason for not pointing an item is *we need more information* — missing AC, contradictory description, unclear scope, or a possible duplicate the creator has to confirm — record that the item should move from `Design Approved` back to `Design Review` alongside its comment. That state is what keeps the next `/quote-backlog` run from re-analyzing an item that is still waiting on its creator; leaving it in `Design Approved` guarantees it comes back in the next batch unchanged.
+**An item that gets no points drops out of the sweep.** Whenever the reason for not pointing an item is *we need more information* — missing AC or repro steps, contradictory description, unclear scope, or a possible duplicate the creator has to confirm — record the drop-out mechanism **for that item's type** alongside its comment:
-Two cases are the exception — no state change, because nothing is missing:
+- **User Story** → move from `Design Approved` back to `Design Review`.
+- **Bug** → add the `needs-info` tag; the state stays `New`. There is no earlier Bug state to send it back to, and without the tag the bug is re-analyzed in every future sweep.
-- **Needs to be split** (the work is understood, it's just too big) — the item stays in `Design Approved`; the deliverable is the split proposal.
+Either way the effect is the same: the next `/quote-backlog` run reaches new items instead of re-reviewing one that is still waiting on its creator.
+Two cases are the exception — no state change and no tag, because nothing is missing:
+- **Needs to be split** (the work is understood, it's just too big) — the item keeps its current state; the deliverable is the split proposal.
 - The user chooses to leave it alone at the Step 4 gate.
 ### 3f. Draft the creator comment (only if issues were found)
@@ -191,10 +219,14 @@ If 3b–3d surfaced anything — gaps, a duplicate, a suggested approach change
 - Acceptance criteria don't cover {X} — what should happen when {Y}?
 - AC #{n} isn't testable as written ({why}) — what does "done" look like for it?
 - The AC are missing the steps for {flow} — {what a tester couldn't verify from them}
+- {Bug only} No repro steps — what sequence produces this, what did you expect, and what happened instead?
 - This looks already implemented in AB#{id} / PR #{n} ({file or feature}) — can you confirm it's still needed?
 - Suggested approach change: {what the code shows, what to do instead}
-{Closing line: what's needed to make it estimable — and, when the item is going back to Design Review, say so plainly: "Moving this back to Design Review until that's answered — ping me and I'll re-quote it." Or, when it was pointed: "Estimated at {n} points assuming {assumption} — correct me if that's wrong."}
+{Closing line: what's needed to make it estimable — and say plainly what just happened to the item, matched to its type:
+ - User Story going back: "Moving this back to Design Review until that's answered — ping me and I'll re-quote it."
+ - Bug being tagged: "Tagging this needs-info so it's out of the estimating sweep — a Bug has no Design Review state to move it to. Remove the tag (or reply here) once there are repro steps and I'll re-quote it."
+ - Either type, pointed: "Estimated at {n} points assuming {assumption} — correct me if that's wrong."}
 ```
 **When the AC field is empty, report it — don't fill it.** Say the acceptance criteria are missing and that the item can't be estimated without them, and ask the creator for them. Never follow that with a drafted list, a "here's a starting point:" section, or criteria inferred from the title. Existing AC are a different case — those can be rewritten in 3g.
@@ -224,23 +256,24 @@ Only when **ultracode is on** (a system-reminder confirms it, or the user typed
 Show the whole batch **before writing anything**. Start with the summary table:
 ```
-Quote sweep — {project} backlog, Design Approved without Story Points
+Quote sweep — {project} backlog, unpointed (Stories: Design Approved · Bugs: New)
 Batch: {n} of {total} qualifying items{ — run /quote-backlog again for the next 10}
-| #  | ID       | Title                              | Completeness  | Points | State           | Comment | Rewrite |
-|----|----------|------------------------------------|---------------|--------|-----------------|---------|---------|
-| 1  | AB#4611  | COM - Payment reminder emails      | Complete      |   5    | → Dev Ready     | —       | —       |
-| 2  | AB#4614  | COM - Bulk close inactive accounts | Minor gaps    |   8    | → Dev Ready     | yes     | —       |
-| 3  | AB#4617  | PAY - Refund webhook handling      | Blocking gaps |   —    | → Design Review | yes     | yes     |
-| 4  | AB#4620  | COM - Export audit log             | Already done? |   —    | → Design Review | yes     | —       |
-| 5  | AB#4623  | COM - Rebuild the reporting module | Too large     |  split | unchanged       | yes     | —       |
+| #  | ID       | Type  | Title                              | Completeness  | Points | Outcome          | Comment | Rewrite |
+|----|----------|-------|------------------------------------|---------------|--------|------------------|---------|---------|
+| 1  | AB#4611  | Story | COM - Payment reminder emails      | Complete      |   5    | → Dev Ready      | —       | —       |
+| 2  | AB#4614  | Story | COM - Bulk close inactive accounts | Minor gaps    |   8    | → Dev Ready      | yes     | —       |
+| 3  | AB#4617  | Story | PAY - Refund webhook handling      | Blocking gaps |   —    | → Design Review  | yes     | yes     |
+| 4  | AB#4619  | Bug   | PAY - Duplicate refund email       | Complete      |   3    | → Dev Ready      | —       | —       |
+| 5  | AB#4620  | Bug   | COM - Audit log export 500s        | Blocking gaps |   —    | + needs-info tag | yes     | —       |
+| 6  | AB#4623  | Story | COM - Rebuild the reporting module | Too large     |  split | unchanged        | yes     | —       |
 ```
-The **State** column is what will actually be written: `→ Dev Ready` for pointed items, `→ Design Review` for items that can't be quoted until the creator supplies something, and `unchanged` for anything else (a split proposal, or an item already past Dev Ready).
+The **Type** column matters — it decides the outcome, so show it. The **Outcome** column is what will actually be written: `→ Dev Ready` for pointed items of either type, `→ Design Review` for **User Stories** that can't be quoted until the creator supplies something, `+ needs-info tag` for **Bugs** in the same situation (state stays `New` — a Bug has no design state to return to), and `unchanged` for anything else (a split proposal, or an item already past Dev Ready).
 Then a detail block per item — estimate reasoning (2–3 bullets), completeness findings, duplicate evidence with links/IDs, code notes, the **full text of any draft comment**, and the **full text of any suggested rewrite**. The user must be able to read every word that would be posted.
-Note above the prompt: **approving an item approves its state change too** — pointed items move to Dev Ready, and items that couldn't be quoted move back to Design Review so the next sweep skips them. Name the items in each group so the user can see exactly which ones leave `Design Approved` and in which direction.
+Note above the prompt: **approving an item approves its outcome too** — pointed items move to Dev Ready, un-quotable User Stories move back to Design Review, and un-quotable Bugs get the `needs-info` tag. Name the items in each group so the user can see exactly which ones drop out of the estimating queue and by which mechanism.
 Then ask:
@@ -250,11 +283,11 @@ Approve? (all / numbers e.g. "1,2,4" / edit N / skip N / apply rewrite N / cance
 **Wait for the user.**
-- `all` → apply every proposed write (points, state changes, and comments) in Step 5; rewrites stay inside the comments as suggestions
+- `all` → apply every proposed write (points, state changes, tags, and comments) in Step 5; rewrites stay inside the comments as suggestions
 - `1,2,4` → apply only those items; the rest are recorded as skipped
 - `edit N` → ask what to change on item N (points value, comment text, or rewrite text), revise, re-show that item, ask again
 - `apply rewrite N` → write item N's rewrite directly onto the work item in Step 5 (instead of only suggesting it in the comment). This covers the description, the title if the rewrite included one, and rewritten AC **only where the item already had AC** — an empty AC field is never populated, under this or any other option
-- `skip N` → drop item N, re-ask for the rest. A skipped item gets **nothing** written — no comment, and no move to Design Review, so it stays in `Design Approved` and will reappear in the next sweep. Say that out loud when confirming a skip, so the user isn't surprised to see it again
+- `skip N` → drop item N, re-ask for the rest. A skipped item gets **nothing** written — no comment, no state change, no tag — so it keeps its current state (`Design Approved` for a Story, `New` for a Bug) and will reappear in the next sweep. Say that out loud when confirming a skip, so the user isn't surprised to see it again
 - `cancel` → stop with **zero changes** to Azure DevOps
 ## Step 5: Apply Approved Changes
@@ -262,17 +295,26 @@ Approve? (all / numbers e.g. "1,2,4" / edit N / skip N / apply rewrite N / cance
 Only for approved items, in batch order:
 1. **Set Story Points and move to Dev Ready** (items with a proposed number): in one `mcp__azure-devops__wit_update_work_item` call, set `Microsoft.VSTS.Scheduling.StoryPoints` **and** `System.State` = `Dev Ready`. The state change applies only to `User Story`, `Bug`, and `Hot Fix` types, and never moves an item backward — if an item is somehow already past Dev Ready, set the points only and note it. Touch no other field — assignee, iteration, and tags stay as they are.
-2. **Move unquotable items back to Design Review** (approved items with **no** proposed points, where the blocker is missing information): set `System.State` = `Design Review` via `mcp__azure-devops__wit_update_work_item`. Do this **before** posting the comment in step 3, so the creator's notification arrives with the item already back in their queue. Rules:
+2. **Send unquotable User Stories back to Design Review** (approved `User Story` items with **no** proposed points, where the blocker is missing information): set `System.State` = `Design Review` via `mcp__azure-devops__wit_update_work_item`. Do this **before** posting the comment in step 4, so the creator's notification arrives with the item already back in their queue. Rules:
-   - Only for `User Story`, `Bug`, and `Hot Fix` types.
+   - **`User Story` only.** Do not attempt this on a `Bug` or a `Hot Fix` — those types have no `Design Review` state, so the update fails at runtime in the middle of the batch. They take step 3 instead.
    - Only from `Design Approved` — **never move an item backward past the design stage.** An item at `Dev Ready`, or anything at `Active` or later (`Active`, `Code Review`, `Ready for Testing`, `Testing`, `Ready to Deploy`, …), keeps its state; note it in the summary instead.
    - Skip items whose only finding is **needs to be split** — the work is understood, so nothing is missing; leave those in `Design Approved`.
    - If the item is already in `Design Review`, this is a no-op — post the comment and move on.
-   - If the project's process template has no `Design Review` state (the update returns an invalid-state error), fall back in this order: `In Design` → `New` → leave the state alone and **warn the user** that the item will be picked up again by the next sweep. Do not silently swallow the error.
-   - Touch no other field — points stay empty, assignee, iteration, and tags stay as they are.
+   - If this project's `User Story` type has no `Design Review` state either (the update returns an invalid-state error), fall back in this order: `In Design` → the `needs-info` tag from step 3 → leave the item alone and **warn the user** that it will be picked up again by the next sweep. Do not silently swallow the error.
+   - Touch no other field — points stay empty; assignee, iteration, and tags stay as they are.
+3. **Tag unquotable Bugs `needs-info`** (approved `Bug` and `Hot Fix` items with **no** proposed points, where the blocker is missing information): `New` is the first state in the Bug workflow, so there is no earlier state to send the bug back to — the tag is what drops it out of the Step 2 query. Do this **before** posting the comment in step 4. Rules:
-3. **Post the comment** (items with an approved draft): add it with `mcp__azure-devops__wit_add_work_item_comment` (or the server's work-item comment tool). Use the mention syntax the server supports so the creator is notified; otherwise lead with their display name as drafted. For an item that just moved to Design Review, the comment must say so — the creator needs to know why it left their Design Approved column.
-4. **Apply the rewrite** (only items the user marked `apply rewrite N`): update `System.Description` (and `System.Title` if the rewrite included one) via `wit_update_work_item`, and adjust the comment to say the rewrite was applied ("rewrote the description/AC per the above — please review") rather than suggesting it. Never apply a rewrite the user didn't explicitly mark.
+   - **Append to `System.Tags`, never replace it.** Take the item's current tag list (fetched in 3a), append `needs-info` to it, and write the whole semicolon-separated list back. Writing the field bare wipes tags someone else set — `release-{N}`, triage labels, scope hints.
+   - If `needs-info` is already present, this is a no-op — post the comment and move on.
+   - **Leave `System.State` alone.** Never move the bug backward, and never move it to `Removed` or `Closed` — it is still a real bug, just not estimable yet.
+   - Only for bugs at `New` (or at `Dev Ready` with no points). If the bug is at `Active` or later, someone is already working it: skip the tag, post the comment, and note it in the summary.
+   - Skip items whose only finding is **needs to be split** — nothing is missing, so no tag.
+   - Touch no other field — points stay empty; assignee, iteration, and state stay as they are.
+4. **Post the comment** (items with an approved draft): add it with `mcp__azure-devops__wit_add_work_item_comment` (or the server's work-item comment tool). Use the mention syntax the server supports so the creator is notified; otherwise lead with their display name as drafted. For a story that just moved to Design Review, the comment must say so — the creator needs to know why it left their Design Approved column. For a bug that just got the `needs-info` tag, the comment must say that too, and say that removing the tag re-queues it.
+5. **Apply the rewrite** (only items the user marked `apply rewrite N`): update `System.Description` (and `System.Title` if the rewrite included one) via `wit_update_work_item`, and adjust the comment to say the rewrite was applied ("rewrote the description/AC per the above — please review") rather than suggesting it. Never apply a rewrite the user didn't explicitly mark.
    **Guard on `Microsoft.VSTS.Common.AcceptanceCriteria`:** write it only if the item's AC field was **non-empty** when fetched in 3a. Re-check the fetched value at write time — if it was blank, drop AC from the update payload and write the other fields. Blank means no criteria at all: empty string, whitespace, or an empty HTML shell like `<div></div>` or `<p><br></p>`.
@@ -283,30 +325,36 @@ If a write fails, report the failure and ask whether to continue with the remain
 ```
 ## Quote Sweep Complete — {project}
-Items analyzed:   {n} (of {total} qualifying — {remaining} left for the next run)
-  ✓ Points set:   {n_pointed}  (total {sum} pts — each moved to Dev Ready)
-  ↩ Design Review: {n_design_review} not quoted — moved back to the creator, out of the next sweep
-  ✓ Comments:     {n_comments} posted to creators
-  ✓ Rewrites:     {n_rewrites_applied} applied, {n_rewrites_suggested} suggested in comments
-  ⚑ AC missing:   {n_ac_missing} items sent back to the creator to write their acceptance criteria
-  ⏭ Skipped:      {n_skipped} left in Design Approved — will reappear next sweep ({reasons})
+Items analyzed:    {n} (of {total} qualifying — {remaining} left for the next run)
+                   {n_stories} stories (Design Approved) · {n_bugs} bugs (New)
+  ✓ Points set:    {n_pointed}  (total {sum} pts — each moved to Dev Ready)
+  ↩ Design Review: {n_design_review} stories not quoted — moved back to the creator, out of the next sweep
+  ⚑ needs-info:    {n_tagged} bugs not quoted — tagged, state left at New, out of the next sweep
+  ✓ Comments:      {n_comments} posted to creators
+  ✓ Rewrites:      {n_rewrites_applied} applied, {n_rewrites_suggested} suggested in comments
+  ⚑ Info missing:  {n_info_missing} items sent back to the creator (AC on stories, repro steps on bugs)
+  ⏭ Skipped:       {n_skipped} left exactly as they were — will reappear next sweep ({reasons})
 Pointed items:
 - AB#4611: 5 pts
 - AB#4614: 8 pts (comment posted)
 - ...
-Moved back to Design Review (no points — waiting on the creator):
+Moved back to Design Review (stories, no points — waiting on the creator):
 - AB#4617: blocking gaps — AC missing failure cases
-- AB#4620: possibly already implemented in AB#4102 — needs confirmation
+- AB#4618: possibly already implemented in AB#4102 — needs confirmation
+Tagged needs-info (bugs, no points — still at New, waiting on the creator):
+- AB#4620: no repro steps — can't tell which flow breaks
+- AB#4621: possibly already fixed in PR #318 — needs confirmation
-Left in Design Approved:
-- AB#4623: too large to point — split proposal in the comment
-- AB#4625: you skipped it
+Left exactly as they were:
+- AB#4623: too large to point — split proposal in the comment (Design Approved)
+- AB#4625: you skipped it (New)
 Next steps:
   /quote-backlog {project}   — process the next 10 qualifying items
   /quote AB#{id}             — re-estimate a single item after the creator responds
 ```
-Do not create tasks or assign items — those are downstream decisions. Pointed items are now Dev Ready, so `/plan-backlog` picks them up on its next run. Items moved to Design Review are out of the `Design Approved` query, so the next `/quote-backlog` run reaches genuinely new items instead of re-reviewing the ones still waiting on their creator — re-quote one with `/quote AB#{id}` once they respond, or let them move it back to Design Approved themselves. Make no state change other than the two described in Step 5.
+Do not create tasks or assign items — those are downstream decisions. Pointed items are now Dev Ready, so `/plan-backlog` picks them up on its next run. Stories moved to Design Review and bugs tagged `needs-info` are both out of the Step 2 query, so the next `/quote-backlog` run reaches genuinely new items instead of re-reviewing the ones still waiting on their creator — re-quote one with `/quote AB#{id}` once they respond, or let them move the story back to Design Approved / drop the bug's tag themselves. Make no change other than the three described in Step 5.

package/templates/commands/quote.md CHANGED Viewed

@@ -8,7 +8,7 @@ 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.
-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`).
+Capture: title, type, description, acceptance criteria, repro steps (on a Bug), attached child items, any existing `Story Points` / `Effort` field value, and the item's **full current tag list** — both the tags that hint at scope (e.g. `spike`, `research`, `infra`) and the rest, because Step 5b appends to that list and must not clobber it.
 ## Step 2: Size the Work
@@ -34,7 +34,7 @@ Adjust downward for: pure config changes, mechanical refactors with good test co
 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).
-**If the item can't be estimated at all, don't guess a number.** An item is *not estimable* when the gap is information only its creator can close — no acceptance criteria, a description that contradicts itself, scope you can't bound, or work that looks like it may already be done under another ticket. Report it as **needs more information**, list exactly what's missing, and go to Step 5 instead of Step 4. This is different from **needs to be split**: a split candidate is understood work that's simply too big, and it keeps its current state.
+**If the item can't be estimated at all, don't guess a number.** An item is *not estimable* when the gap is information only its creator can close — no acceptance criteria (or, on a Bug, no repro steps), a description that contradicts itself, scope you can't bound, or work that looks like it may already be done under another ticket. Report it as **needs more information**, list exactly what's missing, and go to Step 5 instead of Step 4. This is different from **needs to be split**: a split candidate is understood work that's simply too big, and it keeps its current state.
 ## Step 3: Display the Estimate
@@ -91,22 +91,42 @@ When the user agrees, in the **same** `wit_update_work_item` call:
 **Never change the state of a Feature or a Task** — if the sized item is a Feature, persist points only (or per-child points on the children, each of which does get Dev Ready if it qualifies).
-## Step 5: Offer to Send Unquotable Items Back (Design Review)
+## Step 5: Offer to Take Unquotable Items Out of the Estimating Queue
-When the item came out of Step 2 as **needs more information**, offer to move it back so it drops out of the estimating queue:
+When the item came out of Step 2 as **needs more information**, offer to drop it out of the estimating queue. **The mechanism depends on the work item type, because not every type has a design stage:**
-> *"I can't size this until {what's missing}. Want me to move AB#{id} back to Design Review so it's out of the next `/quote-backlog` sweep until the creator responds?"*
+| Type | Mechanism | Section |
+|------|-----------|---------|
+| `User Story` | Move `Design Approved` → **`Design Review`** | 5a |
+| `Bug`, `Hot Fix` | Add a **`needs-info` tag**; leave the state at `New` | 5b |
+| `Feature`, `Task` | Neither — report the gap and stop | — |
+In the CSI Development process template, `Bug` and `Hot Fix` have **no design states at all** — the workflow is `New` → `Dev Ready` → `Active` → `Code Review` → …, with neither `Design Review` nor `Design Approved`. `New` is the bottom of that workflow, so there is nowhere to send a bug back to; the tag is what keeps `/quote-backlog` from re-analyzing it. On an unfamiliar project, confirm the type's real states with `mcp__azure-devops__wit_work_item` (`action: get_type`, `workItemType: Bug`) and read the `states` array — don't infer a state name from what the workflow "should" have. A bad state name is accepted by a query (zero rows, no error) and rejected only at write time.
-**Wait for the user.** Only update the work item if they say yes.
+### 5a. User Story → Design Review
+> *"I can't size this until {what's missing}. Want me to move AB#{id} back to Design Review so it's out of the next `/quote-backlog` sweep until the creator responds?"*
-When they agree, set `System.State` = `Design Review` with `mcp__azure-devops__wit_update_work_item`. Rules:
+**Wait for the user.** Only update the work item if they say yes. Then set `System.State` = `Design Review` with `mcp__azure-devops__wit_update_work_item`. Rules:
-- Only for `User Story`, `Bug`, and `Hot Fix` types — **never** a Feature or a Task.
+- **`User Story` only** — never a Bug, Hot Fix, Feature, or Task. A Bug takes 5b; the update would fail on it anyway.
 - **Never move an item backward past the design stage.** Only from `Design Approved`; if it's already `Dev Ready` or anything at `Active` or later (`Active`, `Code Review`, `Ready for Testing`, `Testing`, `Ready to Deploy`, …), leave the state alone and say so — someone is already working on it, and a state bounce there does real damage.
 - Already in `Design Review` → no-op; say it's already there.
-- No `Design Review` state in the process template (the update returns an invalid-state error) → fall back in this order: `In Design` → `New` → leave the state alone and **warn** that the item will keep surfacing in backlog sweeps. Don't swallow the error.
+- No `Design Review` state for `User Story` in this process template (the update returns an invalid-state error) → fall back in this order: `In Design` → the `needs-info` tag from 5b → leave the state alone and **warn** that the item will keep surfacing in backlog sweeps. Don't swallow the error.
 - Set **no** story points and touch no other field — assignee, iteration, and tags stay as they are.
-Why it matters: `/quote-backlog` sweeps `Design Approved` items with no points. An item left in `Design Approved` while waiting on its creator gets re-analyzed in every sweep, so moving it to `Design Review` is what keeps the next run reaching new items. Re-quote it with `/quote AB#{id}` once the creator responds.
+### 5b. Bug / Hot Fix → `needs-info` tag
+> *"I can't size this until {what's missing} — and a Bug has no design state to send it back to. Want me to tag AB#{id} `needs-info` so it drops out of the next `/quote-backlog` sweep? Removing the tag re-queues it."*
+**Wait for the user.** Only update the work item if they say yes. Then add the tag with `mcp__azure-devops__wit_update_work_item`. Rules:
+- **Append to `System.Tags`, never replace it.** Take the current tag list captured in Step 1, append `needs-info`, and write the whole semicolon-separated list back. Writing the field bare wipes tags someone else set — `release-{N}`, triage labels, scope hints.
+- Already tagged `needs-info` → no-op; say it's already there.
+- **Leave `System.State` alone.** Never move the bug backward, and never move it to `Removed` or `Closed` — it is still a real bug, just not estimable yet.
+- If the bug is at `Active` or later, someone is already working it: skip the tag, say so, and let them size it themselves.
+- Set **no** story points and touch no other field — assignee, iteration, and state stay as they are.
+Why either one matters: `/quote-backlog` sweeps unpointed User Stories in `Design Approved` and unpointed Bugs in `New`, excluding anything tagged `needs-info`. An item left untouched while waiting on its creator gets re-analyzed in every sweep — the state bounce (stories) and the tag (bugs) are what keep the next run reaching genuinely new items. Re-quote with `/quote AB#{id}` once the creator responds.
-**Items that only need to be split keep their state** — the work is understood, so there's nothing to send back. Same for an item where you got a number: that path ends at Step 4.
+**Items that only need to be split keep their state and get no tag** — the work is understood, so there's nothing to send back. Same for an item where you got a number: that path ends at Step 4.

package/templates/infrastructure/CLAUDE-WORKFLOW.md CHANGED Viewed

@@ -41,7 +41,7 @@ Ultracode is **opt-in**. It is on only when a system-reminder confirms it, when
 |-----------|--------------|
 | `/plan-backlog` | one agent per Dev Ready story — analyze, point, and propose tasks in parallel |
 | `/plan-sprint` | one agent per sprint item — analyze and propose tasks in parallel |
-| `/quote-backlog` | one agent per Design Approved item — completeness review, duplicate check, estimate in parallel |
+| `/quote-backlog` | one agent per swept item (stories in Design Approved, bugs in New) — completeness review, duplicate check, estimate in parallel |
 | Backlog / board audits | one agent per work item — find stale, mislabeled, orphaned, or unestimated items |
 | Multi-file or cross-layer review | one agent per file/dimension, then adversarial verify before reporting |
 | Repo-wide sweeps (rename, dependency bump, pattern migration) | one agent per site, worktree-isolated |
@@ -112,7 +112,13 @@ These rules apply to **every** command or flow that creates or estimates work it
 1. **Every work item Claude creates gets a proposed story point estimate** — User Stories and Bugs are never created unpointed by default. Estimates use the modified Fibonacci scale (`1, 2, 3, 5, 8, 13, 21`), calibrated for a **senior developer working with Claude assistance** — no ramp-up padding; pad only for what seniority + Claude can't shortcut (novel work, missing AC, cross-team coordination, external dependencies).
 2. **The user must agree before points are written.** Claude proposes the number with a one-line rationale; the user confirms, adjusts (their number wins), or skips. Points are never set silently.
 3. **Setting points moves the item to Dev Ready.** Any time story points are written to a **User Story**, **Bug**, or **Hot Fix**, `System.State` is set to `Dev Ready` in the same update. Never for Features or Tasks (a Feature's state is never touched; Tasks carry hour estimates, not points), and never backward — an item already past Dev Ready keeps its state, with a note.
-4. **An item that can't be quoted goes back to Design Review.** When `/quote` or `/quote-backlog` can't produce a number because information is missing — no acceptance criteria, contradictory description, unbounded scope, or a possible duplicate the creator has to confirm — the item moves from `Design Approved` back to `Design Review` along with the feedback comment. This keeps the next backlog sweep from re-analyzing items still waiting on their creator. Same guards as rule 3: `User Story` / `Bug` / `Hot Fix` only, and only from `Design Approved` — an item at `Dev Ready` or anything `Active` or later keeps its state. An item that merely **needs to be split** keeps its state — the work is understood, nothing is missing.
+4. **An item that can't be quoted drops out of the estimating queue — by a mechanism that depends on its type.** When `/quote` or `/quote-backlog` can't produce a number because information is missing — no acceptance criteria (or, on a bug, no repro steps), contradictory description, unbounded scope, or a possible duplicate the creator has to confirm — the item drops out of the sweep along with the feedback comment, so the next run isn't re-analyzing items still waiting on their creator:
+   - **User Story** → moves from `Design Approved` back to `Design Review`. Only from `Design Approved`; an item at `Dev Ready` or anything `Active` or later keeps its state.
+   - **Bug / Hot Fix** → gets a **`needs-info` tag**, state left at `New`. **These types have no design states** in the CSI Development template — no `Design Review` and no `Design Approved` — so there is no earlier state to send them back to. Append to `System.Tags`; never overwrite the field. Removing the tag re-queues the bug.
+   - **Feature / Task** → neither; report the gap and stop.
+   An item that merely **needs to be split** keeps its state and gets no tag — the work is understood, nothing is missing.
+5. **Never assume two work item types share a state list.** WIQL doesn't validate state names, so a query filtering on a state the type doesn't have returns **zero rows instead of an error** — the classic symptom is a backlog sweep that silently never surfaces a single bug. Confirm with `mcp__azure-devops__wit_work_item` (`action: get_type`) before writing a state name into a query or an update. In CSI Development: `User Story` has `New → Dev Ready → In Design → Design Review → Design Approved → Active → …`; `Bug` and `Hot Fix` have `New → Dev Ready → Active → …`.
 ### Branching Strategy
@@ -255,9 +261,9 @@ All deployment and release operations are available as slash commands:
 | `/status` | `/status release 24` | Check release, pipeline, or work item status |
 | `/plan-backlog` | `/plan-backlog [project]` | Sweep backlog for Dev Ready stories with points and no tasks → propose child tasks with hours |
 | `/plan-sprint` | `/plan-sprint [project]` | Sweep the current sprint for stories/bugs with no child tasks → propose one child task with hours per item |
-| `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for Design Approved items without points → review completeness, check for duplicates, suggest rewrites, propose points + creator comments (10 at a time, approval-gated). Pointed items move to Dev Ready; items that can't be quoted move back to **Design Review** so the next sweep skips them |
-| `/quote` | `/quote AB#1234` | Estimate story points for one work item; on approval, sets the points and moves the item to Dev Ready. If it can't be estimated, offers to move it back to **Design Review** |
-| `/create-work-item` | `/create-work-item [description]` | Interactively draft and create a Feature, Bug, or User Story — proposes story points (user must agree) and creates pointed items in Dev Ready; on a Feature, also drafts its child stories with `Custom.Order` waves |
+| `/quote-backlog` | `/quote-backlog [project]` | Sweep backlog for unpointed items ready to estimate — stories in `Design Approved`, **bugs in `New`** (bugs have no design states) → review completeness, check for duplicates, suggest rewrites, propose points + creator comments (10 at a time, approval-gated). Pointed items move to Dev Ready; stories that can't be quoted move back to **Design Review**, bugs that can't be quoted get a **`needs-info`** tag, so the next sweep skips them |
+| `/quote` | `/quote AB#1234` | Estimate story points for one work item; on approval, sets the points and moves the item to Dev Ready. If it can't be estimated, offers to send a story back to **Design Review** or tag a bug **`needs-info`** |
+| `/create-work-item` | `/create-work-item [description]` | Interactively draft and create a Feature, Bug, User Story, or Hot Fix — proposes story points (user must agree) and creates pointed items in Dev Ready; on a Feature, also drafts its child stories with `Custom.Order` waves |
 | `/edit-work-item` | `/edit-work-item AB#1234 [what to change]` | Revise an existing work item field-by-field. On a Feature, cascades the change into its child stories — updates, adds, retires, and re-sequences `Custom.Order` waves — with a safety gate on anything already past Dev Ready |
 | `/cleanup-branches` | `/cleanup-branches` | Delete merged branches |
 | `/close-orphan-tasks` | `/close-orphan-tasks [scope] [--dry-run]` | Close open Tasks whose parent is Ready to Deploy / Deployed / Closed |