Update to Matt Skills Curated

{
  "description": "Review changed code against repository coding standards and original specification intent. Use when reviewing a branch, diff, PR, pull request, merge-base changes, or verifying code against documented standards — even if the user just says \"review this\". Do NOT use for authoring new code or diagnosing failing runtime bugs.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 100
    }
  ],
  "name": "code-review",
  "skill_md_contents": "---\nname: code-review\ndescription: \"Review changed code against repository coding standards and original specification intent. Use when reviewing a branch, diff, PR, pull request, merge-base changes, or verifying code against documented standards — even if the user just says \\\"review this\\\". Do NOT use for authoring new code or diagnosing failing runtime bugs.\"\n---\n\n# Code Review\n\nTwo-axis review of the diff between `HEAD` and a fixed point:\n1. **Standards**: Does the code conform to documented repository standards and clean architecture smells?\n2. **Spec**: Does the code faithfully and completely implement the originating issue/spec without scope creep?\n\nBoth axes execute as isolated parallel sub-agents to prevent context contamination, with findings reported side by side.\n\n---\n\n## Core Invariants\n\n1. **Strict Two-Axis Separation**: Keep Standards and Spec findings isolated; never merge or cross-rank them into a blended score.\n2. **Pinned Merge-Base Diff**: Always resolve refs with `git rev-parse` and review `git diff <fixed-point>...HEAD`.\n3. **Evidence-Based Citations**: Every finding must quote the exact file, line range, and standard/spec clause violated.\n4. **Tooling Non-Duplication**: Skip formatting, syntax, or lint errors that automated pre-commit tooling already catches.\n5. **No Blind Approvals**: If the spec is missing, report \"No spec provided - verified against standards only\" explicitly.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Pin Fixed Point ] ──► [ Identify Spec & Standards ] ──► [ Parallel Review Subagents ] ──► [ Side-by-Side Synthesis ]\n                                                                 │\n                                ┌────────────────────────────────┴────────────────────────────────┐\n                                ▼                                                                 ▼\n                     [ Standards Subagent ]                                              [ Spec Subagent ]\n                     - Documented repo rules                                             - Missing requirements\n                     - Fowler code smells                                                - Unasked scope creep\n                     - Architectural boundaries                                          - Flawed implementations\n```\n\n| Component | Responsibility | Evaluation Source |\n|---|---|---|\n| **Standards Axis** | Architecture smells, naming, cohesion | `CODING_STANDARDS.md`, `CONTRIBUTING.md`, smell baseline |\n| **Spec Axis** | Functional completeness, scope boundaries | Issue description, `specs/*.md`, user requirements |\n| **Aggregation** | Side-by-side balanced reporting | Verbatim findings categorized by axis |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Pin the Fixed Point & Diff\n- **Action**: Resolve the base ref and confirm a non-empty diff (`git diff <base>...HEAD`).\n- **Key Point**: Fail fast if the ref is invalid or the working tree is empty.\n- **Why**: Reviewing against an incorrect base compares irrelevant changes.\n\n### Step 2: Extract Standards and Spec Sources\n- **Action**: Locate repository guidelines (`CODING_STANDARDS.md`) and originating requirements/issues.\n- **Key Point**: Equip the standards agent with Fowler smell baselines (Mysterious Name, Duplicated Code, Feature Envy, Primitive Obsession, Speculative Generality).\n- **Inline Checklist**:\n  - [ ] Diff base confirmed\n  - [ ] Standards docs identified\n  - [ ] Spec/issue requirements extracted\n\n### Step 3: Dispatch Parallel Sub-Agents\n- **Action**: Spawn Standards subagent and Spec subagent concurrently with dedicated prompts.\n- **Key Point**: Restrict each subagent to its designated domain (< 400 words per report).\n- **Why**: Combining standards and spec evaluation into a single pass leads to halo bias where clean code masks missing features.\n\n### Step 4: Aggregate and Synthesize Report\n- **Action**: Present findings under `## Standards` and `## Spec` headers with actionable remediation recommendations.\n- **Key Point**: State the single most severe issue within each axis clearly.\n- **Why**: Clear prioritization helps authors address critical design issues first.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"The code looks beautifully formatted, so it must be correct.\"* | **Standards pass $\\neq$ Spec pass.** | Elegant code can completely fail to implement required business logic. |\n| *\"It does what the ticket asked, so ignore messy architecture.\"* | **Spec pass $\\neq$ Standards pass.** | Quick hacks that bypass standards generate severe technical debt. |\n| *\"Merge both reviews into one combined score.\"* | **Strict two-axis separation.** | Blending scores obscures which dimension requires remediation. |\n| *\"Point out minor indentation issues in the review.\"* | **Skip issues handled by automated linters.** | Manual review should focus on semantics, architecture, and intent. |\n"
}