[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXZRQWHTWV1G9PTTHCGGYA":3,"skill-same:01M6DXZRQWHTWV1G9PTTHCGGYA":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item",null,"Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.","atomicinnovation\u002Faccelerator","atomicinnovation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F65866524?v=4","01M6DXP513JV585FN2QPNR6079","Atomic","01M6DXP55MPK99YVZ2HGMEN991",34,"MIT","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"work item","review work","work","review work item","review","use","when","iterate","evaluate","frontmatter","path","implementation","user","quality","Bash","escalation","file","metadata","config","validate","2026-11-10 10:12:30",false,"---\nname: review-work-item\ndescription: Review a work item through multiple quality lenses and\n  collaboratively iterate based on findings. Use when the user wants to\n  evaluate a work item before implementation or escalation.\nargument-hint: \"[path to work item file]\"\nallowed-tools:\n   - Bash(accelerator config *)\n   - Bash(accelerator work *)\n   - Bash(accelerator corpus metadata derive)\n   - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Review Work Item\n\n!`accelerator config context --skill review-work-item --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n!`accelerator config review work-item --fail-safe`\n\n**Work items directory**: !`accelerator config path work --fail-safe`\n**Work item reviews directory**: !`accelerator config path review_work --fail-safe`\n\n## Work Item Review Template\n\nThe template below defines the frontmatter and body structure that every\nwork item review must carry. Read it now — use it to guide what information\nyou record in Steps 3-4 and what shape you persist in Step 4.8.\n\n!`accelerator config template work-item-review --fail-safe`\n\nYou are tasked with reviewing a work item through quality lenses and then\ncollaboratively iterating the work item based on findings.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if a work item path or ID was provided**: invoke the\n   resolver:\n\n   ```\n   accelerator work resolve \u003Cargument>\n   ```\n\n   The resolver respects `work.id_pattern` and accepts paths, full IDs\n   (`PROJ-0042`), and bare numbers.\n\n   - **Exit 0**: stdout is the absolute path. Read the work item\n     immediately and FULLY, then begin the review process.\n   - **Exit 1**: unrecognised input. Print the resolver's error and\n     offer to run `\u002Flist-work-items`.\n   - **Exit 2**: ambiguous match. The resolver lists candidates with\n     source-category tags. Ask the user to disambiguate by re-running\n     with a full ID or path.\n   - **Exit 3**: no match. Print the resolver's error and offer to run\n     `\u002Flist-work-items`.\n   - **Exit 6**: the argument names a real file outside the managed work\n     directory. Print the resolver's error and offer to run\n     `\u002Flist-work-items`.\n   - If optional focus arguments were provided (e.g., \"focus on testability\"),\n     note them for lens selection.\n\n2. **If no work item path or number provided**, respond with:\n\n```\nI'll help you review a work item. Please provide:\n1. The path to the work item file (e.g., `{work_dir}\u002F0042-my-work-item.md`)\n2. (Optional) A work item number shorthand (e.g., `\u002Freview-work-item 42`)\n3. (Optional) Focus areas to emphasise (e.g., \"focus on testability\")\n\nTip: Use `\u002Flist-work-items` to find the work item you want to review.\n```\n\nThen wait for the user's input.\n\n## Available Review Lenses\n\n| Lens             | Lens Skill          | Focus                                                                   |\n|------------------|---------------------|-------------------------------------------------------------------------|\n| **Clarity**      | `clarity-lens`      | Unambiguous referents, internal consistency, jargon handling            |\n| **Completeness** | `completeness-lens` | Section presence, content density, kind-appropriate content             |\n| **Dependency**   | `dependency-lens`   | Implied couplings not captured — blockers, consumers, external systems  |\n| **Scope**        | `scope-lens`        | Right-sized, single coherent unit of work; decomposition; orthogonality |\n| **Testability**  | `testability-lens`  | Measurable criteria, verifiable outcomes, verification framing          |\n\n> Note: completeness flags an *absent* Dependencies section; dependency flags\n> an *empty or underspecified* section whose contents fail to name every\n> coupling the work item implies.\n\n## Process Steps\n\n### Step 1: Read and Understand the Work Item\n\n1. **Read the work item file FULLY** — never use limit\u002Foffset\n2. **Parse the frontmatter** to note `kind` (bug, story, spike, epic, etc.)\n   and `status`\n3. **Read any documents referenced in the References section** — these provide\n   context the lenses may need; do not read source code\n4. **Check for existing reviews**: Glob for review documents matching\n   `{work_reviews_dir}\u002F{work-item-stem}-review-*.md`. If any are found:\n   - Read the most recent review document (highest review number)\n   - Note the previous verdict, review pass count, and key findings\n   - Inform the user: \"I found {N} previous review(s) of this work item. The\n     most recent (review {N}, verdict: {verdict}) will be used as context.\"\n   - The agents do NOT receive the previous review — they review the work item\n     fresh. But the aggregation step (Step 4) should reference the previous\n     review when composing cross-cutting themes and the assessment.\n   - If the prior review file exists but cannot be parsed (malformed\n     frontmatter), warn the user and proceed as if no prior review exists.\n\n   The new review creates a **new file** with the next review number (e.g.,\n   `-review-2.md`). Previous review files are never modified.\n\n### Step 2: Select Review Lenses\n\nBy default, run every lens registered in `BUILTIN_WORK_ITEM_LENSES` unless the\nuser has provided focus arguments or config restricts the selection. The five\nwork item lenses cover orthogonal concerns, so there is no relevance-based\nauto-selection.\n\n**If the user provided focus arguments:**\n\n- Map the focus areas to the corresponding lenses\n- Include any additional lenses that are clearly relevant\n- Briefly explain which lenses you're running\n\n**If no focus arguments were provided:**\n\nRun all built-in work item lenses unless:\n- A lens is listed in `disabled_lenses` — remove it from the active set\n- The user's configured `core_lenses` has filtered this to a subset (see below)\n\nWhen `core_lenses` is set in config, apply it as the *minimum required set*;\nadd any remaining non-disabled lenses up to `max_lenses`. This means users\nwho previously pinned `core_lenses` to the Phase 4 work item lenses\n(`completeness`, `testability`, `clarity`) will also receive `scope` and\n`dependency` on upgrade, unless they add those names to `disabled_lenses` or\nset `max_lenses` to their subset size.\n\nPresent the selection briefly — enumerate the chosen lenses with a one-line\nfocus each — then use the `AskUserQuestion` tool with two options:\n\n1. **Yes, use the proposed lenses** — run the review with the selected lenses\n2. **No, specify which lenses to use** — adjust the selection before running\n\nThe confirmation gate is preserved even though the default always selects every\nlens; the gate is useful when focus args or config have narrowed the set.\n\nExample (default path, no focus args, no `core_lenses` restriction):\n\n```\nI'll review this work item through all work item lenses (clarity, completeness,\ndependency, scope, testability).\n```\n\nWait for the user's answer before spawning reviewers. If they choose option 2,\nask which lenses they want using a **plain-text question only** — do NOT use\n`AskUserQuestion` for this follow-up (the lens list is too large for the\n4-option limit). If any lens name is unrecognised, seek clarification. Once\nconfirmed, update the selection and re-present it using the same\n`AskUserQuestion` proceed\u002Fadjust pattern. This loop is user-controlled with\nno hard termination limit.\n\n### Step 3: Spawn Review Agents\n\nFor each selected lens, spawn the {reviewer agent} agent with a prompt that\nincludes the paths to the lens skill and output format files. Do NOT read these\nfiles yourself — the agent reads them in its own context.\n\nCompose each agent's prompt following this template:\n\n```\nYou are reviewing a work item through the [lens name] lens.\n\n## Context\n\nThe work item is at [path]. Read it fully.\nAlso read any source documents listed in the work item's References section.\n\n## Analysis Strategy\n\n1. Read your lens skill and output format files (see paths below)\n2. Read the work item file fully\n3. Read referenced documents from the work item's References section if present\n4. Evaluate the work item through your lens, applying each key question\n5. Reference specific work item sections in your findings using the `location`\n   field (e.g., \"Acceptance Criteria\", \"Requirements\", \"Frontmatter: kind\")\n\nIMPORTANT: Do not evaluate the codebase — work item content (and any documents\nit explicitly references) is the sole artefact under review. Do not run\ncodebase exploration agents or read source files unless the work item's\nReferences section explicitly links to them.\n\n## Lens\n\nRead the lens skill at the path listed in the Lens Catalogue table in the\nreview configuration above. If no review configuration is present, use:\n${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Freview\u002Flenses\u002F[lens]-lens\u002FSKILL.md\n\n## Output Format\n\nRead the output format at:\n${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Freview\u002Foutput-formats\u002Fwork-item-review-output-format\u002FSKILL.md\n\nIMPORTANT: Return your analysis as a single JSON code block. Do not include\nprose outside the JSON block.\n```\n\nSpawn all selected agents **in parallel** using the Task tool with\n`subagent_type: \"!`accelerator config agent reviewer --fail-safe`\"`.\n\n**IMPORTANT**: Wait for ALL review agents to complete before proceeding.\n\n**Handling malformed agent output**:\n\nIf an agent's response is not a clean JSON block, apply this extraction\nstrategy:\n\n1. Look for a JSON code block fenced with triple backticks (optionally with\n   a `json` language tag)\n2. If found, extract and parse the content within the fences\n3. If the extracted JSON is valid, use it normally\n4. If no JSON code block is found, or the JSON within it is invalid, apply\n   the fallback: treat the agent's entire output as a single finding with\n   `\"suggestion\"` severity (marked `synthetic: true`), attributed to that\n   agent's lens\n\n   Note: `\"suggestion\"` severity is used here (not `\"major\"` as in\n   `review-plan`) so a single flaky agent cannot deterministically force a\n   REVISE verdict when `work_item_revise_severity` is `major` or higher.\n\nWhen falling back, warn the user that the agent's output could not be parsed\nand present the raw agent output so the user can see what the agent found.\nInclude remediation guidance: \"Try re-running with a narrower lens selection,\nor file a bug with the raw output above.\"\n\n### Step 4: Aggregate and Curate Findings\n\nOnce all reviews are complete:\n\n1. **Parse agent outputs**: Extract the JSON block from each agent's response\n   (see the extraction strategy in Step 3). Collect the `summary`, `strengths`,\n   and `findings` arrays from each.\n\n2. **Aggregate across agents**:\n   - Combine all `findings` arrays into a single list\n   - Combine all `strengths` arrays into a single list\n   - Collect all `summary` strings\n\n3. **Deduplicate findings**: Where multiple agents flag the same section with\n   similar concerns, consider merging — but only when the findings address the\n   same underlying concern from different lens perspectives. When in doubt,\n   keep findings separate.\n\n   When merging:\n   - Combine the bodies, attributing each part to its lens\n   - Use the highest severity among the merged findings\n   - Use the highest confidence among the merged findings\n\n4. **Prioritise findings**:\n   - Sort by severity: critical > major > minor > suggestion\n   - Within the same severity, sort by confidence: high > medium > low\n\n5. **Determine suggested verdict**:\n\n   If review configuration provides verdict overrides above, apply those\n   thresholds instead of the defaults below:\n   - If `work_item_revise_severity` is `none`, skip the severity-based REVISE\n     rule (major count rule still applies independently)\n   - If any findings at or above the work item revise severity\n     ({work item revise severity}) exist → suggest `REVISE`\n   - If {work item revise major count} or more `\"major\"` findings exist\n     → suggest `REVISE`\n   - If fewer major findings than the threshold, or only minor\u002Fsuggestion\n     → suggest `COMMENT`\n   - If no findings at all (only strengths) → suggest `APPROVE`\n\n   Verdict meanings:\n   - `APPROVE` — work item is ready for implementation\n   - `REVISE` — work item needs changes before implementation\n   - `COMMENT` — observations only, work item is acceptable as-is\n\n   When presenting a `COMMENT` verdict with major findings, note: \"Work item is\n   acceptable but could be improved — see major findings below.\"\n\n6. **Identify cross-cutting themes**: Look for findings that appear across\n   multiple lenses — issues flagged by 2+ agents reinforce each other and\n   should be highlighted in the summary.\n\n7. **Compose the review summary**:\n\n   ```markdown\n   ## Work Item Review: [Work item Title]\n\n   **Verdict:** [APPROVE | REVISE | COMMENT]\n\n   [Combined assessment: synthesise each agent's summary into 2-3 sentences\n   covering the overall quality of the work item across all lenses]\n\n   ### Cross-Cutting Themes\n   [Issues that multiple lenses identified — these deserve the most attention]\n   - **[Theme]** (flagged by: [lenses]) — [description]\n\n   ### Findings\n\n   #### Critical\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   #### Major\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   #### Minor\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   #### Suggestions\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   ### Strengths\n   - ✅ [Aggregated and deduplicated strengths from all agents]\n\n   ### Recommended Changes\n   [Ordered list of specific, actionable changes to the work item, prioritised by\n   impact. Each should reference the finding(s) it addresses.]\n\n   1. **[Change description]** (addresses: [finding titles])\n      [Specific guidance on what to modify in the work item]\n\n   ---\n   *Review generated by \u002Freview-work-item*\n   ```\n\n8. **Write the review artifact** to `{work_reviews_dir}\u002F`:\n\n   Derive the review filename using the work item stem and the next available\n   review number. The work item stem is the basename of the work item path without\n   the `.md` extension. For example, if the work item is\n   `{work_dir}\u002F0042-improve-search.md` and no prior reviews exist,\n   the review filename is\n   `{work_reviews_dir}\u002F0042-improve-search-review-1.md`.\n\n   To determine the next review number:\n   ```bash\n   mkdir -p {work_reviews_dir}\n   # Glob for existing reviews of this work item\n   ls {work_reviews_dir}\u002F{work-item-stem}-review-*.md 2>\u002Fdev\u002Fnull\n   # Extract the highest number, increment by 1. If none exist, use 1.\n   ```\n\n   Extract the work item's stable 4-digit identifier from its filename using\n   `accelerator work show {path} --field id`\n   (or parse the 4-digit prefix from the filename directly).\n\n#### Populate frontmatter\n\nBefore writing the work item review file, capture metadata and substitute\nthe unified base fields and per-type extras into the template's\nfrontmatter block:\n\n1. Invoke `accelerator corpus metadata derive`\n   to obtain `Current Date\u002FTime (UTC):`.\n2. **Substitute** every field below with the indicated value:\n   - `type:` ← `work-item-review`\n   - `id:` ← the review filename stem (without `.md`), always quoted\n     as a YAML string\n   - `title:` ← `Work Item Review: {work item title}`\n   - `date:` ← the `Current Date\u002FTime (UTC):` value\n   - `author:` ← the author value resolved per `create-work-item\u002FSKILL.md:578-580`\n   - `producer:` ← `review-work-item`\n   - `status:` ← `complete`\n   - `last_updated:` ← the same `Current Date\u002FTime (UTC):` value\n   - `last_updated_by:` ← the same value resolved for `author`\n   - `schema_version:` ← `1` (bare integer, not quoted)\n   - `parent:` ← typed-linkage ref to the parent work item\n     (`\"work-item:NNNN\"`). Fill when the review names a parent;\n     otherwise omit the key.\n   - `target:` ← `\"work-item:\u003C4-digit-id>\"` (e.g. `\"work-item:0042\"`),\n     the typed-linkage ref to the work item under review, per\n     ADR-0034. Always fill — every review has a target.\n   - `relates_to:` ← list of typed-linkage refs to related reviews or\n     artifacts (`[\"work-item-review:NNNN\", ...]`). Fill when prior\n     reviews are explicit; otherwise omit the key.\n   - `work_item_id:` ← the same 4-digit identifier as the `target`\n     payload's id portion (transitional alias — see Migration Notes;\n     the visualiser's `read_ref_keys` consumes this scalar today)\n   - `reviewer:` ← the reviewer value resolved per `create-work-item\u002FSKILL.md:578-580`\n   - `verdict:` ← the verdict from Step 4.5 (`APPROVE | REVISE | COMMENT`)\n   - `lenses:` ← the list of work-item lens names used\n   - `review_number:` ← `N` (the next available review number from the\n     glob above)\n   - `review_pass:` ← `1` (initial-write pass count; re-reviews bump\n     per the Step 7 flow)\n3. Write the file with the substituted frontmatter block, followed by\n   the review summary composed in Step 4.7 and the per-lens results as\n   a final section:\n\n```markdown\n{The full review summary from Step 4.7}\n\n## Per-Lens Results\n\n### {Lens 1 Name}\n\n**Summary**: {agent summary}\n\n**Strengths**:\n{agent strengths}\n\n**Findings**:\n{agent findings — each with severity, confidence, location, and body}\n\n### {Lens 2 Name}\n\n...\n```\n\nThe `target:` field stores the work item's stable 4-digit identifier\nas a typed-linkage key (e.g. `\"work-item:0042\"`) per ADR-0034,\nproviding resilience against work item renames. A `work_item_id:`\nfield is also emitted as a transitional alias carrying the same\n4-digit identifier — the visualiser's `read_ref_keys` consumes it\nas the primary work-item cross-reference key today. Both fields\nencode the same edge; the duplication is bounded by the visualiser\nconsumer update.\n\n**Validate the frontmatter**: after writing the review file, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cthe review file path>\n```\n\nIf it exits non-zero, the document violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n### Step 5: Present the Review\n\nPresent the composed review summary from Step 4.7 to the user.\n\nAfter presenting, offer the user control before proceeding to iteration:\n\n```\nThe review is complete. Verdict: [verdict]\n```\n\nUse the `AskUserQuestion` tool with four options:\n\n1. **Address findings** — edit the work item to resolve issues\n2. **Change the verdict** — currently: [verdict]\n3. **Discuss specific findings** — explore any finding in more detail\n4. **Re-run specific lenses** — adjust focus and re-review\n\n### Step 6: Collaborative Work Item Iteration\n\nAfter presenting the review:\n\n1. **Discuss findings with the user**:\n   - Ask which recommendations they want to address\n   - Clarify any findings that need more context\n\n2. **Edit the work item based on agreed changes**:\n   - Use the Edit tool to modify the work item file directly\n   - Make targeted edits to the relevant work item sections (Summary, Context,\n     Requirements, Acceptance Criteria, etc.)\n   - Do NOT modify the `status` field — that is a separate workflow decision\n   - Preserve the work item's existing frontmatter and section structure\n\n3. **Summarise changes made**:\n   ```\n   I've made the following changes to the work item:\n   - [Change 1] — addressing [finding]\n   - [Change 2] — addressing [finding]\n   - [Skipped] — [finding discussed and decided not to address, with reason]\n   ```\n\n### Step 7: Offer Re-Review\n\nAfter edits are complete, use the `AskUserQuestion` tool with two options:\n\n1. **Yes, run another review pass** — re-run the relevant lenses to verify the\n   changes address the findings\n2. **No, done** — exit without re-reviewing\n\nIf the user chooses option 1:\n\n- Re-run **only the lenses that had findings** in the previous pass\n- Use the same spawn pattern and JSON extraction strategy from Steps 3-4\n- Compare previous findings against new findings to determine resolution status\n- Present a shorter, delta-focused review:\n  ```\n  ## Re-Review: [Work item Title]\n\n  **Verdict:** [APPROVE | REVISE | COMMENT]\n\n  ### Previously Identified Issues\n  - [emoji] **[Lens]**: [title] — Resolved \u002F Partially resolved \u002F Still present\n\n  ### New Issues Introduced\n  - [emoji] **[Lens]**: [title] — [brief description]\n\n  ### Assessment\n  [Whether the work item is now ready for implementation or needs further iteration]\n  ```\n\nAfter composing the re-review summary, **update the review artifact**\nas a single write operation:\n\n1. Read the full content of the existing review document at\n   `{work_reviews_dir}\u002F{work-item-stem}-review-{N}.md`\n2. If the existing review file's frontmatter cannot be parsed (malformed\n   YAML or missing `---` delimiters), warn the user and write a fresh\n   `-review-{N+1}.md` file instead of appending in place\n3. In memory, update exactly four frontmatter fields — `verdict`,\n   `review_pass`, `last_updated`, and `last_updated_by` — preserving\n   all other fields and body content verbatim. The `date` field retains\n   the original-review timestamp; only `last_updated` advances on\n   re-review. (`last_updated_by` may match `reviewer` if the\n   re-reviewer is the same person, but is computed independently.)\n\n   **Pre-0066-artifact handling**: when the re-reviewed artifact lacks\n   `last_updated:` and\u002For `last_updated_by:` (it was written pre-0066),\n   insert those fields rather than treating their absence as\n   malformed-frontmatter. Only an unparseable YAML block or missing\n   `---` delimiters triggers the fresh-`-review-{N+1}.md` fallback.\n4. Append the re-review section at the end of the content\n5. Write the complete modified content back to the same file in one\n   operation\n\nThe document reads chronologically: initial review, per-lens results,\nthen re-review sections in order. The frontmatter always reflects the\nlatest verdict and pass count:\n\n```markdown\n\n## Re-Review (Pass {N}) — {date}\n\n**Verdict:** {verdict}\n\n### Previously Identified Issues\n- {emoji} **{Lens}**: {title} — {Resolved | Partially resolved | Still present}\n\n### New Issues Introduced\n- {emoji} **{Lens}**: {title} — {brief description}\n\n### Assessment\n{Whether the work item is now ready for implementation or needs further iteration}\n```\n\nIf the user declines or the re-review shows all clear, the review is complete.\n\n## Important Guidelines\n\n1. **Read the work item fully** before doing anything else\n\n2. **Spawn agents in parallel** — the work item lenses are independent and\n   should run concurrently for efficiency\n\n3. **Synthesise, don't concatenate** — your value is in compiling a balanced\n   view across lenses, identifying themes, and prioritising actionable\n   recommendations\n\n4. **Do not modify the work item's `status` field** — a REVISE verdict does not\n   automatically change the work item's status; that transition belongs to a\n   separate workflow decision by the team\n\n5. **Do not run codebase exploration agents** — the reviewer agents stay\n   inside the work item and any documents it explicitly references; source code\n   is out of scope for work item review\n\n6. **Be balanced** — highlight strengths alongside concerns\n\n7. **Prioritise by impact** — structural issues that would block implementation\n   matter more than surface-level polish\n\n8. **Handle malformed agent output gracefully** — use the `suggestion` severity\n   fallback (not `major`) so a single flaky agent does not force a REVISE\n   verdict\n\n9. **Use emoji severity prefixes consistently** — ? critical, ? major,\n   ? minor\u002Fsuggestion, ✅ strengths. **IMPORTANT**: Use the actual Unicode\n   emoji characters (? ? ? ✅), NOT text shortcodes.\n\n## What NOT to Do\n\n- Don't skip writing the review artifact — always persist to\n  `{work_reviews_dir}\u002F` so the review is visible to the team\n- Don't modify the work item's `status` field during review\n- Don't run codebase exploration agents or read source files\n- Don't skip the lens selection step — always confirm with the user\n- Don't present raw agent output — always aggregate and curate\n- Don't make work item edits without user agreement\n- Don't post findings as individual items for positive feedback —\n  strengths go in the summary only\n\n## Relationship to Other Commands\n\nWork item review sits in the work item lifecycle between authoring and implementation:\n\n1. `\u002Fcreate-work-item` or `\u002Fextract-work-items` — Author or capture the work item\n2. `\u002Flist-work-items` — Discover work items available for review\n3. `\u002Freview-work-item` — Review and iterate work item quality (this command)\n4. `\u002Fupdate-work-item` — Apply status transitions after review decisions\n5. `\u002Fcreate-plan` — Create an implementation plan from an approved work item\n\n!`accelerator config instructions review-work-item --fail-safe`\n","# Review Work Item\n\n!`accelerator config context --skill review-work-item --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n!`accelerator config review work-item --fail-safe`\n\n**Work items directory**: !`accelerator config path work --fail-safe`\n**Work item reviews directory**: !`accelerator config path review_work --fail-safe`\n\n## Work Item Review Template\n\nThe template below defines the frontmatter and body structure that every\nwork item review must carry. Read it now — use it to guide what information\nyou record in Steps 3-4 and what shape you persist in Step 4.8.\n\n!`accelerator config template work-item-review --fail-safe`\n\nYou are tasked with reviewing a work item through quality lenses and then\ncollaboratively iterating the work item based on findings.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if a work item path or ID was provided**: invoke the\n   resolver:\n\n   ```\n   accelerator work resolve \u003Cargument>\n   ```\n\n   The resolver respects `work.id_pattern` and accepts paths, full IDs\n   (`PROJ-0042`), and bare numbers.\n\n   - **Exit 0**: stdout is the absolute path. Read the work item\n     immediately and FULLY, then begin the review process.\n   - **Exit 1**: unrecognised input. Print the resolver's error and\n     offer to run `\u002Flist-work-items`.\n   - **Exit 2**: ambiguous match. The resolver lists candidates with\n     source-category tags. Ask the user to disambiguate by re-running\n     with a full ID or path.\n   - **Exit 3**: no match. Print the resolver's error and offer to run\n     `\u002Flist-work-items`.\n   - **Exit 6**: the argument names a real file outside the managed work\n     directory. Print the resolver's error and offer to run\n     `\u002Flist-work-items`.\n   - If optional focus arguments were provided (e.g., \"focus on testability\"),\n     note them for lens selection.\n\n2. **If no work item path or number provided**, respond with:\n\n```\nI'll help you review a work item. Please provide:\n1. The path to the work item file (e.g., `{work_dir}\u002F0042-my-work-item.md`)\n2. (Optional) A work item number shorthand (e.g., `\u002Freview-work-item 42`)\n3. (Optional) Focus areas to emphasise (e.g., \"focus on testability\")\n\nTip: Use `\u002Flist-work-items` to find the work item you want to review.\n```\n\nThen wait for the user's input.\n\n## Available Review Lenses\n\n| Lens             | Lens Skill          | Focus                                                                   |\n|------------------|---------------------|-------------------------------------------------------------------------|\n| **Clarity**      | `clarity-lens`      | Unambiguous referents, internal consistency, jargon handling            |\n| **Completeness** | `completeness-lens` | Section presence, content density, kind-appropriate content             |\n| **Dependency**   | `dependency-lens`   | Implied couplings not captured — blockers, consumers, external systems  |\n| **Scope**        | `scope-lens`        | Right-sized, single coherent unit of work; decomposition; orthogonality |\n| **Testability**  | `testability-lens`  | Measurable criteria, verifiable outcomes, verification framing          |\n\n> Note: completeness flags an *absent* Dependencies section; dependency flags\n> an *empty or underspecified* section whose contents fail to name every\n> coupling the work item implies.\n\n## Process Steps\n\n### Step 1: Read and Understand the Work Item\n\n1. **Read the work item file FULLY** — never use limit\u002Foffset\n2. **Parse the frontmatter** to note `kind` (bug, story, spike, epic, etc.)\n   and `status`\n3. **Read any documents referenced in the References section** — these provide\n   context the lenses may need; do not read source code\n4. **Check for existing reviews**: Glob for review documents matching\n   `{work_reviews_dir}\u002F{work-item-stem}-review-*.md`. If any are found:\n   - Read the most recent review document (highest review number)\n   - Note the previous verdict, review pass count, and key findings\n   - Inform the user: \"I found {N} previous review(s) of this work item. The\n     most recent (review {N}, verdict: {verdict}) will be used as context.\"\n   - The agents do NOT receive the previous review — they review the work item\n     fresh. But the aggregation step (Step 4) should reference the previous\n     review when composing cross-cutting themes and the assessment.\n   - If the prior review file exists but cannot be parsed (malformed\n     frontmatter), warn the user and proceed as if no prior review exists.\n\n   The new review creates a **new file** with the next review number (e.g.,\n   `-review-2.md`). Previous review files are never modified.\n\n### Step 2: Select Review Lenses\n\nBy default, run every lens registered in `BUILTIN_WORK_ITEM_LENSES` unless the\nuser has provided focus arguments or config restricts the selection. The five\nwork item lenses cover orthogonal concerns, so there is no relevance-based\nauto-selection.\n\n**If the user provided focus arguments:**\n\n- Map the focus areas to the corresponding lenses\n- Include any additional lenses that are clearly relevant\n- Briefly explain which lenses you're running\n\n**If no focus arguments were provided:**\n\nRun all built-in work item lenses unless:\n- A lens is listed in `disabled_lenses` — remove it from the active set\n- The user's configured `core_lenses` has filtered this to a subset (see below)\n\nWhen `core_lenses` is set in config, apply it as the *minimum required set*;\nadd any remaining non-disabled lenses up to `max_lenses`. This means users\nwho previously pinned `core_lenses` to the Phase 4 work item lenses\n(`completeness`, `testability`, `clarity`) will also receive `scope` and\n`dependency` on upgrade, unless they add those names to `disabled_lenses` or\nset `max_lenses` to their subset size.\n\nPresent the selection briefly — enumerate the chosen lenses with a one-line\nfocus each — then use the `AskUserQuestion` tool with two options:\n\n1. **Yes, use the proposed lenses** — run the review with the selected lenses\n2. **No, specify which lenses to use** — adjust the selection before running\n\nThe confirmation gate is preserved even though the default always selects every\nlens; the gate is useful when focus args or config have narrowed the set.\n\nExample (default path, no focus args, no `core_lenses` restriction):\n\n```\nI'll review this work item through all work item lenses (clarity, completeness,\ndependency, scope, testability).\n```\n\nWait for the user's answer before spawning reviewers. If they choose option 2,\nask which lenses they want using a **plain-text question only** — do NOT use\n`AskUserQuestion` for this follow-up (the lens list is too large for the\n4-option limit). If any lens name is unrecognised, seek clarification. Once\nconfirmed, update the selection and re-present it using the same\n`AskUserQuestion` proceed\u002Fadjust pattern. This loop is user-controlled with\nno hard termination limit.\n\n### Step 3: Spawn Review Agents\n\nFor each selected lens, spawn the {reviewer agent} agent with a prompt that\nincludes the paths to the lens skill and output format files. Do NOT read these\nfiles yourself — the agent reads them in its own context.\n\nCompose each agent's prompt following this template:\n\n```\nYou are reviewing a work item through the [lens name] lens.\n\n## Context\n\nThe work item is at [path]. Read it fully.\nAlso read any source documents listed in the work item's References section.\n\n## Analysis Strategy\n\n1. Read your lens skill and output format files (see paths below)\n2. Read the work item file fully\n3. Read referenced documents from the work item's References section if present\n4. Evaluate the work item through your lens, applying each key question\n5. Reference specific work item sections in your findings using the `location`\n   field (e.g., \"Acceptance Criteria\", \"Requirements\", \"Frontmatter: kind\")\n\nIMPORTANT: Do not evaluate the codebase — work item content (and any documents\nit explicitly references) is the sole artefact under review. Do not run\ncodebase exploration agents or read source files unless the work item's\nReferences section explicitly links to them.\n\n## Lens\n\nRead the lens skill at the path listed in the Lens Catalogue table in the\nreview configuration above. If no review configuration is present, use:\n${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Freview\u002Flenses\u002F[lens]-lens\u002FSKILL.md\n\n## Output Format\n\nRead the output format at:\n${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Freview\u002Foutput-formats\u002Fwork-item-review-output-format\u002FSKILL.md\n\nIMPORTANT: Return your analysis as a single JSON code block. Do not include\nprose outside the JSON block.\n```\n\nSpawn all selected agents **in parallel** using the Task tool with\n`subagent_type: \"!`accelerator config agent reviewer --fail-safe`\"`.\n\n**IMPORTANT**: Wait for ALL review agents to complete before proceeding.\n\n**Handling malformed agent output**:\n\nIf an agent's response is not a clean JSON block, apply this extraction\nstrategy:\n\n1. Look for a JSON code block fenced with triple backticks (optionally with\n   a `json` language tag)\n2. If found, extract and parse the content within the fences\n3. If the extracted JSON is valid, use it normally\n4. If no JSON code block is found, or the JSON within it is invalid, apply\n   the fallback: treat the agent's entire output as a single finding with\n   `\"suggestion\"` severity (marked `synthetic: true`), attributed to that\n   agent's lens\n\n   Note: `\"suggestion\"` severity is used here (not `\"major\"` as in\n   `review-plan`) so a single flaky agent cannot deterministically force a\n   REVISE verdict when `work_item_revise_severity` is `major` or higher.\n\nWhen falling back, warn the user that the agent's output could not be parsed\nand present the raw agent output so the user can see what the agent found.\nInclude remediation guidance: \"Try re-running with a narrower lens selection,\nor file a bug with the raw output above.\"\n\n### Step 4: Aggregate and Curate Findings\n\nOnce all reviews are complete:\n\n1. **Parse agent outputs**: Extract the JSON block from each agent's response\n   (see the extraction strategy in Step 3). Collect the `summary`, `strengths`,\n   and `findings` arrays from each.\n\n2. **Aggregate across agents**:\n   - Combine all `findings` arrays into a single list\n   - Combine all `strengths` arrays into a single list\n   - Collect all `summary` strings\n\n3. **Deduplicate findings**: Where multiple agents flag the same section with\n   similar concerns, consider merging — but only when the findings address the\n   same underlying concern from different lens perspectives. When in doubt,\n   keep findings separate.\n\n   When merging:\n   - Combine the bodies, attributing each part to its lens\n   - Use the highest severity among the merged findings\n   - Use the highest confidence among the merged findings\n\n4. **Prioritise findings**:\n   - Sort by severity: critical > major > minor > suggestion\n   - Within the same severity, sort by confidence: high > medium > low\n\n5. **Determine suggested verdict**:\n\n   If review configuration provides verdict overrides above, apply those\n   thresholds instead of the defaults below:\n   - If `work_item_revise_severity` is `none`, skip the severity-based REVISE\n     rule (major count rule still applies independently)\n   - If any findings at or above the work item revise severity\n     ({work item revise severity}) exist → suggest `REVISE`\n   - If {work item revise major count} or more `\"major\"` findings exist\n     → suggest `REVISE`\n   - If fewer major findings than the threshold, or only minor\u002Fsuggestion\n     → suggest `COMMENT`\n   - If no findings at all (only strengths) → suggest `APPROVE`\n\n   Verdict meanings:\n   - `APPROVE` — work item is ready for implementation\n   - `REVISE` — work item needs changes before implementation\n   - `COMMENT` — observations only, work item is acceptable as-is\n\n   When presenting a `COMMENT` verdict with major findings, note: \"Work item is\n   acceptable but could be improved — see major findings below.\"\n\n6. **Identify cross-cutting themes**: Look for findings that appear across\n   multiple lenses — issues flagged by 2+ agents reinforce each other and\n   should be highlighted in the summary.\n\n7. **Compose the review summary**:\n\n   ```markdown\n   ## Work Item Review: [Work item Title]\n\n   **Verdict:** [APPROVE | REVISE | COMMENT]\n\n   [Combined assessment: synthesise each agent's summary into 2-3 sentences\n   covering the overall quality of the work item across all lenses]\n\n   ### Cross-Cutting Themes\n   [Issues that multiple lenses identified — these deserve the most attention]\n   - **[Theme]** (flagged by: [lenses]) — [description]\n\n   ### Findings\n\n   #### Critical\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   #### Major\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   #### Minor\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   #### Suggestions\n   - ? **[Lens]**: [title]\n     **Location**: [work item section]\n     [First 1-2 sentences of body as summary]\n\n   ### Strengths\n   - ✅ [Aggregated and deduplicated strengths from all agents]\n\n   ### Recommended Changes\n   [Ordered list of specific, actionable changes to the work item, prioritised by\n   impact. Each should reference the finding(s) it addresses.]\n\n   1. **[Change description]** (addresses: [finding titles])\n      [Specific guidance on what to modify in the work item]\n\n   ---\n   *Review generated by \u002Freview-work-item*\n   ```\n\n8. **Write the review artifact** to `{work_reviews_dir}\u002F`:\n\n   Derive the review filename using the work item stem and the next available\n   review number. The work item stem is the basename of the work item path without\n   the `.md` extension. For example, if the work item is\n   `{work_dir}\u002F0042-improve-search.md` and no prior reviews exist,\n   the review filename is\n   `{work_reviews_dir}\u002F0042-improve-search-review-1.md`.\n\n   To determine the next review number:\n   ```bash\n   mkdir -p {work_reviews_dir}\n   # Glob for existing reviews of this work item\n   ls {work_reviews_dir}\u002F{work-item-stem}-review-*.md 2>\u002Fdev\u002Fnull\n   # Extract the highest number, increment by 1. If none exist, use 1.\n   ```\n\n   Extract the work item's stable 4-digit identifier from its filename using\n   `accelerator work show {path} --field id`\n   (or parse the 4-digit prefix from the filename directly).\n\n#### Populate frontmatter\n\nBefore writing the work item review file, capture metadata and substitute\nthe unified base fields and per-type extras into the template's\nfrontmatter block:\n\n1. Invoke `accelerator corpus metadata derive`\n   to obtain `Current Date\u002FTime (UTC):`.\n2. **Substitute** every field below with the indicated value:\n   - `type:` ← `work-item-review`\n   - `id:` ← the review filename stem (without `.md`), always quoted\n     as a YAML string\n   - `title:` ← `Work Item Review: {work item title}`\n   - `date:` ← the `Current Date\u002FTime (UTC):` value\n   - `author:` ← the author value resolved per `create-work-item\u002FSKILL.md:578-580`\n   - `producer:` ← `review-work-item`\n   - `status:` ← `complete`\n   - `last_updated:` ← the same `Current Date\u002FTime (UTC):` value\n   - `last_updated_by:` ← the same value resolved for `author`\n   - `schema_version:` ← `1` (bare integer, not quoted)\n   - `parent:` ← typed-linkage ref to the parent work item\n     (`\"work-item:NNNN\"`). Fill when the review names a parent;\n     otherwise omit the key.\n   - `target:` ← `\"work-item:\u003C4-digit-id>\"` (e.g. `\"work-item:0042\"`),\n     the typed-linkage ref to the work item under review, per\n     ADR-0034. Always fill — every review has a target.\n   - `relates_to:` ← list of typed-linkage refs to related reviews or\n     artifacts (`[\"work-item-review:NNNN\", ...]`). Fill when prior\n     reviews are explicit; otherwise omit the key.\n   - `work_item_id:` ← the same 4-digit identifier as the `target`\n     payload's id portion (transitional alias — see Migration Notes;\n     the visualiser's `read_ref_keys` consumes this scalar today)\n   - `reviewer:` ← the reviewer value resolved per `create-work-item\u002FSKILL.md:578-580`\n   - `verdict:` ← the verdict from Step 4.5 (`APPROVE | REVISE | COMMENT`)\n   - `lenses:` ← the list of work-item lens names used\n   - `review_number:` ← `N` (the next available review number from the\n     glob above)\n   - `review_pass:` ← `1` (initial-write pass count; re-reviews bump\n     per the Step 7 flow)\n3. Write the file with the substituted frontmatter block, followed by\n   the review summary composed in Step 4.7 and the per-lens results as\n   a final section:\n\n```markdown\n{The full review summary from Step 4.7}\n\n## Per-Lens Results\n\n### {Lens 1 Name}\n\n**Summary**: {agent summary}\n\n**Strengths**:\n{agent strengths}\n\n**Findings**:\n{agent findings — each with severity, confidence, location, and body}\n\n### {Lens 2 Name}\n\n...\n```\n\nThe `target:` field stores the work item's stable 4-digit identifier\nas a typed-linkage key (e.g. `\"work-item:0042\"`) per ADR-0034,\nproviding resilience against work item renames. A `work_item_id:`\nfield is also emitted as a transitional alias carrying the same\n4-digit identifier — the visualiser's `read_ref_keys` consumes it\nas the primary work-item cross-reference key today. Both fields\nencode the same edge; the duplication is bounded by the visualiser\nconsumer update.\n\n**Validate the frontmatter**: after writing the review file, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cthe review file path>\n```\n\nIf it exits non-zero, the document violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n### Step 5: Present the Review\n\nPresent the composed review summary from Step 4.7 to the user.\n\nAfter presenting, offer the user control before proceeding to iteration:\n\n```\nThe review is complete. Verdict: [verdict]\n```\n\nUse the `AskUserQuestion` tool with four options:\n\n1. **Address findings** — edit the work item to resolve issues\n2. **Change the verdict** — currently: [verdict]\n3. **Discuss specific findings** — explore any finding in more detail\n4. **Re-run specific lenses** — adjust focus and re-review\n\n### Step 6: Collaborative Work Item Iteration\n\nAfter presenting the review:\n\n1. **Discuss findings with the user**:\n   - Ask which recommendations they want to address\n   - Clarify any findings that need more context\n\n2. **Edit the work item based on agreed changes**:\n   - Use the Edit tool to modify the work item file directly\n   - Make targeted edits to the relevant work item sections (Summary, Context,\n     Requirements, Acceptance Criteria, etc.)\n   - Do NOT modify the `status` field — that is a separate workflow decision\n   - Preserve the work item's existing frontmatter and section structure\n\n3. **Summarise changes made**:\n   ```\n   I've made the following changes to the work item:\n   - [Change 1] — addressing [finding]\n   - [Change 2] — addressing [finding]\n   - [Skipped] — [finding discussed and decided not to address, with reason]\n   ```\n\n### Step 7: Offer Re-Review\n\nAfter edits are complete, use the `AskUserQuestion` tool with two options:\n\n1. **Yes, run another review pass** — re-run the relevant lenses to verify the\n   changes address the findings\n2. **No, done** — exit without re-reviewing\n\nIf the user chooses option 1:\n\n- Re-run **only the lenses that had findings** in the previous pass\n- Use the same spawn pattern and JSON extraction strategy from Steps 3-4\n- Compare previous findings against new findings to determine resolution status\n- Present a shorter, delta-focused review:\n  ```\n  ## Re-Review: [Work item Title]\n\n  **Verdict:** [APPROVE | REVISE | COMMENT]\n\n  ### Previously Identified Issues\n  - [emoji] **[Lens]**: [title] — Resolved \u002F Partially resolved \u002F Still present\n\n  ### New Issues Introduced\n  - [emoji] **[Lens]**: [title] — [brief description]\n\n  ### Assessment\n  [Whether the work item is now ready for implementation or needs further iteration]\n  ```\n\nAfter composing the re-review summary, **update the review artifact**\nas a single write operation:\n\n1. Read the full content of the existing review document at\n   `{work_reviews_dir}\u002F{work-item-stem}-review-{N}.md`\n2. If the existing review file's frontmatter cannot be parsed (malformed\n   YAML or missing `---` delimiters), warn the user and write a fresh\n   `-review-{N+1}.md` file instead of appending in place\n3. In memory, update exactly four frontmatter fields — `verdict`,\n   `review_pass`, `last_updated`, and `last_updated_by` — preserving\n   all other fields and body content verbatim. The `date` field retains\n   the original-review timestamp; only `last_updated` advances on\n   re-review. (`last_updated_by` may match `reviewer` if the\n   re-reviewer is the same person, but is computed independently.)\n\n   **Pre-0066-artifact handling**: when the re-reviewed artifact lacks\n   `last_updated:` and\u002For `last_updated_by:` (it was written pre-0066),\n   insert those fields rather than treating their absence as\n   malformed-frontmatter. Only an unparseable YAML block or missing\n   `---` delimiters triggers the fresh-`-review-{N+1}.md` fallback.\n4. Append the re-review section at the end of the content\n5. Write the complete modified content back to the same file in one\n   operation\n\nThe document reads chronologically: initial review, per-lens results,\nthen re-review sections in order. The frontmatter always reflects the\nlatest verdict and pass count:\n\n```markdown\n\n## Re-Review (Pass {N}) — {date}\n\n**Verdict:** {verdict}\n\n### Previously Identified Issues\n- {emoji} **{Lens}**: {title} — {Resolved | Partially resolved | Still present}\n\n### New Issues Introduced\n- {emoji} **{Lens}**: {title} — {brief description}\n\n### Assessment\n{Whether the work item is now ready for implementation or needs further iteration}\n```\n\nIf the user declines or the re-review shows all clear, the review is complete.\n\n## Important Guidelines\n\n1. **Read the work item fully** before doing anything else\n\n2. **Spawn agents in parallel** — the work item lenses are independent and\n   should run concurrently for efficiency\n\n3. **Synthesise, don't concatenate** — your value is in compiling a balanced\n   view across lenses, identifying themes, and prioritising actionable\n   recommendations\n\n4. **Do not modify the work item's `status` field** — a REVISE verdict does not\n   automatically change the work item's status; that transition belongs to a\n   separate workflow decision by the team\n\n5. **Do not run codebase exploration agents** — the reviewer agents stay\n   inside the work item and any documents it explicitly references; source code\n   is out of scope for work item review\n\n6. **Be balanced** — highlight strengths alongside concerns\n\n7. **Prioritise by impact** — structural issues that would block implementation\n   matter more than surface-level polish\n\n8. **Handle malformed agent output gracefully** — use the `suggestion` severity\n   fallback (not `major`) so a single flaky agent does not force a REVISE\n   verdict\n\n9. **Use emoji severity prefixes consistently** — ? critical, ? major,\n   ? minor\u002Fsuggestion, ✅ strengths. **IMPORTANT**: Use the actual Unicode\n   emoji characters (? ? ? ✅), NOT text shortcodes.\n\n## What NOT to Do\n\n- Don't skip writing the review artifact — always persist to\n  `{work_reviews_dir}\u002F` so the review is visible to the team\n- Don't modify the work item's `status` field during review\n- Don't run codebase exploration agents or read source files\n- Don't skip the lens selection step — always confirm with the user\n- Don't present raw agent output — always aggregate and curate\n- Don't make work item edits without user agreement\n- Don't post findings as individual items for positive feedback —\n  strengths go in the summary only\n\n## Relationship to Other Commands\n\nWork item review sits in the work item lifecycle between authoring and implementation:\n\n1. `\u002Fcreate-work-item` or `\u002Fextract-work-items` — Author or capture the work item\n2. `\u002Flist-work-items` — Discover work items available for review\n3. `\u002Freview-work-item` — Review and iterate work item quality (this command)\n4. `\u002Fupdate-work-item` — Apply status transitions after review decisions\n5. `\u002Fcreate-plan` — Create an implementation plan from an approved work item\n\n!`accelerator config instructions review-work-item --fail-safe`\n",{"name":5,"description":7,"allowed-tools":44,"argument-hint":49},[45,46,47,48],"Bash(accelerator config *)","Bash(accelerator work *)","Bash(accelerator corpus metadata derive)","Bash(accelerator corpus frontmatter validate *)","[path to work item file]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fwork\u002Freview-work-item",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-12 04:07:28",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add atomicinnovation\u002Faccelerator --skill review-work-item",{"tool":64,"command":65},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill review-work-item",{"tool":67,"command":68},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill review-work-item","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",true,[72,78,82,86,90,94],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fopenai.yaml","REFERENCE","参考文档",231,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fresearch-workflow\u002Fcodex-paper-skills-main\u002Fpaper_skills\u002Fpaper-analysis\u002Fagents\u002Fopenai.yaml",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Fbenchmark.json",3901,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002Fevals\u002Fbenchmark.json",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Fevals.json",3615,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002Fevals\u002Fevals.json",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Ffiles\u002Ffull-review-flow\u002Fwork-item.md",3495,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002Fevals\u002Ffiles\u002Ffull-review-flow\u002Fwork-item.md",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fexperiment-analysis.md",707,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fresearch-workflow\u002Fcodex-paper-skills-main\u002Fpaper_skills\u002Fpaper-analysis\u002Freferences\u002Fexperiment-analysis.md",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fmodel-selection.md",978,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fresearch-workflow\u002Fcodex-paper-skills-main\u002Fpaper_skills\u002Fpaper-analysis\u002Freferences\u002Fmodel-selection.md",[99,133,152,174,192,215],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":115,"publishedAt":39},"01M70S7PFGVATJREBFEGPJB718","explore-pr","Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fexplore-pr\u002FSKILL.md",[105,110],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[116,117,118,119,120,121,122,123,124,125,25,126,127,33,128,129,130,23,131,132],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","number","URL","code","architecture","reviewer","notes","change",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":39},"01M6DY04WBTMFV96JMBP5ZXVFX","update-work-item","Update fields (status, priority, tags, parent, etc.) of an existing work item. Use to transition status, change priority, manage tags, or edit any frontmatter field. No transition enforcement — arbitrary changes are allowed.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002FSKILL.md",[],[21,140,141,19,142,143,24,33,132,37,144,38,145,146,28,147,148,149,150,151],"update","update work item","enforcement","manage","edit","status","transition","Existing","tags","changes","fields","op",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":39},"01M6DY0106CF15CYEJHZM14GBZ","sync-work-items","Reconcile local work items in meta\u002Fwork\u002F with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items\u002FSKILL.md",[],[21,159,160,161,162,163,164,33,165,132,166,167,168,169,170,171,172,37,173,28,25],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":39},"01M6HNF86984S4XK21Q26VZA21","sync-work-items-recovery","Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items-recovery\u002FSKILL.md",[],[181,21,182,159,160,183,184,185,186,187,188,189,190,191],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":201,"publishedAt":39},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item","Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",[198],{"categoryNo":199,"categoryName":200,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000008","测试与质量",[202,203,21,204,19,205,206,207,208,209,210,33,211,212,37,38,30,213,31,126,214,28],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","grilling","gaps",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":221,"publishedAt":39},"01M6DXZMY4QJXX8V72CMWR2MZ1","rekey-work-items","Converge every work item's ID onto the configured work.id_pattern, renaming files and rewriting references across meta\u002F. Use after changing work.id_pattern or work.key, when existing work items should take IDs in the new shape, or to finish or undo an interrupted re-key.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frekey-work-items\u002FSKILL.md",[],[21,222,223,162,224,24,33,225,226,227,228,37,229,230,38,231,232,19,121,233,147,25],"rekey work items","ids","files","across","id","references","shape","pattern","take","finish","converge","new"]