@chris1807/claude-kit 2.1.18 → 2.1.19

package/package.json

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

@@ -237,6 +237,17 @@ Azure DevOps description and acceptance criteria fields are HTML — they do not
 
 Wrap each top-level section in `<p>...</p>`. Preserve any user-supplied `<img>` tags from Step 2 as-is.
 
+### Emphasis and code spans (required)
+
+A description that is one long paragraph of plain prose is not acceptable — even after Markdown is converted, the rendered output must guide the reader's eye. Before rendering, edit the draft so that:
+
+- **Key terms, values, and outcomes** in each sentence are wrapped in `**bold**` (renders as `<strong>...</strong>`). Bold the noun phrase that carries the claim, not the whole sentence.
+- **Code identifiers** — method names, class names, field names, file paths, route paths, JSON keys, env vars, commit hashes, IDs, literal values like `true` / `null` / numeric thresholds — are wrapped in `` `code spans` `` (renders as `<code>...</code>`).
+- **Lists** are used instead of comma-separated prose whenever the draft contains 2+ parallel items (steps, files, references, acceptance criteria).
+- **Section headings** (`### Description`, `### Acceptance Criteria`, etc.) are kept — they become `<h3>` and structure the rendered output.
+
+Apply this pass to every section (Description, Acceptance Criteria, Steps to Reproduce, Expected/Actual Behavior, Environment/Scope, Open Questions). Apply it equally to Bugs and User Stories.
+
 ### Call the create API
 
 Call `mcp__azure-devops__wit_create_work_item` with:

package/templates/commands/rework.md

@@ -161,7 +161,23 @@ If the user provided hours (suggested or overridden):
    - **workItemType**: `Task`
    - **title**: `Rework AB#{id} — round {N}`
    - **fields**: JSON Patch document setting:
-     - `System.Description` — short summary of the rework feedback + link to the most recent PR
+     - `System.Description` — structured **HTML** (Azure DevOps does not render Markdown in this field). Use exactly these three sections, in this order, omitting any that have no content:
+
+       ```html
+       <h3>Summary</h3>
+       <p>{1–2 sentences describing the problem the rework addresses. Bold key terms, values, and outcomes with <strong>...</strong>.}</p>
+       <h3>Fix</h3>
+       <ul>
+         <li>{What changes. Wrap code identifiers, method names, fields, file paths, and literal values in <code>...</code>.}</li>
+       </ul>
+       <h3>Reference</h3>
+       <ul>
+         <li>Rework round {N} of AB#{id} ({date or tester} feedback).</li>
+         <li><a href="{PR url}">PR #{n}</a> — {one-line context, e.g. test-plan scenario, submission id in <code>...</code>}</li>
+       </ul>
+       ```
+
+       Render any code identifiers (method names, fields, file paths, hashes, literal values) inside `<code>` spans, and emphasize the key claim/value in each sentence with `<strong>`. Do not submit a wall of plain prose — every rework task must have at least the `Summary` and `Fix` sections in this shape.
      - `Microsoft.VSTS.Scheduling.OriginalEstimate` — the agreed hours
      - `Microsoft.VSTS.Scheduling.RemainingWork` — the agreed hours
      - `System.AreaPath` — same as the parent