Update to Matt Skills Curated

{
  "description": "Build scoped code changes and run verification from an approved specification or plan. Use when a concrete spec, approved plan, or set of tickets is ready to implement, when the user asks to build or code a planned feature, or when executing tasks — even if they don't explicitly say \"implement\". Do NOT use for initial architecture exploration or vague requirements.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 96
    }
  ],
  "name": "implement",
  "skill_md_contents": "---\nname: implement\ndescription: \"Build scoped code changes and run verification from an approved specification or plan. Use when a concrete spec, approved plan, or set of tickets is ready to implement, when the user asks to build or code a planned feature, or when executing tasks — even if they don't explicitly say \\\"implement\\\". Do NOT use for initial architecture exploration or vague requirements.\"\n---\n\n# Implement\n\nExecute scoped code changes and thorough verification from an approved specification, plan, or ticket set.\n\n## Core Principle\n\n> **Implement incrementally via vertical tracer slices, verify at each step, and maintain a green build at every seam.**\n\n---\n\n## Core Invariants\n\n1. **Approved Plan or Spec First**: Never start broad implementation on ambiguous or unapproved specs.\n2. **Vertical Slice Progress**: Implement in small, testable tracer slices rather than mass horizontal file edits.\n3. **Continuous Typecheck & Test Verification**: Run local typechecks and single test files after every file modification, and the full suite before completion.\n4. **Pre-Commit Quality Gate**: Pass clean code review (`code-review`) and lint checks before committing.\n5. **Zero Dead or Speculative Code**: Write strictly the code required to satisfy the spec; avoid speculative abstractions.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Review Approved Spec ] ──► [ Order Tracer Slices ] ──► [ TDD Cycle per Slice ] ──► [ Full Suite Verification ] ──► [ Code Review & Commit ]\n```\n\n| Phase | Responsibility | Key Action |\n|---|---|---|\n| **1. Preparation** | Read spec, identify dependencies, check existing test seams | Verify repo builds cleanly before touching code |\n| **2. Tracer Execution** | Implement slice-by-slice with TDD | Red-green cycles on target components |\n| **3. Continuous Check** | Fast feedback on type errors and single tests | Run targeted test runner after each edit |\n| **4. Integration Gate** | End-to-end regression validation | Full test suite, linter, and typecheck pass |\n| **5. Delivery** | Review diff against standards and spec | Route to `code-review` and clean commit |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Ingest Spec & Verify Baseline Cleanliness\n- **Action**: Read the spec or ticket descriptions, inspect referenced files, and verify the existing test suite passes cleanly.\n- **Key Point**: Never begin adding new features to a broken or failing baseline.\n- **Why**: Existing failures confound regression detection for new changes.\n\n### Step 2: Implement via Vertical Slices (TDD)\n- **Action**: For each ticket or component, write failing assertions at public seams, then implement minimal passing logic.\n- **Key Point**: Keep edits contained and avoid touching unrelated modules.\n- **Inline Checklist**:\n  - [ ] Public seam identified and tested\n  - [ ] Typecheck passes without errors\n  - [ ] Targeted test passes cleanly\n\n### Step 3: Full Test Suite & Quality Verification\n- **Action**: Run the complete project test suite, typechecker, and linter across the entire repository.\n- **Key Point**: Zero failures, zero unexpected warnings, zero unformatted files.\n- **Why**: Changes in one module can subtly break downstream consumers.\n\n### Step 4: Code Review & Final Commit\n- **Action**: Audit the git diff against repository coding standards and original requirements using `code-review`.\n- **Key Point**: Write a clear, value-communicating commit message summarizing the change.\n- **Why**: Durable commit histories preserve architectural reasoning for future maintainers.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"I'll edit all 10 files at once before testing anything.\"* | **Vertical tracer slicing: verify each file/unit immediately.** | Massive multi-file edits make errors difficult to isolate and debug. |\n| *\"Typechecks are slow, I'll run them at the very end.\"* | **Run fast targeted checks continuously.** | Catching type errors early prevents building on flawed data signatures. |\n| *\"The existing test suite was failing before, so ignore it.\"* | **Establish clean baseline before modifying code.** | Unaccounted failures hide new regressions introduced by the feature. |\n| *\"Skip code review since the code runs fine.\"* | **Mandatory diff review against spec and standards.** | Functional code can still violate repository conventions and security standards. |\n"
}