[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXTHG7ZC9JFCXD5KC25MPF":3,"skill-same:01M6DXTHG7ZC9JFCXD5KC25MPF":76},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6DXTHG7ZC9JFCXD5KC25MPF","review-plan",null,"Review an implementation plan through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a plan before implementation.","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\u002Fplanning\u002Freview-plan\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"review plan","plan","review","user","when","implementation plan","iterate","evaluate","to plan","frontmatter","path","implementation","use","quality","Bash","file","metadata","config","validate","2026-11-10 10:12:30",false,"---\nname: review-plan\ndescription: Review an implementation plan through multiple quality lenses and\n  collaboratively iterate based on findings. Use when the user wants to evaluate\n  a plan before implementation.\nargument-hint: \"[path to plan file]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator corpus metadata derive)\n  - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Review Plan\n\n!`accelerator config context --skill review-plan --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 plan --fail-safe`\n\n**Plans directory**: !`accelerator config path plans --fail-safe`\n**Plan reviews directory**: !`accelerator config path review_plans --fail-safe`\n\n## Plan Review Template\n\nThe template below defines the frontmatter and body structure that every\nplan 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 plan-review --fail-safe`\n\nYou are tasked with reviewing an implementation plan through multiple quality\nlenses and then collaboratively iterating the plan based on findings.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if a plan path was provided**:\n\n- If a plan path was provided, read it immediately and FULLY\n- If optional focus arguments were provided (e.g., \"security and architecture\"),\n  note them for lens selection\n- Begin the review process\n\n2. **If no plan path provided**, respond with:\n\n```\nI'll help you review an implementation plan. Please provide:\n1. The path to the plan file (e.g., `{plans directory}\u002F2025-01-08-ENG-1478-feature.md`)\n2. (Optional) Focus areas to emphasise (e.g., \"focus on security and architecture\")\n\nTip: You can invoke this command with arguments:\n  `\u002Freview-plan {plans directory}\u002F2025-01-08-feature.md`\n  `\u002Freview-plan {plans directory}\u002F2025-01-08-feature.md focus on security and architecture`\n```\n\nThen wait for the user's input.\n\n## Available Review Lenses\n\n| Lens               | Lens Skill                    | Focus                                                                 |\n|--------------------|-------------------------------|-----------------------------------------------------------------------|\n| **Architecture**   | `architecture-lens`           | Modularity, coupling, scalability, evolutionary design, tradeoffs     |\n| **Security**       | `security-lens`               | Threats, missing protections, STRIDE analysis, OWASP coverage         |\n| **Test Coverage**  | `test-coverage-lens`          | Testing strategy, test pyramid, edge cases, isolation, risk coverage  |\n| **Code Quality**   | `code-quality-lens`           | Design principles, testability, error handling, complexity management |\n| **Standards**      | `standards-lens`              | Project conventions, API standards, accessibility                     |\n| **Usability**      | `usability-lens`              | Developer experience, API ergonomics, configuration, onboarding       |\n| **Performance**    | `performance-lens`            | Algorithmic efficiency, resource usage, concurrency, caching          |\n| **Documentation**  | `documentation-lens`          | Documentation completeness, accuracy, audience fit                    |\n| **Database**       | `database-lens`               | Migration safety, schema design, query correctness, integrity         |\n| **Correctness**    | `correctness-lens`            | Logical validity, boundary conditions, state management, concurrency  |\n| **Compatibility**  | `compatibility-lens`          | API contracts, cross-platform, protocol compliance, deps              |\n| **Portability**    | `portability-lens`            | Environment independence, deployment flexibility, vendor lock         |\n| **Safety**         | `safety-lens`                 | Data loss prevention, operational safety, protective mechanisms       |\n\n## Process Steps\n\n### Step 1: Read and Understand the Plan\n\n1. **Read the plan file FULLY** — never use limit\u002Foffset\n2. **Read any files the plan references** — work items, related research, key\n   source files mentioned\n3. **Understand the plan's scope**:\n  - What technologies and layers does it touch?\n  - Does it involve APIs, UI, infrastructure, data models?\n  - What's the complexity and risk profile?\n  - Who are the consumers — other developers, services, end users?\n\n4. **Check for existing reviews**: Glob for review documents matching\n   `{plan reviews directory}\u002F{plan-stem}-review-*.md`. If any are found:\n   - Read the most recent review document (highest review number) to\n     understand what was previously reviewed\n   - Note the previous verdict, review pass count, and key findings\n   - Inform the user: \"I found {N} previous review(s) of this plan. 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 plan\n     fresh. But the aggregation step (Step 4) should reference the previous\n     review when composing cross-cutting themes and the assessment:\n     specifically, note which findings from the previous review recur in\n     the new review and which appear to have been addressed by plan changes.\n   - If the prior review file exists but cannot be parsed (e.g., malformed\n     frontmatter from a partial write), warn the user and proceed as if no\n     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 or deleted —\n   the full review history is preserved on disk.\n\n### Step 2: Select Review Lenses\n\nDetermine which lenses are relevant based on the plan's scope and any user-\nprovided focus arguments.\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 to the plan's scope\n- Briefly explain which lenses you're running and why\n\n**If no focus arguments were provided, auto-detect relevance:**\n\nTake time to think carefully about which lenses apply based on:\n\n- **Architecture** — relevant for most plans; skip only for trivial, single-file\n  changes\n- **Code Quality** — relevant for most plans; skip only for documentation-only\n  or configuration-only changes\n- **Test Coverage** — relevant for most plans; skip only for documentation-only,\n  configuration-only, or infrastructure-only changes with no code\n- **Security** — relevant when the plan involves: authentication\u002Fauthorisation,\n  user input handling, data storage, external integrations, API endpoints,\n  secrets\u002Fcredentials, network boundaries\n- **Standards** — relevant when the plan involves: API changes, UI changes,\n  new file\u002Fmodule creation, changes to public interfaces\n- **Usability** — relevant when the plan involves: public APIs, CLI interfaces,\n  configuration surfaces, breaking changes, migration paths, developer-facing\n  libraries\n- **Performance** — relevant when the plan involves: data processing pipelines,\n  high-throughput APIs, concurrent processing resource efficiency, caching\n  strategy, or algorithm-heavy logic. Skip for documentation-only,\n  configuration-only, or trivial changes.\n- **Documentation** — relevant when the plan involves: new public APIs, new\n  user-facing features, configuration changes, breaking changes, or new\n  system components that will need documentation.\n- **Database** — relevant when the plan involves: database schema changes,\n  new tables, migrations, query-heavy features, or changes to data access\n  patterns.\n- **Correctness** — relevant for most plans; skip only for\n  documentation-only or trivial configuration changes.\n- **Compatibility** — relevant when the plan involves: public API changes,\n  dependency updates, protocol changes, cross-platform considerations, or\n  versioning decisions.\n- **Portability** — relevant when the plan involves: infrastructure changes,\n  deployment modifications, new cloud service integrations, or\n  environment-specific logic.\n- **Safety** — relevant when the plan involves: data migration, deletion\n  logic, deployment changes, automated processes, or changes to critical\n  system paths.\n\n**Lens selection cap:** Select the most relevant lenses for the change under\nreview. If review configuration is provided above, use the configured\n`min_lenses` and `max_lenses` values. Otherwise, use the defaults: \n**{min lenses} to {max lenses}** lenses. Apply these prioritisation rules:\n\nApply this lens selection pipeline in order:\n\n1. **Start with all available lenses**: the 13 built-in lenses plus any\n   custom lenses listed in the review configuration above.\n2. **Remove disabled lenses**: if review configuration specifies\n   `disabled_lenses`, remove those from the available set. They are never\n   selected regardless of auto-detect criteria.\n3. **Mark core lenses**: if review configuration specifies `core_lenses`,\n   use that list. Otherwise, the core lenses are Architecture, Code Quality,\n   Test Coverage, and Correctness. Core lenses are included unless the change\n   is clearly outside their scope.\n4. **Auto-detect remaining lenses**: use the criteria below (for built-in\n   lenses) and the auto-detect criteria from review configuration (for custom\n   lenses) to identify which non-core lenses are relevant to the change.\n   Custom lenses that provide auto-detect criteria participate in selection\n   like any other non-core lens. Custom lenses without auto-detect criteria\n   (marked \"always include\" in the configuration) are always selected. Custom\n   lenses use absolute paths instead of the `${CLAUDE_PLUGIN_ROOT}` lens\n   path template.\n5. **Apply focus arguments**: if the user provided focus areas, prioritise\n   the corresponding lenses and fill remaining slots with auto-detected ones.\n6. **Cap at `max_lenses`**: if more lenses than the configured maximum pass\n   selection, rank by relevance and drop the least relevant. Prefer lenses\n   whose core responsibilities directly overlap with the change's concerns.\n7. **Enforce `min_lenses` floor**: never run fewer than `min_lenses` unless\n   the change is trivially scoped.\n\nWhen presenting the lens selection, clearly indicate which lenses are\nselected and which are skipped, with a brief reason for each skip.\n\nPresent your lens selection to the user before proceeding:\n\n```\nBased on the plan's scope, I'll review through these lenses:\n- Architecture: [reason]\n- Security: [reason — or \"Skipping: no security-sensitive changes identified\"]\n- Test Coverage: [reason]\n- Code Quality: [reason]\n- Standards: [reason — or \"Skipping: ...\"]\n- Usability: [reason — or \"Skipping: ...\"]\n- Performance: [reason — or \"Skipping: no performance-sensitive changes identified\"]\n- Documentation: [reason — or \"Skipping: ...\"]\n- Database: [reason — or \"Skipping: no database changes identified\"]\n- Correctness: [reason]\n- Compatibility: [reason — or \"Skipping: ...\"]\n- Portability: [reason — or \"Skipping: ...\"]\n- Safety: [reason — or \"Skipping: ...\"]\n```\n\nThen use the `AskUserQuestion` tool to ask the user whether to proceed, with\ntwo 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\nWait for the user's answer before spawning reviewers. If they choose option 2,\nask which lenses they want as 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). Once confirmed, update the selection and re-present it using\nthe same `AskUserQuestion` proceed\u002Fadjust pattern above.\n\n### Step 3: Spawn Review Agents\n\nFor each selected lens, spawn the {reviewer agent} agent with a prompt\nthat includes paths to the lens skill and output format files. Do NOT read\nthese files yourself — the agent reads them in its own context.\n\nCompose each agent's prompt following this template:\n\n```\nYou are reviewing an implementation plan through the [lens name] lens.\n\n## Context\n\nThe implementation plan is at [path]. Read it fully.\nAlso read any files the plan references for additional context.\n\n## Analysis Strategy\n\n1. Read your lens skill and output format files (see paths below)\n2. Read the implementation plan file fully\n3. Identify the scope and complexity of the proposed changes\n4. Explore the codebase to understand existing patterns and context\n5. Evaluate the plan through your lens, applying each key question\n6. Reference specific plan sections in your findings using the `location`\n   field (e.g., \"Phase 2: API Endpoints\", \"Testing Strategy section\")\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: ${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Freview\u002Foutput-formats\u002Fplan-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   the agent's lens name and `\"major\"` severity, and include it in the\n   review summary\n\nWhen falling back, warn the user that the agent's output could not be parsed\nand present the raw agent output in a collapsed form so the user can see what\nthe agent actually found.\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 overlapping plan\n   sections with similar concerns, consider merging — but only when the\n   findings address the same underlying concern from different lens\n   perspectives. Location proximity alone is not sufficient; the findings must\n   be semantically related.\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   - Note all contributing lenses in the title\n\n   When in doubt, keep findings separate — distinct findings are easier to\n   address individually than a merged finding covering multiple concerns.\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 `plan_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 plan revise severity ({plan revise severity})\n     exist → suggest `REVISE`\n   - If {plan 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` — plan is sound and ready for implementation\n   - `REVISE` — plan needs changes before implementation\n   - `COMMENT` — observations only, plan is acceptable as-is\n\n   When presenting a `COMMENT` verdict with major findings, note: \"Plan 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. Also identify tradeoffs where\n   different lenses conflict (e.g., security wants more validation, usability\n   wants less friction).\n\n7. **Compose the review summary**:\n\n   ```markdown\n   ## Plan Review: [Plan Name]\n\n   **Verdict:** [APPROVE | REVISE | COMMENT]\n\n   [Combined assessment: take each agent's summary and synthesise into 2-3\n   sentences covering the overall quality of the plan 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   ### Tradeoff Analysis\n   [Where different lenses disagree, present both perspectives]\n   - **[Quality A] vs [Quality B]**: [description and recommendation]\n\n   [Omit either section if there are no cross-cutting themes or tradeoffs]\n\n   ### Findings\n\n   #### Critical\n   - ? **[Lens]**: [title]\n     **Location**: [plan section]\n     [First 1-2 sentences of body as summary]\n\n   #### Major\n   - ? **[Lens]**: [title]\n     **Location**: [plan section]\n     [First 1-2 sentences of body as summary]\n\n   #### Minor\n   - ? **[Lens]**: [title]\n     **Location**: [plan section]\n     [First 1-2 sentences of body as summary]\n\n   #### Suggestions\n   - ? **[Lens]**: [title]\n     **Location**: [plan 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 plan, 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 plan]\n\n   ---\n   *Review generated by \u002Freview-plan*\n   ```\n\n8. **Write the review artifact** to `{plan reviews directory}\u002F`:\n\n   Derive the review filename using the plan stem and the next available\n   review number. The plan stem is the basename of the plan path without\n   the `.md` extension. For example, if the plan is\n   `{plans directory}\u002F2026-03-22-improve-error-handling.md` and no prior reviews\n   exist, the review filename is\n   `{plan reviews directory}\u002F2026-03-22-improve-error-handling-review-1.md`.\n\n   To determine the next review number:\n   ```bash\n   mkdir -p {plan reviews directory}\n   # Glob for existing reviews of this plan\n   ls {plan reviews directory}\u002F{plan-stem}-review-*.md 2>\u002Fdev\u002Fnull\n   # Extract the highest number, increment by 1. If none exist, use 1.\n   ```\n\n#### Populate frontmatter\n\nThe `target:` field is filled automatically from the `$ARGUMENTS` plan\nreference — this is what makes the review traceable back to the plan it\ncovers. Per ADR-0034, the typed-linkage form is `\"plan:\u003Cplan-id>\"`.\n\nBefore writing the plan review file, capture metadata and substitute the\nunified base fields and per-type extras into the template's frontmatter\nblock:\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:` ← `plan-review`\n   - `id:` ← the review filename stem (without `.md`), always quoted\n     as a YAML string\n   - `title:` ← `Plan Review: {plan 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-plan`\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 plan (`\"plan:NNNN\"`).\n     Fill when the review names a parent plan; otherwise omit the key.\n   - `target:` ← `\"plan:\u003Cplan-id>\"` where `\u003Cplan-id>` is the plan\n     filename stem (e.g. `\"plan:2026-05-30-0065-update-artifact-templates-to-unified-schema\"`);\n     the typed-linkage ref to the plan under review, per ADR-0034.\n     Always fill — every review has a target.\n   - `relates_to:` ← list of typed-linkage refs to related reviews or\n     artifacts (`[\"plan-review:NNNN\", ...]`). Fill when prior reviews\n     are explicit; otherwise omit the key.\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 lens names used (from Step 2)\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 per-lens results section contains the full content from each agent's\nJSON output, converted to readable markdown. This preserves the complete\nanalysis for future reference while keeping it human-readable.\n\n**Validate the frontmatter**: after writing the review, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the review 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\nWould you like to:\n1. Proceed to address findings? (I'll help edit the plan)\n2. Change the verdict? (currently: [verdict])\n3. Discuss any specific findings in more detail?\n4. Re-run specific lenses with adjusted focus?\n```\n\n### Step 6: Collaborative Plan Iteration\n\nAfter presenting the review:\n\n1. **Discuss findings with the user**:\n  - Ask which recommendations they want to address\n  - Discuss any tradeoffs where they need to make a judgment call\n  - Clarify any findings that need more context\n\n2. **Edit the plan based on agreed changes**:\n  - Use the Edit tool to modify the plan file directly\n  - Make changes incrementally — one finding at a time or in logical groups\n  - Preserve the plan's existing structure and conventions\n  - Don't rewrite sections unnecessarily — make targeted edits\n\n3. **Summarise changes made**:\n   ```\n   I've made the following changes to the plan:\n   - [Change 1] — addressing [finding]\n   - [Change 2] — addressing [finding]\n   - [Skipped] — [finding you discussed and decided not to address, with reason]\n   ```\n\n### Step 7: Offer Re-Review\n\nAfter edits are complete:\n\n```\nThe plan has been updated. Would you like me to run another review pass to\nverify the changes address the findings? This will re-run the relevant lenses\nto check for any remaining issues or new concerns introduced by the edits.\n```\n\nIf the user accepts:\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 (by `title` + `lens`) to\n  determine resolution status\n- Focus the review on whether findings were addressed and whether edits\n  introduced new issues\n- Present a shorter, delta-focused review:\n  ```\n  ## Re-Review: [Plan Name]\n\n  **Verdict:** [APPROVE | REVISE | COMMENT]\n\n  ### Previously Identified Issues\n  - [emoji] **[Lens]**: [title] — Resolved \u002F Partially resolved \u002F Still present\n  - ...\n\n  ### New Issues Introduced\n  - [emoji] **[Lens]**: [title] — [brief description]\n\n  ### Assessment\n  [Whether the plan is now in good shape 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   `{plan reviews directory}\u002F{plan-stem}-review-{N}.md`\n2. 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\n   retains the original-review timestamp; only `last_updated`\n   advances on re-review. (`last_updated_by` may match `reviewer` if\n   the re-reviewer is the same person, but is computed independently\n   to handle the cross-reviewer case.)\n\n   **Pre-0066-artifact handling**: when the re-reviewed artifact\n   lacks `last_updated:` and\u002For `last_updated_by:` (it was written\n   pre-0066), insert those fields rather than treating their absence\n   as malformed-frontmatter. Only an unparseable YAML block or\n   missing `---` delimiters triggers the fresh-`-review-{N+1}.md`\n   fallback.\n3. Append the re-review section at the end of the content (after the\n   Per-Lens Results section)\n4. Write the complete modified content back to the same file in one\n   operation\n\nThe frontmatter's `verdict` and `review_pass` fields reflect the\nlatest re-review state (not the initial review state), so readers can\ncheck the current status without scrolling:\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\n   ### New Issues Introduced\n   - {emoji} **{Lens}**: {title} — {brief description}\n\n   ### Assessment\n   {Whether the plan is now in good shape or needs further iteration}\n   ```\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\nIf the user declines or the re-review shows all clear, the review is complete.\n\n## Important Guidelines\n\n1. **Read the plan fully** before doing anything else — you need complete\n   context to select lenses and brief the agents properly\n\n2. **Spawn agents in parallel** — the review lenses are independent and should\n   run concurrently for efficiency\n\n3. **Synthesise, don't concatenate** — your value is in compiling a balanced\n   view across lenses, identifying themes and tradeoffs, and prioritising\n   actionable recommendations. Don't just paste seven reports together.\n\n4. **Be balanced** — highlight strengths alongside concerns. A plan that makes\n   good architectural decisions but has security gaps should get credit for\n   both.\n\n5. **Prioritise by impact** — structural issues that are hard to fix later\n   matter more than surface-level concerns. A critical finding from one lens\n   outweighs minor findings from all seven.\n\n6. **Respect tradeoffs** — when lenses conflict, present both sides and let the\n   user decide. Don't privilege one quality attribute over another without\n   justification.\n\n7. **Edit conservatively** — when modifying the plan, make the minimum changes\n   needed to address findings. Don't restructure or rewrite beyond what's\n   required.\n\n8. **Track what was addressed** — when presenting changes, clearly map them\n   back to findings so nothing falls through the cracks.\n\n9. **Handle malformed agent output gracefully** — if an agent doesn't return\n   valid JSON, extract what you can and present the raw output to the user\n   rather than silently dropping findings\n\n10. **Keep positive feedback in the summary** — strengths go in the review\n    summary, not as individual findings. Findings are exclusively for\n    actionable concerns.\n\n11. **Use emoji severity prefixes consistently** — ? critical, ? major,\n    ? minor\u002Fsuggestion, ✅ strengths. **IMPORTANT**: Use the actual Unicode\n    emoji characters (? ? ? ✅), NOT text shortcodes like `:red_circle:`,\n    `:yellow_circle:`, `:blue_circle:`, or `:white_check_mark:`. Shortcodes\n    are not rendered in markdown and will appear as literal text.\n\n## What NOT to Do\n\n- Don't skip writing the review artifact — always persist to\n  {plan reviews directory}\u002F so the review is visible to the team\n- Don't skip the lens selection step — always confirm with the user which\n  lenses will run\n- Don't present raw agent output — always aggregate and curate into the\n  structured format\n- Don't make plan edits without user agreement\n- Don't force all findings to be addressed — some may be intentionally\n  accepted tradeoffs\n- Don't run lenses that clearly aren't relevant — a documentation plan doesn't\n  need a security review\n- Don't post findings as individual items for positive feedback — strengths go\n  in the summary only\n- Don't skip the verdict — always include a suggested verdict based on finding\n  severity\n\n## Relationship to Other Commands\n\nThe review sits in the plan lifecycle between creation and implementation:\n\n1. `\u002Fcreate-plan` — Create the implementation plan interactively\n2. `\u002Freview-plan` — Review and iterate the plan quality (this command)\n3. `\u002Fimplement-plan` — Execute the approved plan\n4. `\u002Fvalidate-plan` — Verify implementation matches the plan\n\n!`accelerator config instructions review-plan --fail-safe`\n","# Review Plan\n\n!`accelerator config context --skill review-plan --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 plan --fail-safe`\n\n**Plans directory**: !`accelerator config path plans --fail-safe`\n**Plan reviews directory**: !`accelerator config path review_plans --fail-safe`\n\n## Plan Review Template\n\nThe template below defines the frontmatter and body structure that every\nplan 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 plan-review --fail-safe`\n\nYou are tasked with reviewing an implementation plan through multiple quality\nlenses and then collaboratively iterating the plan based on findings.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if a plan path was provided**:\n\n- If a plan path was provided, read it immediately and FULLY\n- If optional focus arguments were provided (e.g., \"security and architecture\"),\n  note them for lens selection\n- Begin the review process\n\n2. **If no plan path provided**, respond with:\n\n```\nI'll help you review an implementation plan. Please provide:\n1. The path to the plan file (e.g., `{plans directory}\u002F2025-01-08-ENG-1478-feature.md`)\n2. (Optional) Focus areas to emphasise (e.g., \"focus on security and architecture\")\n\nTip: You can invoke this command with arguments:\n  `\u002Freview-plan {plans directory}\u002F2025-01-08-feature.md`\n  `\u002Freview-plan {plans directory}\u002F2025-01-08-feature.md focus on security and architecture`\n```\n\nThen wait for the user's input.\n\n## Available Review Lenses\n\n| Lens               | Lens Skill                    | Focus                                                                 |\n|--------------------|-------------------------------|-----------------------------------------------------------------------|\n| **Architecture**   | `architecture-lens`           | Modularity, coupling, scalability, evolutionary design, tradeoffs     |\n| **Security**       | `security-lens`               | Threats, missing protections, STRIDE analysis, OWASP coverage         |\n| **Test Coverage**  | `test-coverage-lens`          | Testing strategy, test pyramid, edge cases, isolation, risk coverage  |\n| **Code Quality**   | `code-quality-lens`           | Design principles, testability, error handling, complexity management |\n| **Standards**      | `standards-lens`              | Project conventions, API standards, accessibility                     |\n| **Usability**      | `usability-lens`              | Developer experience, API ergonomics, configuration, onboarding       |\n| **Performance**    | `performance-lens`            | Algorithmic efficiency, resource usage, concurrency, caching          |\n| **Documentation**  | `documentation-lens`          | Documentation completeness, accuracy, audience fit                    |\n| **Database**       | `database-lens`               | Migration safety, schema design, query correctness, integrity         |\n| **Correctness**    | `correctness-lens`            | Logical validity, boundary conditions, state management, concurrency  |\n| **Compatibility**  | `compatibility-lens`          | API contracts, cross-platform, protocol compliance, deps              |\n| **Portability**    | `portability-lens`            | Environment independence, deployment flexibility, vendor lock         |\n| **Safety**         | `safety-lens`                 | Data loss prevention, operational safety, protective mechanisms       |\n\n## Process Steps\n\n### Step 1: Read and Understand the Plan\n\n1. **Read the plan file FULLY** — never use limit\u002Foffset\n2. **Read any files the plan references** — work items, related research, key\n   source files mentioned\n3. **Understand the plan's scope**:\n  - What technologies and layers does it touch?\n  - Does it involve APIs, UI, infrastructure, data models?\n  - What's the complexity and risk profile?\n  - Who are the consumers — other developers, services, end users?\n\n4. **Check for existing reviews**: Glob for review documents matching\n   `{plan reviews directory}\u002F{plan-stem}-review-*.md`. If any are found:\n   - Read the most recent review document (highest review number) to\n     understand what was previously reviewed\n   - Note the previous verdict, review pass count, and key findings\n   - Inform the user: \"I found {N} previous review(s) of this plan. 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 plan\n     fresh. But the aggregation step (Step 4) should reference the previous\n     review when composing cross-cutting themes and the assessment:\n     specifically, note which findings from the previous review recur in\n     the new review and which appear to have been addressed by plan changes.\n   - If the prior review file exists but cannot be parsed (e.g., malformed\n     frontmatter from a partial write), warn the user and proceed as if no\n     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 or deleted —\n   the full review history is preserved on disk.\n\n### Step 2: Select Review Lenses\n\nDetermine which lenses are relevant based on the plan's scope and any user-\nprovided focus arguments.\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 to the plan's scope\n- Briefly explain which lenses you're running and why\n\n**If no focus arguments were provided, auto-detect relevance:**\n\nTake time to think carefully about which lenses apply based on:\n\n- **Architecture** — relevant for most plans; skip only for trivial, single-file\n  changes\n- **Code Quality** — relevant for most plans; skip only for documentation-only\n  or configuration-only changes\n- **Test Coverage** — relevant for most plans; skip only for documentation-only,\n  configuration-only, or infrastructure-only changes with no code\n- **Security** — relevant when the plan involves: authentication\u002Fauthorisation,\n  user input handling, data storage, external integrations, API endpoints,\n  secrets\u002Fcredentials, network boundaries\n- **Standards** — relevant when the plan involves: API changes, UI changes,\n  new file\u002Fmodule creation, changes to public interfaces\n- **Usability** — relevant when the plan involves: public APIs, CLI interfaces,\n  configuration surfaces, breaking changes, migration paths, developer-facing\n  libraries\n- **Performance** — relevant when the plan involves: data processing pipelines,\n  high-throughput APIs, concurrent processing resource efficiency, caching\n  strategy, or algorithm-heavy logic. Skip for documentation-only,\n  configuration-only, or trivial changes.\n- **Documentation** — relevant when the plan involves: new public APIs, new\n  user-facing features, configuration changes, breaking changes, or new\n  system components that will need documentation.\n- **Database** — relevant when the plan involves: database schema changes,\n  new tables, migrations, query-heavy features, or changes to data access\n  patterns.\n- **Correctness** — relevant for most plans; skip only for\n  documentation-only or trivial configuration changes.\n- **Compatibility** — relevant when the plan involves: public API changes,\n  dependency updates, protocol changes, cross-platform considerations, or\n  versioning decisions.\n- **Portability** — relevant when the plan involves: infrastructure changes,\n  deployment modifications, new cloud service integrations, or\n  environment-specific logic.\n- **Safety** — relevant when the plan involves: data migration, deletion\n  logic, deployment changes, automated processes, or changes to critical\n  system paths.\n\n**Lens selection cap:** Select the most relevant lenses for the change under\nreview. If review configuration is provided above, use the configured\n`min_lenses` and `max_lenses` values. Otherwise, use the defaults: \n**{min lenses} to {max lenses}** lenses. Apply these prioritisation rules:\n\nApply this lens selection pipeline in order:\n\n1. **Start with all available lenses**: the 13 built-in lenses plus any\n   custom lenses listed in the review configuration above.\n2. **Remove disabled lenses**: if review configuration specifies\n   `disabled_lenses`, remove those from the available set. They are never\n   selected regardless of auto-detect criteria.\n3. **Mark core lenses**: if review configuration specifies `core_lenses`,\n   use that list. Otherwise, the core lenses are Architecture, Code Quality,\n   Test Coverage, and Correctness. Core lenses are included unless the change\n   is clearly outside their scope.\n4. **Auto-detect remaining lenses**: use the criteria below (for built-in\n   lenses) and the auto-detect criteria from review configuration (for custom\n   lenses) to identify which non-core lenses are relevant to the change.\n   Custom lenses that provide auto-detect criteria participate in selection\n   like any other non-core lens. Custom lenses without auto-detect criteria\n   (marked \"always include\" in the configuration) are always selected. Custom\n   lenses use absolute paths instead of the `${CLAUDE_PLUGIN_ROOT}` lens\n   path template.\n5. **Apply focus arguments**: if the user provided focus areas, prioritise\n   the corresponding lenses and fill remaining slots with auto-detected ones.\n6. **Cap at `max_lenses`**: if more lenses than the configured maximum pass\n   selection, rank by relevance and drop the least relevant. Prefer lenses\n   whose core responsibilities directly overlap with the change's concerns.\n7. **Enforce `min_lenses` floor**: never run fewer than `min_lenses` unless\n   the change is trivially scoped.\n\nWhen presenting the lens selection, clearly indicate which lenses are\nselected and which are skipped, with a brief reason for each skip.\n\nPresent your lens selection to the user before proceeding:\n\n```\nBased on the plan's scope, I'll review through these lenses:\n- Architecture: [reason]\n- Security: [reason — or \"Skipping: no security-sensitive changes identified\"]\n- Test Coverage: [reason]\n- Code Quality: [reason]\n- Standards: [reason — or \"Skipping: ...\"]\n- Usability: [reason — or \"Skipping: ...\"]\n- Performance: [reason — or \"Skipping: no performance-sensitive changes identified\"]\n- Documentation: [reason — or \"Skipping: ...\"]\n- Database: [reason — or \"Skipping: no database changes identified\"]\n- Correctness: [reason]\n- Compatibility: [reason — or \"Skipping: ...\"]\n- Portability: [reason — or \"Skipping: ...\"]\n- Safety: [reason — or \"Skipping: ...\"]\n```\n\nThen use the `AskUserQuestion` tool to ask the user whether to proceed, with\ntwo 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\nWait for the user's answer before spawning reviewers. If they choose option 2,\nask which lenses they want as 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). Once confirmed, update the selection and re-present it using\nthe same `AskUserQuestion` proceed\u002Fadjust pattern above.\n\n### Step 3: Spawn Review Agents\n\nFor each selected lens, spawn the {reviewer agent} agent with a prompt\nthat includes paths to the lens skill and output format files. Do NOT read\nthese files yourself — the agent reads them in its own context.\n\nCompose each agent's prompt following this template:\n\n```\nYou are reviewing an implementation plan through the [lens name] lens.\n\n## Context\n\nThe implementation plan is at [path]. Read it fully.\nAlso read any files the plan references for additional context.\n\n## Analysis Strategy\n\n1. Read your lens skill and output format files (see paths below)\n2. Read the implementation plan file fully\n3. Identify the scope and complexity of the proposed changes\n4. Explore the codebase to understand existing patterns and context\n5. Evaluate the plan through your lens, applying each key question\n6. Reference specific plan sections in your findings using the `location`\n   field (e.g., \"Phase 2: API Endpoints\", \"Testing Strategy section\")\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: ${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Freview\u002Foutput-formats\u002Fplan-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   the agent's lens name and `\"major\"` severity, and include it in the\n   review summary\n\nWhen falling back, warn the user that the agent's output could not be parsed\nand present the raw agent output in a collapsed form so the user can see what\nthe agent actually found.\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 overlapping plan\n   sections with similar concerns, consider merging — but only when the\n   findings address the same underlying concern from different lens\n   perspectives. Location proximity alone is not sufficient; the findings must\n   be semantically related.\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   - Note all contributing lenses in the title\n\n   When in doubt, keep findings separate — distinct findings are easier to\n   address individually than a merged finding covering multiple concerns.\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 `plan_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 plan revise severity ({plan revise severity})\n     exist → suggest `REVISE`\n   - If {plan 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` — plan is sound and ready for implementation\n   - `REVISE` — plan needs changes before implementation\n   - `COMMENT` — observations only, plan is acceptable as-is\n\n   When presenting a `COMMENT` verdict with major findings, note: \"Plan 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. Also identify tradeoffs where\n   different lenses conflict (e.g., security wants more validation, usability\n   wants less friction).\n\n7. **Compose the review summary**:\n\n   ```markdown\n   ## Plan Review: [Plan Name]\n\n   **Verdict:** [APPROVE | REVISE | COMMENT]\n\n   [Combined assessment: take each agent's summary and synthesise into 2-3\n   sentences covering the overall quality of the plan 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   ### Tradeoff Analysis\n   [Where different lenses disagree, present both perspectives]\n   - **[Quality A] vs [Quality B]**: [description and recommendation]\n\n   [Omit either section if there are no cross-cutting themes or tradeoffs]\n\n   ### Findings\n\n   #### Critical\n   - ? **[Lens]**: [title]\n     **Location**: [plan section]\n     [First 1-2 sentences of body as summary]\n\n   #### Major\n   - ? **[Lens]**: [title]\n     **Location**: [plan section]\n     [First 1-2 sentences of body as summary]\n\n   #### Minor\n   - ? **[Lens]**: [title]\n     **Location**: [plan section]\n     [First 1-2 sentences of body as summary]\n\n   #### Suggestions\n   - ? **[Lens]**: [title]\n     **Location**: [plan 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 plan, 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 plan]\n\n   ---\n   *Review generated by \u002Freview-plan*\n   ```\n\n8. **Write the review artifact** to `{plan reviews directory}\u002F`:\n\n   Derive the review filename using the plan stem and the next available\n   review number. The plan stem is the basename of the plan path without\n   the `.md` extension. For example, if the plan is\n   `{plans directory}\u002F2026-03-22-improve-error-handling.md` and no prior reviews\n   exist, the review filename is\n   `{plan reviews directory}\u002F2026-03-22-improve-error-handling-review-1.md`.\n\n   To determine the next review number:\n   ```bash\n   mkdir -p {plan reviews directory}\n   # Glob for existing reviews of this plan\n   ls {plan reviews directory}\u002F{plan-stem}-review-*.md 2>\u002Fdev\u002Fnull\n   # Extract the highest number, increment by 1. If none exist, use 1.\n   ```\n\n#### Populate frontmatter\n\nThe `target:` field is filled automatically from the `$ARGUMENTS` plan\nreference — this is what makes the review traceable back to the plan it\ncovers. Per ADR-0034, the typed-linkage form is `\"plan:\u003Cplan-id>\"`.\n\nBefore writing the plan review file, capture metadata and substitute the\nunified base fields and per-type extras into the template's frontmatter\nblock:\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:` ← `plan-review`\n   - `id:` ← the review filename stem (without `.md`), always quoted\n     as a YAML string\n   - `title:` ← `Plan Review: {plan 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-plan`\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 plan (`\"plan:NNNN\"`).\n     Fill when the review names a parent plan; otherwise omit the key.\n   - `target:` ← `\"plan:\u003Cplan-id>\"` where `\u003Cplan-id>` is the plan\n     filename stem (e.g. `\"plan:2026-05-30-0065-update-artifact-templates-to-unified-schema\"`);\n     the typed-linkage ref to the plan under review, per ADR-0034.\n     Always fill — every review has a target.\n   - `relates_to:` ← list of typed-linkage refs to related reviews or\n     artifacts (`[\"plan-review:NNNN\", ...]`). Fill when prior reviews\n     are explicit; otherwise omit the key.\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 lens names used (from Step 2)\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 per-lens results section contains the full content from each agent's\nJSON output, converted to readable markdown. This preserves the complete\nanalysis for future reference while keeping it human-readable.\n\n**Validate the frontmatter**: after writing the review, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the review 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\nWould you like to:\n1. Proceed to address findings? (I'll help edit the plan)\n2. Change the verdict? (currently: [verdict])\n3. Discuss any specific findings in more detail?\n4. Re-run specific lenses with adjusted focus?\n```\n\n### Step 6: Collaborative Plan Iteration\n\nAfter presenting the review:\n\n1. **Discuss findings with the user**:\n  - Ask which recommendations they want to address\n  - Discuss any tradeoffs where they need to make a judgment call\n  - Clarify any findings that need more context\n\n2. **Edit the plan based on agreed changes**:\n  - Use the Edit tool to modify the plan file directly\n  - Make changes incrementally — one finding at a time or in logical groups\n  - Preserve the plan's existing structure and conventions\n  - Don't rewrite sections unnecessarily — make targeted edits\n\n3. **Summarise changes made**:\n   ```\n   I've made the following changes to the plan:\n   - [Change 1] — addressing [finding]\n   - [Change 2] — addressing [finding]\n   - [Skipped] — [finding you discussed and decided not to address, with reason]\n   ```\n\n### Step 7: Offer Re-Review\n\nAfter edits are complete:\n\n```\nThe plan has been updated. Would you like me to run another review pass to\nverify the changes address the findings? This will re-run the relevant lenses\nto check for any remaining issues or new concerns introduced by the edits.\n```\n\nIf the user accepts:\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 (by `title` + `lens`) to\n  determine resolution status\n- Focus the review on whether findings were addressed and whether edits\n  introduced new issues\n- Present a shorter, delta-focused review:\n  ```\n  ## Re-Review: [Plan Name]\n\n  **Verdict:** [APPROVE | REVISE | COMMENT]\n\n  ### Previously Identified Issues\n  - [emoji] **[Lens]**: [title] — Resolved \u002F Partially resolved \u002F Still present\n  - ...\n\n  ### New Issues Introduced\n  - [emoji] **[Lens]**: [title] — [brief description]\n\n  ### Assessment\n  [Whether the plan is now in good shape 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   `{plan reviews directory}\u002F{plan-stem}-review-{N}.md`\n2. 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\n   retains the original-review timestamp; only `last_updated`\n   advances on re-review. (`last_updated_by` may match `reviewer` if\n   the re-reviewer is the same person, but is computed independently\n   to handle the cross-reviewer case.)\n\n   **Pre-0066-artifact handling**: when the re-reviewed artifact\n   lacks `last_updated:` and\u002For `last_updated_by:` (it was written\n   pre-0066), insert those fields rather than treating their absence\n   as malformed-frontmatter. Only an unparseable YAML block or\n   missing `---` delimiters triggers the fresh-`-review-{N+1}.md`\n   fallback.\n3. Append the re-review section at the end of the content (after the\n   Per-Lens Results section)\n4. Write the complete modified content back to the same file in one\n   operation\n\nThe frontmatter's `verdict` and `review_pass` fields reflect the\nlatest re-review state (not the initial review state), so readers can\ncheck the current status without scrolling:\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\n   ### New Issues Introduced\n   - {emoji} **{Lens}**: {title} — {brief description}\n\n   ### Assessment\n   {Whether the plan is now in good shape or needs further iteration}\n   ```\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\nIf the user declines or the re-review shows all clear, the review is complete.\n\n## Important Guidelines\n\n1. **Read the plan fully** before doing anything else — you need complete\n   context to select lenses and brief the agents properly\n\n2. **Spawn agents in parallel** — the review lenses are independent and should\n   run concurrently for efficiency\n\n3. **Synthesise, don't concatenate** — your value is in compiling a balanced\n   view across lenses, identifying themes and tradeoffs, and prioritising\n   actionable recommendations. Don't just paste seven reports together.\n\n4. **Be balanced** — highlight strengths alongside concerns. A plan that makes\n   good architectural decisions but has security gaps should get credit for\n   both.\n\n5. **Prioritise by impact** — structural issues that are hard to fix later\n   matter more than surface-level concerns. A critical finding from one lens\n   outweighs minor findings from all seven.\n\n6. **Respect tradeoffs** — when lenses conflict, present both sides and let the\n   user decide. Don't privilege one quality attribute over another without\n   justification.\n\n7. **Edit conservatively** — when modifying the plan, make the minimum changes\n   needed to address findings. Don't restructure or rewrite beyond what's\n   required.\n\n8. **Track what was addressed** — when presenting changes, clearly map them\n   back to findings so nothing falls through the cracks.\n\n9. **Handle malformed agent output gracefully** — if an agent doesn't return\n   valid JSON, extract what you can and present the raw output to the user\n   rather than silently dropping findings\n\n10. **Keep positive feedback in the summary** — strengths go in the review\n    summary, not as individual findings. Findings are exclusively for\n    actionable concerns.\n\n11. **Use emoji severity prefixes consistently** — ? critical, ? major,\n    ? minor\u002Fsuggestion, ✅ strengths. **IMPORTANT**: Use the actual Unicode\n    emoji characters (? ? ? ✅), NOT text shortcodes like `:red_circle:`,\n    `:yellow_circle:`, `:blue_circle:`, or `:white_check_mark:`. Shortcodes\n    are not rendered in markdown and will appear as literal text.\n\n## What NOT to Do\n\n- Don't skip writing the review artifact — always persist to\n  {plan reviews directory}\u002F so the review is visible to the team\n- Don't skip the lens selection step — always confirm with the user which\n  lenses will run\n- Don't present raw agent output — always aggregate and curate into the\n  structured format\n- Don't make plan edits without user agreement\n- Don't force all findings to be addressed — some may be intentionally\n  accepted tradeoffs\n- Don't run lenses that clearly aren't relevant — a documentation plan doesn't\n  need a security review\n- Don't post findings as individual items for positive feedback — strengths go\n  in the summary only\n- Don't skip the verdict — always include a suggested verdict based on finding\n  severity\n\n## Relationship to Other Commands\n\nThe review sits in the plan lifecycle between creation and implementation:\n\n1. `\u002Fcreate-plan` — Create the implementation plan interactively\n2. `\u002Freview-plan` — Review and iterate the plan quality (this command)\n3. `\u002Fimplement-plan` — Execute the approved plan\n4. `\u002Fvalidate-plan` — Verify implementation matches the plan\n\n!`accelerator config instructions review-plan --fail-safe`\n",{"name":5,"description":7,"allowed-tools":43,"argument-hint":47},[44,45,46],"Bash(accelerator config *)","Bash(accelerator corpus metadata derive)","Bash(accelerator corpus frontmatter validate *)","[path to plan file]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fplanning\u002Freview-plan",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":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add atomicinnovation\u002Faccelerator --skill review-plan",{"tool":62,"command":63},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill review-plan",{"tool":65,"command":66},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill review-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fplanning\u002Freview-plan\u002FSKILL.md",true,[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"index.json","REFERENCE","参考文档",690,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fnetwork\u002Fprotocol\u002Ficmp\u002Fcovert-channel\u002Fdetect\u002Findex.json",[77,111,132,154,172,195],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":93,"publishedAt":38},"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",[83,88],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[94,95,96,97,98,99,100,101,102,103,23,104,105,33,106,107,108,21,109,110],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","number","URL","code","architecture","reviewer","notes","change",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":38},"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",[],[118,119,120,121,122,123,31,33,110,36,124,37,125,126,28,127,128,129,130,131],"work","update","update work item","work item","enforcement","manage","edit","status","transition","Existing","tags","changes","fields","op",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":38},"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",[],[118,139,140,141,142,143,144,33,145,110,146,147,148,149,150,151,152,36,153,28,23],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":38},"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",[],[161,118,162,139,140,163,164,165,166,167,168,169,170,171],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":181,"publishedAt":38},"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",[178],{"categoryNo":179,"categoryName":180,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量",[182,183,118,184,121,185,186,187,188,189,190,33,191,192,36,37,30,193,22,104,194,28],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","grilling","gaps",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":38},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item","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.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[21,118,202,121,203,204,31,33,34,32,36,37,30,22,35,23,25,26,28,29],"review work item","review work","escalation"]