[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7550WDHS9JRWXSW1MP824D9":3,"skill-same:01M7550WDHS9JRWXSW1MP824D9":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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":55},"01M7550WDHS9JRWXSW1MP824D9","x-review-codebase",null,"Parallel code review with specialist engineers (Security, QA, Performance, Database, Observability, DevOps, API, Event). Invokes individual review skills in parallel via Skill tool, then consolidates into a scored report. Use for pre-PR quality validation.","review-bench\u002Federcnj_ia-dev-environment","review-bench","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F286778065?v=4","01M7517F9NTEPDZDAXJBR30FWT","ReviewBench","01M7517FAC9F4P7TGWCNJ8VYVW",0,"MIT","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: x-review-codebase\nmodel: sonnet\ndescription: \"Parallel code review with specialist engineers (Security, QA, Performance, Database, Observability, DevOps, API, Event). Invokes individual review skills in parallel via Skill tool, then consolidates into a scored report. Use for pre-PR quality validation.\"\nuser-invocable: true\nallowed-tools: Read, Write, Edit, Bash, Grep, Glob, Skill, TaskCreate, TaskUpdate\nargument-hint: \"[STORY-ID or --scope reviewer1,reviewer2] [--no-auto-fix-story]\"\ncontext-budget: heavy\nrequires-capabilities: []\nfragment-slots: [{ slot: review-specialist, ordering: fragment-order }]\n---\n\n## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n# Skill: Specialist Review (Orchestrator)\n\n## Purpose\n\nPerform parallel specialist code reviews across multiple engineering dimensions by delegating to individual review skills (`\u002Fx-review-qa`, `\u002Fx-review-performance`, `\u002Fx-review-database`, etc.), consolidating findings into a scored dashboard, and optionally generating correction stories for critical findings.\n\n## When to Use\n\n- `\u002Fx-review-codebase` -- review current branch\n- `\u002Fx-review-codebase STORY-ID` -- review specific story\n- `\u002Fx-review-codebase --scope security,qa` -- run only specific reviewers\n\n## Workflow Overview\n\n```\n0. PRE-CHECK   -> Idempotency: skip if reports exist and code unchanged (inline)\n1. DETECT      -> Identify branch, diff, applicable specialists (inline)\n2. REVIEW      -> Invoke N review skills in parallel via Skill tool (SINGLE message)\n3. CONSOLIDATE -> Collect reports, score, dashboard, remediation (inline)\n4. STORY       -> If CRITICAL\u002FMEDIUM findings: ask user, generate correction story (inline)\n```\n\n\u003C!-- phase-no-gate: read-only idempotency pre-check; no artifact produced -->\n## Phase 0 -- Idempotency Pre-Check (Orchestrator -- Inline)\n\nOpen a phase tracker (close with `TaskUpdate(id: phase0TaskId, status: \"completed\")` after Step 5):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 0 - Idempotency\", activeForm: \"Checking review idempotency\")\n\nBefore executing a review, check if reports already exist and are still valid.\n\n1. Extract story ID from argument or branch name (e.g., `story-XXXX-YYYY`)\n2. Derive epic directory: `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002F`\n3. Check if report files exist:\n   ```bash\n   ls ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-*-story-XXXX-YYYY.md 2>\u002Fdev\u002Fnull\n   ```\n4. If reports exist AND the branch has no new commits since last report:\n   ```bash\n   # Compare latest report mtime with latest commit date\n   stat -c %Y ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-security-story-XXXX-YYYY.md 2>\u002Fdev\u002Fnull\n   git log -1 --format=%ct HEAD\n   ```\n   - If `mtime(report) >= commit_date`: log `Reusing existing review reports from {date}` and skip to Phase 3c (dashboard regeneration)\n   - If code changed after reports: proceed with full review\n5. If no reports exist, proceed normally\n\nPersist interactiveMode to execution-state.json (EPIC-0068 — consumed by Stop hook `enforce-continuous-flow.sh`):\n\n    Skill(skill: \"x-internal-update-status\", args: \"--file ai\u002Fepics\u002Fepic-XXXX\u002Fexecution-state.json --type story --id \u003CSTORY-ID> --field interactiveMode --value \u003Cinteractive|non-interactive>\")\n\nValue: `\"interactive\"` when `--interactive` passed or `CLAUDE_LEGACY_INTERACTIVE=1`; otherwise `\"non-interactive\"` (Rule 20 default, EPIC-0061).\n\n    TaskUpdate(id: phase0TaskId, status: \"completed\")\n\n\u003C!-- phase-no-gate: read-only context detection; no artifact produced -->\n## Phase 1 -- Detect Context (Orchestrator -- Inline)\n\nOpen a phase tracker (close with `TaskUpdate(id: phase1TaskId, status: \"completed\")` after Step 4):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 1 - Detect\", activeForm: \"Detecting review context\")\n\n1. Extract story ID from argument or branch name\n2. Get diff against main:\n   ```bash\n   git branch --show-current\n   git diff main --stat\n   git diff main --name-only\n   ```\n3. If no changes, abort: `No changes found relative to main.`\n4. Determine applicable specialists using Specialist Reference Table below.\n\n**Always active:** QA, Performance\n\n**Conditional:** Activated only when their feature gate condition is met.\n\nIf `--scope` provided, filter to listed specialists only.\n\n## Specialist Reference Table\n\n| Specialist | Skill | Max Score | Condition |\n|------------|-------|-----------|-----------|\n| QA | `\u002Fx-review-qa` | \u002F36 | Always |\n| Performance | `\u002Fx-review-performance` | \u002F26 | Always |\n| Database | `\u002Fx-review-database` | \u002F40 | database != none |\n| Observability | `\u002Fx-review-observability` | \u002F18 | observability != none |\n| DevOps | `\u002Fx-review-devops` | \u002F20 | container != none |\n| Data Modeling | `\u002Fx-review-data-modeling` | \u002F20 | database != none AND architecture in [hexagonal, ddd, cqrs] |\n| Security | `\u002Fx-review-security` | \u002F30 | security frameworks configured |\n| API | `\u002Fx-review-api` | \u002F16 | REST interface present |\n| Event | `\u002Fx-review-events` | \u002F28 | event-driven or event interfaces |\n\n> Each individual skill contains its own checklist, knowledge pack references, and scoring logic. The orchestrator does NOT duplicate these -- it delegates entirely.\n\n## Composition Pattern (RULE-007 — EPIC-0064)\n\nFragment-slot composition — only specialists relevant to active capabilities are included.\nSee [`references\u002Fcomposition-architecture.md`](references\u002Fcomposition-architecture.md) for the canonical fragment table and contribution guide.\n\n{{ #each fragments.review-specialist }}\n\n## Phase 2 -- Parallel Reviews (Skills via Skill Tool)\n\n**CONTEXT ISOLATION: You receive only metadata. Read all files yourself.\nDo NOT expect source code, diffs, or knowledge pack content in this prompt.\nEach review skill reads its own knowledge pack and runs `git diff` independently.**\n\n**CRITICAL: ALL review skills MUST be invoked in a SINGLE message for true parallelism.**\n\nFor each applicable specialist determined in Phase 1, invoke the corresponding review skill using the Skill tool. Pass the story ID as argument.\n\n### Invocation Pattern\n\nEach specialist is invoked via `Skill(...)` (Rule 13 — INLINE-SKILL pattern, parallel execution) AND is tracked individually via a per-specialist TaskCreate\u002FTaskUpdate pair (Story 0033-0003 Concern #3 — Level 3 tracking in x-review-codebase). ALL Skill calls and ALL TaskCreate calls in Batch A MUST be in the SAME assistant message for true parallelism — the Claude runtime dispatches tool calls in parallel only when they are siblings in one assistant turn.\n\n**Activation conditions — evaluate BEFORE emitting the batch. Only emit the (TaskCreate, Skill) pair for specialists whose condition is true for the current project profile. Never emit a placeholder pair for inactive specialists.**\n\n- `x-review-qa` — always active.\n- `x-review-performance` — always active.\n- `x-review-database` — only if `database != none`.\n- `x-review-observability` — only if `observability != none`.\n- `x-review-devops` — only if `container != none`.\n- `x-review-data-modeling` — only if `database != none` AND `architecture` is one of `[hexagonal, ddd, cqrs]`.\n- `x-review-security` — only if security frameworks are configured.\n- `x-review-api` — only if a REST interface is present.\n- `x-review-events` — only if event interfaces are present.\n\nProgress is surfaced by the `TaskCreate`\u002F`TaskUpdate` pairs emitted in\nBatches A\u002FB below — the earlier duplicate `TodoWrite(...)` block was\nremoved in EPIC-0055 (story-0055-0006) because it competed with the\ncanonical task hierarchy defined by Rule 25. Only emit the (TaskCreate,\nSkill) pair for specialists whose activation condition is true (Phase 1).\n\n**PRE gate (Rule 25 Invariant 4).** Before Batch A, verify Phase 1\ndetected a valid diff and the story context is consistent:\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode pre --skill x-review-codebase --phase Phase-2-SpecialistReviews\")\n\nOn gate exit 12, abort with a clear error — a failed PRE gate indicates\na stale execution-state.json or predecessor phase that must be resolved.\n\n**Batch A — First assistant message (all TaskCreate + all Skill calls as sibling tool calls):**\n\nEach `subject` follows the Rule 25 §3 canonical regex with the `›`\n(U+203A) separator — `{STORY_ID} › Review › {Specialist}`:\n\n    TaskCreate(subject: \"{STORY_ID} › Review › QA\",            activeForm: \"Running QA review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Performance\",   activeForm: \"Running performance review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Database\",      activeForm: \"Running database review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Observability\", activeForm: \"Running observability review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › DevOps\",        activeForm: \"Running DevOps review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Data Modeling\", activeForm: \"Running data-modeling review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Security\",      activeForm: \"Running security review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › API\",           activeForm: \"Running API review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Events\",        activeForm: \"Running events review\")\n\n**MANDATORY TOOL CALL — NON-NEGOTIABLE (Rule 24):** Each `Skill(skill: \"x-review-*\")` below is a tool call, not prose. Silent omission of any active specialist is a `PROTOCOL_VIOLATION` and the resulting `review-story-{STORY-ID}.md` will fail Camada 3 audit (`EIE_EVIDENCE_MISSING`):\n\n    Skill(skill: \"x-review-qa\",            model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-performance\",          model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-database\",            model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-observability\",           model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-devops\",        model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-data-modeling\", model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-security\",      model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-api\",           model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-events\",        model: \"sonnet\", args: \"{STORY_ID}\")\n\nRecord the returned TaskCreate integer IDs in an in-memory map `reviewTasks` indexed by specialist short name (e.g., `reviewTasks[\"qa\"] = \u003Cid>`, `reviewTasks[\"perf\"] = \u003Cid>`, ...). The mapping is used in Batch B below.\n\n**Wait for all Skill calls to return.** The runtime handles this automatically — the next assistant message is only produced after every tool call in Batch A completes.\n\n**Batch B — Second assistant message (all TaskUpdate calls as sibling tool calls):**\n\n    TaskUpdate(id: reviewTasks[\"qa\"],            status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"perf\"],          status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"db\"],            status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"obs\"],           status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"devops\"],        status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"data-modeling\"], status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"security\"],      status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"api\"],           status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"events\"],        status: \"completed\")\n\nOnly emit `TaskUpdate` for specialists that were active in Batch A. If a specialist review returned STATUS = Rejected (score 0 on critical items), the TaskUpdate still uses `status: \"completed\"` for UI visibility — the authoritative Pass\u002FFail verdict lives in the consolidated dashboard (Step 4), not in the Claude Code task list (CR-04 of EPIC-0033).\n\n**Batch C — Wave POST gate (Rule 25 REGRA-003).** After Batch B, invoke the phase-gate skill in `--mode wave` to verify every task in `--expected-tasks` completed AND every file in `--expected-artifacts` exists:\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode wave --skill x-review-codebase --phase Phase-2-SpecialistReviews --expected-tasks {comma-separated-reviewTasks-ids} --expected-artifacts {comma-separated-report-paths}\")\n\n`--expected-tasks` = the `reviewTasks` IDs recorded in Batch A for the active specialists (same filter as Batch A\u002FB — Rule 25 Invariant 3). `--expected-artifacts` = `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-{specialist}-story-XXXX-YYYY.md` for each active specialist; reports are written in Step 3c. On gate exit 12, surface the failure and return — Phase 3 is skipped until the broken specialist is resolved.\n\nEach skill produces output in the standard review format:\n\n```\nENGINEER: {SPECIALIST}\nSTORY: {STORY_ID}\nSCORE: XX\u002FYY\nSTATUS: Approved | Rejected | Partial\n---\nPASSED:\n- [ID] Description (2\u002F2)\nFAILED:\n- [ID] Description (0\u002F2) -- file:line -- Fix: suggestion [SEVERITY]\nPARTIAL:\n- [ID] Description (1\u002F2) -- file:line -- Improvement: suggestion [SEVERITY]\n```\n\n> **STATUS = Approved** only if ALL items score 2\u002F2.\n> **STATUS = Rejected** if ANY item scores 0.\n> **STATUS = Partial** if ANY item scores 1 but none scores 0.\n\n\u003C!-- phase-no-gate: consolidation aggregates Phase 2 artifacts (already validated by the Phase 2 wave gate); no additional gate needed -->\n## Phase 3 -- Consolidation (Orchestrator -- Inline)\n\nOpen a phase tracker (close with `TaskUpdate(id: phase3TaskId, status: \"completed\")` after Step 3g):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 3 - Consolidate\", activeForm: \"Consolidating review findings\")\n\n### 3a. Collect & Score\n\nParse each skill's output. Build consolidated table:\n\n```\n+---------------+-------+--------------------+\n|    Review     | Score |      Status        |\n+---------------+-------+--------------------+\n| Security      | XX\u002F30 | Approved           |\n| QA            | XX\u002F36 | Rejected           |\n| ...           | ...   | ...                |\n+---------------+-------+--------------------+\nTotal: XXX\u002FYYY (XX%)\nOVERALL: APPROVED | REJECTED\n```\n\n### 3b. Issue Summary\n\nGroup all findings by severity: `CRITICAL: N | HIGH: N | MEDIUM: N | LOW: N`\n\n```\nANY item with score \u003C 2 -> MUST be fixed before merge. No exceptions.\nApproval requires ALL specialists with STATUS: Approved (every item at 2\u002F2).\nOVERALL: APPROVED only when every specialist has STATUS: Approved.\n```\n\n### 3c. Save Individual Reports\n\nSave each specialist's report to `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-{specialist}-story-XXXX-YYYY.md` (extract epic ID XXXX and story sequence YYYY from the story ID). Ensure directory exists: `mkdir -p ai\u002Fepics\u002Fepic-XXXX\u002Freviews`.\n\n**Persistence (EPIC-0042):** Use the Write tool explicitly to save each specialist report:\n\n    Write(file_path: \"ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-{specialist}-story-XXXX-YYYY.md\", content: \"{report_content}\")\n\nDo NOT rely on generating report content in the conversation alone -- every report MUST be written to disk via the Write tool.\n\n### 3d. Generate Consolidated Dashboard\n\nAfter saving all individual reports, generate a consolidated dashboard.\n\n1. **Check dashboard template:**\n   ```bash\n   test -f .claude\u002Ftemplates\u002F_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md && echo \"DASHBOARD_TEMPLATE_AVAILABLE\" || echo \"DASHBOARD_TEMPLATE_MISSING\"\n   ```\n\n2. **If template available:**\n   - Read template at `.claude\u002Ftemplates\u002F_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md`\n   - Create `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fdashboard-story-XXXX-YYYY.md`\n   - Populate with:\n     - **Engineer Scores Table:** One row per specialist with Score, Max, and Status\n     - **Overall Score:** Sum of all specialist scores \u002F sum of all max scores, with percentage\n     - **Overall Status:** `Approved` only if ALL specialists are Approved; `Rejected` if ANY has score 0 items; `Partial` otherwise\n     - **Critical Issues Summary:** All findings with severity Critical or High from all reports\n     - **Severity Distribution:** Aggregate counts across all specialists\n     - **Review History:** Record as Round N with date, scores, and status\n   - Tech Lead Score section: leave as placeholder `--\u002F64 | Status: Pending` (updated by `x-review-pr`)\n   - Dashboard is **cumulative** (RULE-006): if dashboard already exists, append a new round to Review History instead of overwriting\n\n   **Persistence (EPIC-0042):** Use the Write tool explicitly to save the dashboard:\n\n       Write(file_path: \"ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fdashboard-story-XXXX-YYYY.md\", content: \"{dashboard_content}\")\n\n   Do NOT rely on generating dashboard content in the conversation alone -- the dashboard MUST be written to disk via the Write tool.\n\n3. **If template missing:**\n   - Log warning: `Dashboard template not found, skipping dashboard generation`\n   - Continue to next phase without generating dashboard\n\n### 3e. Generate Remediation Tracking\n\nAfter generating the dashboard, create a remediation tracking file.\n\n1. **Check remediation template:**\n   ```bash\n   test -f .claude\u002Ftemplates\u002F_TEMPLATE-REVIEW-REMEDIATION.md && echo \"REMEDIATION_TEMPLATE_AVAILABLE\" || echo \"REMEDIATION_TEMPLATE_MISSING\"\n   ```\n\n2. **If template available:**\n   - Read template at `.claude\u002Ftemplates\u002F_TEMPLATE-REVIEW-REMEDIATION.md`\n   - Create `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fremediation-story-XXXX-YYYY.md`\n   - **Extract findings:** Parse all individual reports for items with status FAILED or PARTIAL\n   - **Populate Findings Tracker:** One row per finding with:\n     - `Finding ID`: Sequential `FIND-NNN`\n     - `Engineer`: Specialist who reported the finding\n     - `Severity`: Critical \u002F High \u002F Medium \u002F Low\n     - `Description`: Finding description from the report\n     - `Status`: All initialized as `Open`\n     - `Fix Commit SHA`: Empty (populated after fixes)\n   - **Populate Remediation Summary:** Count of findings by status (all Open initially)\n   - **Header:** Include total count: `{N} findings pending remediation`\n\n   **Persistence (EPIC-0042):** Use the Write tool explicitly to save the remediation file:\n\n       Write(file_path: \"ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fremediation-story-XXXX-YYYY.md\", content: \"{remediation_content}\")\n\n   Do NOT rely on generating remediation content in the conversation alone -- the remediation file MUST be written to disk via the Write tool.\n\n3. **If template missing:**\n   - Log warning: `Remediation template not found, skipping remediation tracking generation`\n   - Continue to next phase\n\n### 3f. Threat Model Update\n\nAfter saving review artifacts, extract security findings from the Security specialist's report and update the project threat model incrementally.\n\n1. **Check for security findings:** Parse the Security specialist's report for items with severity Critical, High, or Medium. If no security findings exist, skip this step.\n\n2. **Read or create threat model:** If `results\u002Fsecurity\u002Fthreat-model.md` exists, read it. Otherwise, create it from the template `resources\u002Ftemplates\u002F_TEMPLATE-THREAT-MODEL.md`.\n\n3. **Map findings to STRIDE categories:** Classify each security finding into one of the 6 STRIDE categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) based on the nature of the threat.\n\n4. **Apply severity-based auto-add rules:**\n\n   | Finding Severity | Auto-Add? | Initial Status |\n   |-----------------|-----------|----------------|\n   | Critical | Yes | `Open` |\n   | High | Yes | `Open` |\n   | Medium | Yes | `Under Review` |\n   | Low | No | N\u002FA (noted in review only) |\n\n5. **Incremental update behavior:** Append new threats to the appropriate STRIDE category table. Preserve all existing entries -- never remove or overwrite. If a finding matches an existing threat by description, update the existing entry instead of duplicating.\n\n6. **Recompute Risk Summary:** Update the severity counts table in the Risk Summary section to reflect current Open and Under Review threats.\n\n7. **Append Change History:** Add a new row with the current date, story reference, and summary of threats added or updated.\n\n### 3g. Consolidated Summary Box (EPIC-0042)\n\nAfter ALL specialists complete and all artifacts (reports, dashboard, remediation) are saved, emit a formatted summary to the terminal:\n\n```\n============================================================\n SPECIALIST REVIEW — [STORY_ID]\n============================================================\n Overall Score:  XX\u002FYYY (ZZ%)\n\n | Specialist     | Score   | Status   |\n |----------------|---------|----------|\n | QA             | XX\u002F36   | APPROVED\u002FREJECTED |\n | Performance    | XX\u002F26   | APPROVED\u002FREJECTED |\n | Security       | XX\u002F30   | APPROVED\u002FREJECTED |\n | Database       | XX\u002F40   | APPROVED\u002FREJECTED |\n | Observability  | XX\u002F18   | APPROVED\u002FREJECTED |\n | DevOps         | XX\u002F20   | APPROVED\u002FREJECTED |\n | Data Modeling  | XX\u002F20   | APPROVED\u002FREJECTED |\n | API            | XX\u002F16   | APPROVED\u002FREJECTED |\n\n Critical Issues: N\n Open Findings:   N\n------------------------------------------------------------\n Dashboard:   ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fdashboard-story-XXXX-YYYY.md\n Remediation: ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fremediation-story-XXXX-YYYY.md\n============================================================\n```\n\nOnly include rows for specialists that were active in Phase 2. Replace placeholders with actual scores and statuses from the consolidation data.\n\n\u003C!-- phase-no-gate: conditional correction-story generation; runs only when findings exist and is intrinsically guarded by Phase 3 consolidation result -->\n## Phase 4 -- Story Generation for Findings (Orchestrator -- Inline)\n\nOpen a phase tracker only when this phase runs — see Step 4a (close with `TaskUpdate(id: phase4TaskId, status: \"completed\")` after Step 4c):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 4 - Correction story\", activeForm: \"Generating correction story\")\n\nThis phase runs ONLY when CRITICAL, HIGH, or MEDIUM findings exist.\n\n### 4a. Check Findings\n\nAfter consolidation, evaluate if there are findings with severity CRITICAL, HIGH, or MEDIUM.\nIf all findings are LOW or there are no findings, skip this phase entirely.\n\n### 4b. Auto-Generate Correction Story (EPIC-0042)\n\n**Default behavior (auto-execution):** When CRITICAL or HIGH findings exist, automatically\ngenerate a correction story WITHOUT asking the user. Log:\n`\"Auto-generating correction story for {N} CRITICAL\u002FHIGH findings (EPIC-0042)\"`\n\n**Exception — CRITICAL security findings:** When ANY finding with severity CRITICAL originates\nfrom the Security specialist (`x-review-security`), pause for mandatory human confirmation\nbefore proceeding. Use `AskUserQuestion`:\n\n```\nquestion: \"CRITICAL security finding detected. Review the finding and confirm correction story generation.\"\nheader: \"Security — Mandatory Human Review\"\noptions:\n  - label: \"Generate correction story\"\n    description: \"Proceed with auto-generating correction story including the CRITICAL security finding\"\n  - label: \"Abort\"\n    description: \"Do not generate correction story. Manual remediation required.\"\nmultiSelect: false\n```\n\nIf \"Abort\", end the review process normally. Log:\n`\"Correction story generation aborted by user (CRITICAL security finding)\"`\n\n**Opt-out flag `--no-auto-fix-story` (EPIC-0042):** When `--no-auto-fix-story` is present,\nsuppress automatic correction story generation. Instead, use `AskUserQuestion` to confirm:\n\n```\nquestion: \"Deseja criar uma historia para correcao dos problemas encontrados?\"\nheader: \"Story\"\noptions:\n  - label: \"Sim\"\n    description: \"Gerar uma historia com os findings CRITICAL e MEDIUM como criterios de aceite\"\n  - label: \"Nao\"\n    description: \"Apenas manter o relatorio de review sem gerar historia\"\nmultiSelect: false\n```\n\nIf \"Nao\", end the review process normally.\n\n### 4c. Generate Correction Story\n\nWhen auto-generation proceeds (default) or user selects \"Sim\" (with `--no-auto-fix-story`),\ngenerate a correction story following these steps:\n\n1. **Read the story template:**\n   ```\n   .claude\u002Ftemplates\u002F_TEMPLATE-STORY.md\n   ```\n\n2. **Build the story content** using findings as input:\n\n   - **Story ID**: `STORY-{STORY_ID}-FIX-{NNN}` (where NNN is sequential)\n   - **Title**: `Correcao de findings do review -- {STORY_ID}`\n   - **Descricao**: Summary of what was found, grouped by specialist and severity\n   - **Regras Transversais**: Reference rules violated by the findings\n   - **Criterios de Aceite (Gherkin)**: Transform each CRITICAL and MEDIUM finding into a Gherkin scenario:\n     ```\n     Cenario: {finding description}\n       DADO que o codigo atual {describe current violation}\n       QUANDO a correcao for aplicada\n       ENTAO {expected fix result}\n       E o score do review para {specialist} deve melhorar\n     ```\n   - **Sub-tarefas**: One `[Dev]` task per CRITICAL finding, grouped `[Dev]` tasks for MEDIUM findings by specialist, one `[Test]` task to re-run `\u002Fx-review-codebase` after fixes\n   - **DoD Local**: All CRITICAL findings resolved, all MEDIUM findings resolved or justified, `\u002Fx-review-codebase` re-run with no new CRITICAL findings\n\n3. **Save the story** to `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fcorrection-story-XXXX-YYYY.md`\n\n4. **Report** to the user: story file path, number of findings converted, and suggested next step (`\u002Fx-implement-task` or manual fix).\n\n## Phase 5 -- Emit Frontmatter (MANDATORY -- Rule 24 §Camada-1)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-review-codebase Phase-5-Frontmatter`\n\n> **MANDATORY TOOL CALL (Rule 24 §Camada-1):** This phase MUST NOT be inlined, simulated,\n> or omitted. The LLM MUST prepend the populated YAML frontmatter to the review artifact.\n> Absent frontmatter is detected by `audit-review-frontmatter.sh` (Layer 3 CI) and the Stop\n> hook (Layer 2 runtime). There is no fallback when frontmatter emission fails.\n\nTaskCreate(\n  subject: \"\u003CSTORY_ID> › Phase 5 › Emit specialist review frontmatter\",\n  activeForm: \"Emitting specialist review frontmatter\",\n  metadata: {\n    \"phase\": \"Phase 5\",\n    \"parentSkill\": \"x-review-codebase\",\n    \"storyId\": \"\u003CSTORY_ID>\",\n    \"epicId\": \"\u003CEPIC_ID>\",\n    \"expectedArtifacts\": [\"\u003Cpath to review-story-XXXX-YYYY.md>\"]\n  }\n)\n\nInvoke pre-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode pre --phase 'Phase 5' --skill x-review-codebase\")\n\nAfter all specialist subagents have returned findings and the prose body of\n`review-story-\u003CSTORY_ID>.md` has been assembled, prepend the YAML frontmatter block\nconforming to `governance\u002Fschemas\u002Freview-frontmatter-1.0.json`:\n\n```\n\u003C!-- template-version: 1.0 -->\n---\nschema-version: \"1.0\"\ngenerated-by: x-review-codebase@\u003Cgit rev-parse HEAD>\nstory-id: \u003CSTORY_ID>\nepic-id: \u003CEPIC_ID>\ndate: \u003Cdate -u +%Y-%m-%dT%H:%M:%SZ>\ndecision: \u003CGO|NO-GO|GO-WITH-RESERVATIONS>\nscore: \u003Csum of specialist scores>\nscore-max: 50\nseverity-counts:\n  critical: \u003Ccount>\n  high: \u003Ccount>\n  medium: \u003Ccount>\n  low: \u003Ccount>\n  info: \u003Ccount>\nblocking-findings:\n\u003CYAML list of critical\u002Fhigh findings, empty list [] if none>\nreviewers:\n\u003CYAML list of invoked specialist roles>\n---\n# Specialist Review — \u003CSTORY_ID>\n...existing prose body...\n```\n\n**Decision consolidation rule:** NO-GO > GO-WITH-RESERVATIONS > GO. If any specialist\nreturned NO-GO → `decision: \"NO-GO\"`. If any returned GO-WITH-RESERVATIONS (and no NO-GO)\n→ `decision: \"GO-WITH-RESERVATIONS\"`. Otherwise → `decision: \"GO\"`.\n\nAfter writing the artifact, validate:\n\n    Bash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fscripts\u002Faudit-review-frontmatter.sh --story \u003CSTORY_ID>`\n\nIf the script returns exit ≠ 0, abort with `REVIEW_FRONTMATTER_INVALID`. No fallback.\n\nInvoke post-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode post --phase 'Phase 5' --skill x-review-codebase --expected-artifacts \u003Cpath to review-story-XXXX-YYYY.md>\")\n\nTaskUpdate(taskId: \u003Cid from TaskCreate above>, status: \"completed\")\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-review-codebase Phase-5-Frontmatter ok`\n\n## Phase 5 -- Emit Frontmatter (MANDATORY -- Rule 24 §Camada-1)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-review Phase-5-Frontmatter`\n\n> **MANDATORY TOOL CALL (Rule 24 §Camada-1):** This phase MUST NOT be inlined, simulated,\n> or omitted. The LLM MUST prepend the populated YAML frontmatter to the review artifact.\n> Absent frontmatter is detected by `audit-review-frontmatter.sh` (Layer 3 CI) and the Stop\n> hook (Layer 2 runtime). There is no fallback when frontmatter emission fails.\n\nTaskCreate(\n  subject: \"\u003CSTORY_ID> › Phase 5 › Emit specialist review frontmatter\",\n  activeForm: \"Emitting specialist review frontmatter\",\n  metadata: {\n    \"phase\": \"Phase 5\",\n    \"parentSkill\": \"x-review\",\n    \"storyId\": \"\u003CSTORY_ID>\",\n    \"epicId\": \"\u003CEPIC_ID>\",\n    \"expectedArtifacts\": [\"\u003Cpath to review-story-XXXX-YYYY.md>\"]\n  }\n)\n\nInvoke pre-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-phase-gate\", model: \"haiku\", args: \"--mode pre --phase 'Phase 5' --skill x-review\")\n\nAfter all specialist subagents have returned findings and the prose body of\n`review-story-\u003CSTORY_ID>.md` has been assembled, prepend the YAML frontmatter block\nconforming to `governance\u002Fschemas\u002Freview-frontmatter-1.0.json`:\n\n```\n\u003C!-- template-version: 1.0 -->\n---\nschema-version: \"1.0\"\ngenerated-by: x-review@\u003Cgit rev-parse HEAD>\nstory-id: \u003CSTORY_ID>\nepic-id: \u003CEPIC_ID>\ndate: \u003Cdate -u +%Y-%m-%dT%H:%M:%SZ>\ndecision: \u003CGO|NO-GO|GO-WITH-RESERVATIONS>\nscore: \u003Csum of specialist scores>\nscore-max: 50\nseverity-counts:\n  critical: \u003Ccount>\n  high: \u003Ccount>\n  medium: \u003Ccount>\n  low: \u003Ccount>\n  info: \u003Ccount>\nblocking-findings:\n\u003CYAML list of critical\u002Fhigh findings, empty list [] if none>\nreviewers:\n\u003CYAML list of invoked specialist roles>\n---\n# Specialist Review — \u003CSTORY_ID>\n...existing prose body...\n```\n\n**Decision consolidation rule:** NO-GO > GO-WITH-RESERVATIONS > GO. If any specialist\nreturned NO-GO → `decision: \"NO-GO\"`. If any returned GO-WITH-RESERVATIONS (and no NO-GO)\n→ `decision: \"GO-WITH-RESERVATIONS\"`. Otherwise → `decision: \"GO\"`.\n\nAfter writing the artifact, validate:\n\n    Bash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fscripts\u002Faudit-review-frontmatter.sh --story \u003CSTORY_ID>`\n\nIf the script returns exit ≠ 0, abort with `REVIEW_FRONTMATTER_INVALID`. No fallback.\n\nInvoke post-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-phase-gate\", model: \"haiku\", args: \"--mode post --phase 'Phase 5' --skill x-review --expected-artifacts \u003Cpath to review-story-XXXX-YYYY.md>\")\n\nTaskUpdate(taskId: \u003Cid from TaskCreate above>, status: \"completed\")\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-review Phase-5-Frontmatter ok`\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| No changes found relative to main | Abort with message: `No changes found relative to main.` |\n| Skill returns invalid output (missing SCORE or STATUS) | Mark specialist as `FAILED`, score 0, continue with remaining specialists |\n| Dashboard template not found | Log warning, skip dashboard generation, continue to next phase |\n| Remediation template not found | Log warning, skip remediation tracking generation, continue |\n| All specialists return FAILED | Overall status `REJECTED`, report saved with 0 scores |\n\n## Template Fallback\n\nTemplates referenced by this skill follow RULE-012. When a template file does not exist (e.g., pre-EPIC-0024 projects), the skill degrades gracefully:\n\n- `_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md` -- dashboard generation skipped\n- `_TEMPLATE-REVIEW-REMEDIATION.md` -- remediation tracking skipped\n\nWhen templates are absent, dashboard\u002Fremediation are skipped.\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n|-------|-------------|---------|\n| `x-implement-story` | Called by (Phase 4) | Produces the same artifacts as lifecycle Phase 4 |\n| `x-review-pr` | Followed by | Recommended flow: `\u002Fx-review-codebase` then fix criticals then `\u002Fx-review-pr` |\n| `x-story-create` | Reads format | Correction stories (Phase 4) follow the story template |\n| `x-implement-task` | Followed by | Correction stories can be picked up by `\u002Fx-implement-task` |\n| `_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md` | Reads | Dashboard format, cumulative across rounds (RULE-006) |\n| `_TEMPLATE-REVIEW-REMEDIATION.md` | Reads | Remediation tracking format |\n| `PlanTemplatesAssembler` | Depends on | Templates copied verbatim -- not rendered by the engine |\n","## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n# Skill: Specialist Review (Orchestrator)\n\n## Purpose\n\nPerform parallel specialist code reviews across multiple engineering dimensions by delegating to individual review skills (`\u002Fx-review-qa`, `\u002Fx-review-performance`, `\u002Fx-review-database`, etc.), consolidating findings into a scored dashboard, and optionally generating correction stories for critical findings.\n\n## When to Use\n\n- `\u002Fx-review-codebase` -- review current branch\n- `\u002Fx-review-codebase STORY-ID` -- review specific story\n- `\u002Fx-review-codebase --scope security,qa` -- run only specific reviewers\n\n## Workflow Overview\n\n```\n0. PRE-CHECK   -> Idempotency: skip if reports exist and code unchanged (inline)\n1. DETECT      -> Identify branch, diff, applicable specialists (inline)\n2. REVIEW      -> Invoke N review skills in parallel via Skill tool (SINGLE message)\n3. CONSOLIDATE -> Collect reports, score, dashboard, remediation (inline)\n4. STORY       -> If CRITICAL\u002FMEDIUM findings: ask user, generate correction story (inline)\n```\n\n\u003C!-- phase-no-gate: read-only idempotency pre-check; no artifact produced -->\n## Phase 0 -- Idempotency Pre-Check (Orchestrator -- Inline)\n\nOpen a phase tracker (close with `TaskUpdate(id: phase0TaskId, status: \"completed\")` after Step 5):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 0 - Idempotency\", activeForm: \"Checking review idempotency\")\n\nBefore executing a review, check if reports already exist and are still valid.\n\n1. Extract story ID from argument or branch name (e.g., `story-XXXX-YYYY`)\n2. Derive epic directory: `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002F`\n3. Check if report files exist:\n   ```bash\n   ls ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-*-story-XXXX-YYYY.md 2>\u002Fdev\u002Fnull\n   ```\n4. If reports exist AND the branch has no new commits since last report:\n   ```bash\n   # Compare latest report mtime with latest commit date\n   stat -c %Y ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-security-story-XXXX-YYYY.md 2>\u002Fdev\u002Fnull\n   git log -1 --format=%ct HEAD\n   ```\n   - If `mtime(report) >= commit_date`: log `Reusing existing review reports from {date}` and skip to Phase 3c (dashboard regeneration)\n   - If code changed after reports: proceed with full review\n5. If no reports exist, proceed normally\n\nPersist interactiveMode to execution-state.json (EPIC-0068 — consumed by Stop hook `enforce-continuous-flow.sh`):\n\n    Skill(skill: \"x-internal-update-status\", args: \"--file ai\u002Fepics\u002Fepic-XXXX\u002Fexecution-state.json --type story --id \u003CSTORY-ID> --field interactiveMode --value \u003Cinteractive|non-interactive>\")\n\nValue: `\"interactive\"` when `--interactive` passed or `CLAUDE_LEGACY_INTERACTIVE=1`; otherwise `\"non-interactive\"` (Rule 20 default, EPIC-0061).\n\n    TaskUpdate(id: phase0TaskId, status: \"completed\")\n\n\u003C!-- phase-no-gate: read-only context detection; no artifact produced -->\n## Phase 1 -- Detect Context (Orchestrator -- Inline)\n\nOpen a phase tracker (close with `TaskUpdate(id: phase1TaskId, status: \"completed\")` after Step 4):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 1 - Detect\", activeForm: \"Detecting review context\")\n\n1. Extract story ID from argument or branch name\n2. Get diff against main:\n   ```bash\n   git branch --show-current\n   git diff main --stat\n   git diff main --name-only\n   ```\n3. If no changes, abort: `No changes found relative to main.`\n4. Determine applicable specialists using Specialist Reference Table below.\n\n**Always active:** QA, Performance\n\n**Conditional:** Activated only when their feature gate condition is met.\n\nIf `--scope` provided, filter to listed specialists only.\n\n## Specialist Reference Table\n\n| Specialist | Skill | Max Score | Condition |\n|------------|-------|-----------|-----------|\n| QA | `\u002Fx-review-qa` | \u002F36 | Always |\n| Performance | `\u002Fx-review-performance` | \u002F26 | Always |\n| Database | `\u002Fx-review-database` | \u002F40 | database != none |\n| Observability | `\u002Fx-review-observability` | \u002F18 | observability != none |\n| DevOps | `\u002Fx-review-devops` | \u002F20 | container != none |\n| Data Modeling | `\u002Fx-review-data-modeling` | \u002F20 | database != none AND architecture in [hexagonal, ddd, cqrs] |\n| Security | `\u002Fx-review-security` | \u002F30 | security frameworks configured |\n| API | `\u002Fx-review-api` | \u002F16 | REST interface present |\n| Event | `\u002Fx-review-events` | \u002F28 | event-driven or event interfaces |\n\n> Each individual skill contains its own checklist, knowledge pack references, and scoring logic. The orchestrator does NOT duplicate these -- it delegates entirely.\n\n## Composition Pattern (RULE-007 — EPIC-0064)\n\nFragment-slot composition — only specialists relevant to active capabilities are included.\nSee [`references\u002Fcomposition-architecture.md`](references\u002Fcomposition-architecture.md) for the canonical fragment table and contribution guide.\n\n{{ #each fragments.review-specialist }}\n\n## Phase 2 -- Parallel Reviews (Skills via Skill Tool)\n\n**CONTEXT ISOLATION: You receive only metadata. Read all files yourself.\nDo NOT expect source code, diffs, or knowledge pack content in this prompt.\nEach review skill reads its own knowledge pack and runs `git diff` independently.**\n\n**CRITICAL: ALL review skills MUST be invoked in a SINGLE message for true parallelism.**\n\nFor each applicable specialist determined in Phase 1, invoke the corresponding review skill using the Skill tool. Pass the story ID as argument.\n\n### Invocation Pattern\n\nEach specialist is invoked via `Skill(...)` (Rule 13 — INLINE-SKILL pattern, parallel execution) AND is tracked individually via a per-specialist TaskCreate\u002FTaskUpdate pair (Story 0033-0003 Concern #3 — Level 3 tracking in x-review-codebase). ALL Skill calls and ALL TaskCreate calls in Batch A MUST be in the SAME assistant message for true parallelism — the Claude runtime dispatches tool calls in parallel only when they are siblings in one assistant turn.\n\n**Activation conditions — evaluate BEFORE emitting the batch. Only emit the (TaskCreate, Skill) pair for specialists whose condition is true for the current project profile. Never emit a placeholder pair for inactive specialists.**\n\n- `x-review-qa` — always active.\n- `x-review-performance` — always active.\n- `x-review-database` — only if `database != none`.\n- `x-review-observability` — only if `observability != none`.\n- `x-review-devops` — only if `container != none`.\n- `x-review-data-modeling` — only if `database != none` AND `architecture` is one of `[hexagonal, ddd, cqrs]`.\n- `x-review-security` — only if security frameworks are configured.\n- `x-review-api` — only if a REST interface is present.\n- `x-review-events` — only if event interfaces are present.\n\nProgress is surfaced by the `TaskCreate`\u002F`TaskUpdate` pairs emitted in\nBatches A\u002FB below — the earlier duplicate `TodoWrite(...)` block was\nremoved in EPIC-0055 (story-0055-0006) because it competed with the\ncanonical task hierarchy defined by Rule 25. Only emit the (TaskCreate,\nSkill) pair for specialists whose activation condition is true (Phase 1).\n\n**PRE gate (Rule 25 Invariant 4).** Before Batch A, verify Phase 1\ndetected a valid diff and the story context is consistent:\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode pre --skill x-review-codebase --phase Phase-2-SpecialistReviews\")\n\nOn gate exit 12, abort with a clear error — a failed PRE gate indicates\na stale execution-state.json or predecessor phase that must be resolved.\n\n**Batch A — First assistant message (all TaskCreate + all Skill calls as sibling tool calls):**\n\nEach `subject` follows the Rule 25 §3 canonical regex with the `›`\n(U+203A) separator — `{STORY_ID} › Review › {Specialist}`:\n\n    TaskCreate(subject: \"{STORY_ID} › Review › QA\",            activeForm: \"Running QA review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Performance\",   activeForm: \"Running performance review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Database\",      activeForm: \"Running database review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Observability\", activeForm: \"Running observability review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › DevOps\",        activeForm: \"Running DevOps review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Data Modeling\", activeForm: \"Running data-modeling review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Security\",      activeForm: \"Running security review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › API\",           activeForm: \"Running API review\")\n    TaskCreate(subject: \"{STORY_ID} › Review › Events\",        activeForm: \"Running events review\")\n\n**MANDATORY TOOL CALL — NON-NEGOTIABLE (Rule 24):** Each `Skill(skill: \"x-review-*\")` below is a tool call, not prose. Silent omission of any active specialist is a `PROTOCOL_VIOLATION` and the resulting `review-story-{STORY-ID}.md` will fail Camada 3 audit (`EIE_EVIDENCE_MISSING`):\n\n    Skill(skill: \"x-review-qa\",            model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-performance\",          model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-database\",            model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-observability\",           model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-devops\",        model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-data-modeling\", model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-security\",      model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-api\",           model: \"sonnet\", args: \"{STORY_ID}\")\n    Skill(skill: \"x-review-events\",        model: \"sonnet\", args: \"{STORY_ID}\")\n\nRecord the returned TaskCreate integer IDs in an in-memory map `reviewTasks` indexed by specialist short name (e.g., `reviewTasks[\"qa\"] = \u003Cid>`, `reviewTasks[\"perf\"] = \u003Cid>`, ...). The mapping is used in Batch B below.\n\n**Wait for all Skill calls to return.** The runtime handles this automatically — the next assistant message is only produced after every tool call in Batch A completes.\n\n**Batch B — Second assistant message (all TaskUpdate calls as sibling tool calls):**\n\n    TaskUpdate(id: reviewTasks[\"qa\"],            status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"perf\"],          status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"db\"],            status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"obs\"],           status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"devops\"],        status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"data-modeling\"], status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"security\"],      status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"api\"],           status: \"completed\")\n    TaskUpdate(id: reviewTasks[\"events\"],        status: \"completed\")\n\nOnly emit `TaskUpdate` for specialists that were active in Batch A. If a specialist review returned STATUS = Rejected (score 0 on critical items), the TaskUpdate still uses `status: \"completed\"` for UI visibility — the authoritative Pass\u002FFail verdict lives in the consolidated dashboard (Step 4), not in the Claude Code task list (CR-04 of EPIC-0033).\n\n**Batch C — Wave POST gate (Rule 25 REGRA-003).** After Batch B, invoke the phase-gate skill in `--mode wave` to verify every task in `--expected-tasks` completed AND every file in `--expected-artifacts` exists:\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode wave --skill x-review-codebase --phase Phase-2-SpecialistReviews --expected-tasks {comma-separated-reviewTasks-ids} --expected-artifacts {comma-separated-report-paths}\")\n\n`--expected-tasks` = the `reviewTasks` IDs recorded in Batch A for the active specialists (same filter as Batch A\u002FB — Rule 25 Invariant 3). `--expected-artifacts` = `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-{specialist}-story-XXXX-YYYY.md` for each active specialist; reports are written in Step 3c. On gate exit 12, surface the failure and return — Phase 3 is skipped until the broken specialist is resolved.\n\nEach skill produces output in the standard review format:\n\n```\nENGINEER: {SPECIALIST}\nSTORY: {STORY_ID}\nSCORE: XX\u002FYY\nSTATUS: Approved | Rejected | Partial\n---\nPASSED:\n- [ID] Description (2\u002F2)\nFAILED:\n- [ID] Description (0\u002F2) -- file:line -- Fix: suggestion [SEVERITY]\nPARTIAL:\n- [ID] Description (1\u002F2) -- file:line -- Improvement: suggestion [SEVERITY]\n```\n\n> **STATUS = Approved** only if ALL items score 2\u002F2.\n> **STATUS = Rejected** if ANY item scores 0.\n> **STATUS = Partial** if ANY item scores 1 but none scores 0.\n\n\u003C!-- phase-no-gate: consolidation aggregates Phase 2 artifacts (already validated by the Phase 2 wave gate); no additional gate needed -->\n## Phase 3 -- Consolidation (Orchestrator -- Inline)\n\nOpen a phase tracker (close with `TaskUpdate(id: phase3TaskId, status: \"completed\")` after Step 3g):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 3 - Consolidate\", activeForm: \"Consolidating review findings\")\n\n### 3a. Collect & Score\n\nParse each skill's output. Build consolidated table:\n\n```\n+---------------+-------+--------------------+\n|    Review     | Score |      Status        |\n+---------------+-------+--------------------+\n| Security      | XX\u002F30 | Approved           |\n| QA            | XX\u002F36 | Rejected           |\n| ...           | ...   | ...                |\n+---------------+-------+--------------------+\nTotal: XXX\u002FYYY (XX%)\nOVERALL: APPROVED | REJECTED\n```\n\n### 3b. Issue Summary\n\nGroup all findings by severity: `CRITICAL: N | HIGH: N | MEDIUM: N | LOW: N`\n\n```\nANY item with score \u003C 2 -> MUST be fixed before merge. No exceptions.\nApproval requires ALL specialists with STATUS: Approved (every item at 2\u002F2).\nOVERALL: APPROVED only when every specialist has STATUS: Approved.\n```\n\n### 3c. Save Individual Reports\n\nSave each specialist's report to `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-{specialist}-story-XXXX-YYYY.md` (extract epic ID XXXX and story sequence YYYY from the story ID). Ensure directory exists: `mkdir -p ai\u002Fepics\u002Fepic-XXXX\u002Freviews`.\n\n**Persistence (EPIC-0042):** Use the Write tool explicitly to save each specialist report:\n\n    Write(file_path: \"ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Freview-{specialist}-story-XXXX-YYYY.md\", content: \"{report_content}\")\n\nDo NOT rely on generating report content in the conversation alone -- every report MUST be written to disk via the Write tool.\n\n### 3d. Generate Consolidated Dashboard\n\nAfter saving all individual reports, generate a consolidated dashboard.\n\n1. **Check dashboard template:**\n   ```bash\n   test -f .claude\u002Ftemplates\u002F_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md && echo \"DASHBOARD_TEMPLATE_AVAILABLE\" || echo \"DASHBOARD_TEMPLATE_MISSING\"\n   ```\n\n2. **If template available:**\n   - Read template at `.claude\u002Ftemplates\u002F_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md`\n   - Create `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fdashboard-story-XXXX-YYYY.md`\n   - Populate with:\n     - **Engineer Scores Table:** One row per specialist with Score, Max, and Status\n     - **Overall Score:** Sum of all specialist scores \u002F sum of all max scores, with percentage\n     - **Overall Status:** `Approved` only if ALL specialists are Approved; `Rejected` if ANY has score 0 items; `Partial` otherwise\n     - **Critical Issues Summary:** All findings with severity Critical or High from all reports\n     - **Severity Distribution:** Aggregate counts across all specialists\n     - **Review History:** Record as Round N with date, scores, and status\n   - Tech Lead Score section: leave as placeholder `--\u002F64 | Status: Pending` (updated by `x-review-pr`)\n   - Dashboard is **cumulative** (RULE-006): if dashboard already exists, append a new round to Review History instead of overwriting\n\n   **Persistence (EPIC-0042):** Use the Write tool explicitly to save the dashboard:\n\n       Write(file_path: \"ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fdashboard-story-XXXX-YYYY.md\", content: \"{dashboard_content}\")\n\n   Do NOT rely on generating dashboard content in the conversation alone -- the dashboard MUST be written to disk via the Write tool.\n\n3. **If template missing:**\n   - Log warning: `Dashboard template not found, skipping dashboard generation`\n   - Continue to next phase without generating dashboard\n\n### 3e. Generate Remediation Tracking\n\nAfter generating the dashboard, create a remediation tracking file.\n\n1. **Check remediation template:**\n   ```bash\n   test -f .claude\u002Ftemplates\u002F_TEMPLATE-REVIEW-REMEDIATION.md && echo \"REMEDIATION_TEMPLATE_AVAILABLE\" || echo \"REMEDIATION_TEMPLATE_MISSING\"\n   ```\n\n2. **If template available:**\n   - Read template at `.claude\u002Ftemplates\u002F_TEMPLATE-REVIEW-REMEDIATION.md`\n   - Create `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fremediation-story-XXXX-YYYY.md`\n   - **Extract findings:** Parse all individual reports for items with status FAILED or PARTIAL\n   - **Populate Findings Tracker:** One row per finding with:\n     - `Finding ID`: Sequential `FIND-NNN`\n     - `Engineer`: Specialist who reported the finding\n     - `Severity`: Critical \u002F High \u002F Medium \u002F Low\n     - `Description`: Finding description from the report\n     - `Status`: All initialized as `Open`\n     - `Fix Commit SHA`: Empty (populated after fixes)\n   - **Populate Remediation Summary:** Count of findings by status (all Open initially)\n   - **Header:** Include total count: `{N} findings pending remediation`\n\n   **Persistence (EPIC-0042):** Use the Write tool explicitly to save the remediation file:\n\n       Write(file_path: \"ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fremediation-story-XXXX-YYYY.md\", content: \"{remediation_content}\")\n\n   Do NOT rely on generating remediation content in the conversation alone -- the remediation file MUST be written to disk via the Write tool.\n\n3. **If template missing:**\n   - Log warning: `Remediation template not found, skipping remediation tracking generation`\n   - Continue to next phase\n\n### 3f. Threat Model Update\n\nAfter saving review artifacts, extract security findings from the Security specialist's report and update the project threat model incrementally.\n\n1. **Check for security findings:** Parse the Security specialist's report for items with severity Critical, High, or Medium. If no security findings exist, skip this step.\n\n2. **Read or create threat model:** If `results\u002Fsecurity\u002Fthreat-model.md` exists, read it. Otherwise, create it from the template `resources\u002Ftemplates\u002F_TEMPLATE-THREAT-MODEL.md`.\n\n3. **Map findings to STRIDE categories:** Classify each security finding into one of the 6 STRIDE categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) based on the nature of the threat.\n\n4. **Apply severity-based auto-add rules:**\n\n   | Finding Severity | Auto-Add? | Initial Status |\n   |-----------------|-----------|----------------|\n   | Critical | Yes | `Open` |\n   | High | Yes | `Open` |\n   | Medium | Yes | `Under Review` |\n   | Low | No | N\u002FA (noted in review only) |\n\n5. **Incremental update behavior:** Append new threats to the appropriate STRIDE category table. Preserve all existing entries -- never remove or overwrite. If a finding matches an existing threat by description, update the existing entry instead of duplicating.\n\n6. **Recompute Risk Summary:** Update the severity counts table in the Risk Summary section to reflect current Open and Under Review threats.\n\n7. **Append Change History:** Add a new row with the current date, story reference, and summary of threats added or updated.\n\n### 3g. Consolidated Summary Box (EPIC-0042)\n\nAfter ALL specialists complete and all artifacts (reports, dashboard, remediation) are saved, emit a formatted summary to the terminal:\n\n```\n============================================================\n SPECIALIST REVIEW — [STORY_ID]\n============================================================\n Overall Score:  XX\u002FYYY (ZZ%)\n\n | Specialist     | Score   | Status   |\n |----------------|---------|----------|\n | QA             | XX\u002F36   | APPROVED\u002FREJECTED |\n | Performance    | XX\u002F26   | APPROVED\u002FREJECTED |\n | Security       | XX\u002F30   | APPROVED\u002FREJECTED |\n | Database       | XX\u002F40   | APPROVED\u002FREJECTED |\n | Observability  | XX\u002F18   | APPROVED\u002FREJECTED |\n | DevOps         | XX\u002F20   | APPROVED\u002FREJECTED |\n | Data Modeling  | XX\u002F20   | APPROVED\u002FREJECTED |\n | API            | XX\u002F16   | APPROVED\u002FREJECTED |\n\n Critical Issues: N\n Open Findings:   N\n------------------------------------------------------------\n Dashboard:   ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fdashboard-story-XXXX-YYYY.md\n Remediation: ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fremediation-story-XXXX-YYYY.md\n============================================================\n```\n\nOnly include rows for specialists that were active in Phase 2. Replace placeholders with actual scores and statuses from the consolidation data.\n\n\u003C!-- phase-no-gate: conditional correction-story generation; runs only when findings exist and is intrinsically guarded by Phase 3 consolidation result -->\n## Phase 4 -- Story Generation for Findings (Orchestrator -- Inline)\n\nOpen a phase tracker only when this phase runs — see Step 4a (close with `TaskUpdate(id: phase4TaskId, status: \"completed\")` after Step 4c):\n\n    TaskCreate(subject: \"{STORY_ID} › Review › Phase 4 - Correction story\", activeForm: \"Generating correction story\")\n\nThis phase runs ONLY when CRITICAL, HIGH, or MEDIUM findings exist.\n\n### 4a. Check Findings\n\nAfter consolidation, evaluate if there are findings with severity CRITICAL, HIGH, or MEDIUM.\nIf all findings are LOW or there are no findings, skip this phase entirely.\n\n### 4b. Auto-Generate Correction Story (EPIC-0042)\n\n**Default behavior (auto-execution):** When CRITICAL or HIGH findings exist, automatically\ngenerate a correction story WITHOUT asking the user. Log:\n`\"Auto-generating correction story for {N} CRITICAL\u002FHIGH findings (EPIC-0042)\"`\n\n**Exception — CRITICAL security findings:** When ANY finding with severity CRITICAL originates\nfrom the Security specialist (`x-review-security`), pause for mandatory human confirmation\nbefore proceeding. Use `AskUserQuestion`:\n\n```\nquestion: \"CRITICAL security finding detected. Review the finding and confirm correction story generation.\"\nheader: \"Security — Mandatory Human Review\"\noptions:\n  - label: \"Generate correction story\"\n    description: \"Proceed with auto-generating correction story including the CRITICAL security finding\"\n  - label: \"Abort\"\n    description: \"Do not generate correction story. Manual remediation required.\"\nmultiSelect: false\n```\n\nIf \"Abort\", end the review process normally. Log:\n`\"Correction story generation aborted by user (CRITICAL security finding)\"`\n\n**Opt-out flag `--no-auto-fix-story` (EPIC-0042):** When `--no-auto-fix-story` is present,\nsuppress automatic correction story generation. Instead, use `AskUserQuestion` to confirm:\n\n```\nquestion: \"Deseja criar uma historia para correcao dos problemas encontrados?\"\nheader: \"Story\"\noptions:\n  - label: \"Sim\"\n    description: \"Gerar uma historia com os findings CRITICAL e MEDIUM como criterios de aceite\"\n  - label: \"Nao\"\n    description: \"Apenas manter o relatorio de review sem gerar historia\"\nmultiSelect: false\n```\n\nIf \"Nao\", end the review process normally.\n\n### 4c. Generate Correction Story\n\nWhen auto-generation proceeds (default) or user selects \"Sim\" (with `--no-auto-fix-story`),\ngenerate a correction story following these steps:\n\n1. **Read the story template:**\n   ```\n   .claude\u002Ftemplates\u002F_TEMPLATE-STORY.md\n   ```\n\n2. **Build the story content** using findings as input:\n\n   - **Story ID**: `STORY-{STORY_ID}-FIX-{NNN}` (where NNN is sequential)\n   - **Title**: `Correcao de findings do review -- {STORY_ID}`\n   - **Descricao**: Summary of what was found, grouped by specialist and severity\n   - **Regras Transversais**: Reference rules violated by the findings\n   - **Criterios de Aceite (Gherkin)**: Transform each CRITICAL and MEDIUM finding into a Gherkin scenario:\n     ```\n     Cenario: {finding description}\n       DADO que o codigo atual {describe current violation}\n       QUANDO a correcao for aplicada\n       ENTAO {expected fix result}\n       E o score do review para {specialist} deve melhorar\n     ```\n   - **Sub-tarefas**: One `[Dev]` task per CRITICAL finding, grouped `[Dev]` tasks for MEDIUM findings by specialist, one `[Test]` task to re-run `\u002Fx-review-codebase` after fixes\n   - **DoD Local**: All CRITICAL findings resolved, all MEDIUM findings resolved or justified, `\u002Fx-review-codebase` re-run with no new CRITICAL findings\n\n3. **Save the story** to `ai\u002Fepics\u002Fepic-XXXX\u002Freviews\u002Fcorrection-story-XXXX-YYYY.md`\n\n4. **Report** to the user: story file path, number of findings converted, and suggested next step (`\u002Fx-implement-task` or manual fix).\n\n## Phase 5 -- Emit Frontmatter (MANDATORY -- Rule 24 §Camada-1)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-review-codebase Phase-5-Frontmatter`\n\n> **MANDATORY TOOL CALL (Rule 24 §Camada-1):** This phase MUST NOT be inlined, simulated,\n> or omitted. The LLM MUST prepend the populated YAML frontmatter to the review artifact.\n> Absent frontmatter is detected by `audit-review-frontmatter.sh` (Layer 3 CI) and the Stop\n> hook (Layer 2 runtime). There is no fallback when frontmatter emission fails.\n\nTaskCreate(\n  subject: \"\u003CSTORY_ID> › Phase 5 › Emit specialist review frontmatter\",\n  activeForm: \"Emitting specialist review frontmatter\",\n  metadata: {\n    \"phase\": \"Phase 5\",\n    \"parentSkill\": \"x-review-codebase\",\n    \"storyId\": \"\u003CSTORY_ID>\",\n    \"epicId\": \"\u003CEPIC_ID>\",\n    \"expectedArtifacts\": [\"\u003Cpath to review-story-XXXX-YYYY.md>\"]\n  }\n)\n\nInvoke pre-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode pre --phase 'Phase 5' --skill x-review-codebase\")\n\nAfter all specialist subagents have returned findings and the prose body of\n`review-story-\u003CSTORY_ID>.md` has been assembled, prepend the YAML frontmatter block\nconforming to `governance\u002Fschemas\u002Freview-frontmatter-1.0.json`:\n\n```\n\u003C!-- template-version: 1.0 -->\n---\nschema-version: \"1.0\"\ngenerated-by: x-review-codebase@\u003Cgit rev-parse HEAD>\nstory-id: \u003CSTORY_ID>\nepic-id: \u003CEPIC_ID>\ndate: \u003Cdate -u +%Y-%m-%dT%H:%M:%SZ>\ndecision: \u003CGO|NO-GO|GO-WITH-RESERVATIONS>\nscore: \u003Csum of specialist scores>\nscore-max: 50\nseverity-counts:\n  critical: \u003Ccount>\n  high: \u003Ccount>\n  medium: \u003Ccount>\n  low: \u003Ccount>\n  info: \u003Ccount>\nblocking-findings:\n\u003CYAML list of critical\u002Fhigh findings, empty list [] if none>\nreviewers:\n\u003CYAML list of invoked specialist roles>\n---\n# Specialist Review — \u003CSTORY_ID>\n...existing prose body...\n```\n\n**Decision consolidation rule:** NO-GO > GO-WITH-RESERVATIONS > GO. If any specialist\nreturned NO-GO → `decision: \"NO-GO\"`. If any returned GO-WITH-RESERVATIONS (and no NO-GO)\n→ `decision: \"GO-WITH-RESERVATIONS\"`. Otherwise → `decision: \"GO\"`.\n\nAfter writing the artifact, validate:\n\n    Bash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fscripts\u002Faudit-review-frontmatter.sh --story \u003CSTORY_ID>`\n\nIf the script returns exit ≠ 0, abort with `REVIEW_FRONTMATTER_INVALID`. No fallback.\n\nInvoke post-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-verify-phase-gates\", model: \"haiku\", args: \"--mode post --phase 'Phase 5' --skill x-review-codebase --expected-artifacts \u003Cpath to review-story-XXXX-YYYY.md>\")\n\nTaskUpdate(taskId: \u003Cid from TaskCreate above>, status: \"completed\")\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-review-codebase Phase-5-Frontmatter ok`\n\n## Phase 5 -- Emit Frontmatter (MANDATORY -- Rule 24 §Camada-1)\n\n\u003C!-- TELEMETRY: phase.start -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh start x-review Phase-5-Frontmatter`\n\n> **MANDATORY TOOL CALL (Rule 24 §Camada-1):** This phase MUST NOT be inlined, simulated,\n> or omitted. The LLM MUST prepend the populated YAML frontmatter to the review artifact.\n> Absent frontmatter is detected by `audit-review-frontmatter.sh` (Layer 3 CI) and the Stop\n> hook (Layer 2 runtime). There is no fallback when frontmatter emission fails.\n\nTaskCreate(\n  subject: \"\u003CSTORY_ID> › Phase 5 › Emit specialist review frontmatter\",\n  activeForm: \"Emitting specialist review frontmatter\",\n  metadata: {\n    \"phase\": \"Phase 5\",\n    \"parentSkill\": \"x-review\",\n    \"storyId\": \"\u003CSTORY_ID>\",\n    \"epicId\": \"\u003CEPIC_ID>\",\n    \"expectedArtifacts\": [\"\u003Cpath to review-story-XXXX-YYYY.md>\"]\n  }\n)\n\nInvoke pre-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-phase-gate\", model: \"haiku\", args: \"--mode pre --phase 'Phase 5' --skill x-review\")\n\nAfter all specialist subagents have returned findings and the prose body of\n`review-story-\u003CSTORY_ID>.md` has been assembled, prepend the YAML frontmatter block\nconforming to `governance\u002Fschemas\u002Freview-frontmatter-1.0.json`:\n\n```\n\u003C!-- template-version: 1.0 -->\n---\nschema-version: \"1.0\"\ngenerated-by: x-review@\u003Cgit rev-parse HEAD>\nstory-id: \u003CSTORY_ID>\nepic-id: \u003CEPIC_ID>\ndate: \u003Cdate -u +%Y-%m-%dT%H:%M:%SZ>\ndecision: \u003CGO|NO-GO|GO-WITH-RESERVATIONS>\nscore: \u003Csum of specialist scores>\nscore-max: 50\nseverity-counts:\n  critical: \u003Ccount>\n  high: \u003Ccount>\n  medium: \u003Ccount>\n  low: \u003Ccount>\n  info: \u003Ccount>\nblocking-findings:\n\u003CYAML list of critical\u002Fhigh findings, empty list [] if none>\nreviewers:\n\u003CYAML list of invoked specialist roles>\n---\n# Specialist Review — \u003CSTORY_ID>\n...existing prose body...\n```\n\n**Decision consolidation rule:** NO-GO > GO-WITH-RESERVATIONS > GO. If any specialist\nreturned NO-GO → `decision: \"NO-GO\"`. If any returned GO-WITH-RESERVATIONS (and no NO-GO)\n→ `decision: \"GO-WITH-RESERVATIONS\"`. Otherwise → `decision: \"GO\"`.\n\nAfter writing the artifact, validate:\n\n    Bash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fscripts\u002Faudit-review-frontmatter.sh --story \u003CSTORY_ID>`\n\nIf the script returns exit ≠ 0, abort with `REVIEW_FRONTMATTER_INVALID`. No fallback.\n\nInvoke post-gate (Rule 25 §Invariants 4):\n\n    Skill(skill: \"x-internal-phase-gate\", model: \"haiku\", args: \"--mode post --phase 'Phase 5' --skill x-review --expected-artifacts \u003Cpath to review-story-XXXX-YYYY.md>\")\n\nTaskUpdate(taskId: \u003Cid from TaskCreate above>, status: \"completed\")\n\n\u003C!-- TELEMETRY: phase.end -->\nBash command: `$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ftelemetry-phase.sh end x-review Phase-5-Frontmatter ok`\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| No changes found relative to main | Abort with message: `No changes found relative to main.` |\n| Skill returns invalid output (missing SCORE or STATUS) | Mark specialist as `FAILED`, score 0, continue with remaining specialists |\n| Dashboard template not found | Log warning, skip dashboard generation, continue to next phase |\n| Remediation template not found | Log warning, skip remediation tracking generation, continue |\n| All specialists return FAILED | Overall status `REJECTED`, report saved with 0 scores |\n\n## Template Fallback\n\nTemplates referenced by this skill follow RULE-012. When a template file does not exist (e.g., pre-EPIC-0024 projects), the skill degrades gracefully:\n\n- `_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md` -- dashboard generation skipped\n- `_TEMPLATE-REVIEW-REMEDIATION.md` -- remediation tracking skipped\n\nWhen templates are absent, dashboard\u002Fremediation are skipped.\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n|-------|-------------|---------|\n| `x-implement-story` | Called by (Phase 4) | Produces the same artifacts as lifecycle Phase 4 |\n| `x-review-pr` | Followed by | Recommended flow: `\u002Fx-review-codebase` then fix criticals then `\u002Fx-review-pr` |\n| `x-story-create` | Reads format | Correction stories (Phase 4) follow the story template |\n| `x-implement-task` | Followed by | Correction stories can be picked up by `\u002Fx-implement-task` |\n| `_TEMPLATE-CONSOLIDATED-REVIEW-DASHBOARD.md` | Reads | Dashboard format, cumulative across rounds (RULE-006) |\n| `_TEMPLATE-REVIEW-REMEDIATION.md` | Reads | Remediation tracking format |\n| `PlanTemplatesAssembler` | Depends on | Templates copied verbatim -- not rendered by the engine |\n",{"name":5,"model":24,"description":7,"allowed-tools":25,"argument-hint":26,"context-budget":27,"fragment-slots":28,"user-invocable":32,"requires-capabilities":33},"sonnet","Read, Write, Edit, Bash, Grep, Glob, Skill, TaskCreate, TaskUpdate","[STORY-ID or --scope reviewer1,reviewer2] [--no-auto-fix-story]","heavy",[29],{"slot":30,"ordering":31},"review-specialist","fragment-order",true,[],"main","952a630c6f38d193a349d86fa18db1de8843e837","src\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase",1,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment","https:\u002F\u002Fgithub.com\u002Freview-bench","https:\u002F\u002Freview-bench.ai","An open benchmark for AI code review.","2026-10-27 06:56:37",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":32},[45,48,51],{"tool":46,"command":47},"npx","npx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-review-codebase",{"tool":49,"command":50},"bunx","bunx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-review-codebase",{"tool":52,"command":53},"pnpm","pnpm dlx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-review-codebase","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002FSKILL.md",[56,62,66,70,74,78,82,86,90,94],{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"fragments\u002Fapi.md","REFERENCE","参考文档",928,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fapi.md",{"path":63,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":64,"sourceHtmlUrl":65},"fragments\u002Fcompliance.md",820,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fcompliance.md",{"path":67,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":68,"sourceHtmlUrl":69},"fragments\u002Fdb.md",812,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fdb.md",{"path":71,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":72,"sourceHtmlUrl":73},"fragments\u002Fdevops.md",876,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fdevops.md",{"path":75,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":76,"sourceHtmlUrl":77},"fragments\u002Fevent.md",863,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fevent.md",{"path":79,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":80,"sourceHtmlUrl":81},"fragments\u002Fperf.md",706,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fperf.md",{"path":83,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":84,"sourceHtmlUrl":85},"fragments\u002Fqa.md",654,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fqa.md",{"path":87,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":88,"sourceHtmlUrl":89},"fragments\u002Fsecurity.md",696,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Ffragments\u002Fsecurity.md",{"path":91,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":92,"sourceHtmlUrl":93},"README.md",5778,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002FREADME.md",{"path":95,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fcomposition-architecture.md",1247,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-review-codebase\u002Freferences\u002Fcomposition-architecture.md",[99,106,113,120,127,134],{"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":105,"publishedAt":19},"01M757M8J48TQ1Y3X25GSJBXAS","x-parallel-eval","Detects and classifies file-collision risks between work units (tasks, stories, or epic phases) before parallel execution. Reads ## File Footprint blocks produced by x-task-plan \u002F x-story-plan, applies the parallelism-heuristics knowledge pack (hard \u002F regen \u002F soft categories + hotspot overrides), and emits a collision matrix + serialization recommendation in Markdown (default) or JSON.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fx-parallel-eval\u002FSKILL.md",[],[],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":19},"01M757M57XMR9546S69466HDWT","parallelism-heuristics","Canonical catalog of file-collision heuristics for parallel task, story, and epic execution. Defines the File Footprint block format, the three Conflict Categories (hard \u002F regen \u002F soft), a hotspot list of high-contention paths, and the degrade-with-warning policy. Consumed by x-task-plan, x-story-plan, x-epic-map, x-parallel-eval, and x-dev-*-implement.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fparallelism-heuristics\u002FSKILL.md",[],[],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":19},"01M757M11SZ8P1VCQABT08QVYA","x-watch-pr-ci","Polls a PR's CI checks and Copilot review status, blocking until checks complete or timeout. Returns one of 8 stable exit codes (SUCCESS=0, CI_PENDING_PROCEED=10, CI_FAILED=20, TIMEOUT=30, PR_ALREADY_MERGED=40, NO_CI_CONFIGURED=50, PR_CLOSED=60, PR_NOT_FOUND=70). Writes a versioned state-file for session resume.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-watch-pr-ci\u002FSKILL.md",[],[],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":19},"01M757KW53K8KFPGADFB4PH949","x-validate-docs","Documentation freshness gate: validates 6 dimensions (readme, api-specs, grpc-proto, adr, skill-docs, system-architecture) against code changes in a PR. Stack-aware — only validates targets declared\u002Fauto-detected from ProjectConfig.documentation.targets. Returns exit non-zero on staleness; produces structured report.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-validate-docs\u002FSKILL.md",[],[],{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":19},"01M757KQZHSA10MKC0CR571D60","x-update-system-architecture","Incrementally updates docs\u002Farchitecture\u002Fsystem.md after an epic completes. Appends new entries to the Decision Log (§11) using x-internal-write-report --append (dedup by ## ID: marker) and surgically inserts component\u002Fintegration changes into sections 1-10 via Edit. Idempotent: re-running with the same epic produces a byte-identical system.md.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-system-architecture\u002FSKILL.md",[],[],{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":19},"01M757KKBT5Q1SVF8DMJBVF46M","x-update-architecture","Incrementally updates the service architecture document with changes from architecture plans. Adds new components, integrations, flows, and ADR references without rewriting existing content. Use after implementation to keep architecture documentation current.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-architecture\u002FSKILL.md",[],[]]