Update to Matt Skills Curated

{
  "description": "Decompose an approved specification or plan into ordered, dependency-linked tracer-bullet implementation tickets. Use when turning a spec or architectural plan into actionable tracker issues with clear acceptance criteria — even if the user says \"break this into tickets\". Do NOT use for initial requirements gathering.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 103
    }
  ],
  "name": "to-tickets",
  "skill_md_contents": "---\nname: to-tickets\ndescription: \"Decompose an approved specification or plan into ordered, dependency-linked tracer-bullet implementation tickets. Use when turning a spec or architectural plan into actionable tracker issues with clear acceptance criteria — even if the user says \\\"break this into tickets\\\". Do NOT use for initial requirements gathering.\"\n---\n\n# To Tickets\n\nDecompose an approved specification, plan, or design document into vertically sliced, dependency-ordered tracer-bullet implementation tickets with explicit acceptance criteria.\n\n---\n\n## Core Invariants\n\n1. **Strict Vertical Tracer Slicing**: Every standard ticket must cut vertically across all necessary layers (schema, domain logic, API, UI, test) rather than horizontal slices of a single layer.\n2. **Explicit Dependency DAG**: Every ticket must explicitly declare its blocking prerequisites (`Blocked by:`) to form an unambiguous directed acyclic graph.\n3. **Single Context-Window Sizing**: Each ticket must be sized to complete within a single agent context window without exhausting token or tool limits.\n4. **Expand-Contract for Wide Refactors**: Wide architectural refactors with broad blast radius must follow the Expand-Contract pattern rather than being forced into fragile single-step vertical slices.\n5. **No Parent Mutation**: Never close, resolve, or corrupt parent tracker issues when authoring and publishing child tickets.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Approved Spec / Plan ] ──► [ DAG Dependency Decomposition ] ──► [ User Granularity Review ] ──► [ Atomic Tracker Publication ]\n                                            │\n               ┌────────────────────────────┴────────────────────────────┐\n               ▼                                                         ▼\n    [ Vertical Tracer Bullets ]                               [ Expand-Contract Migrations ]\n    - Narrow cross-layer path                                 - Expand (add new form beside old)\n    - Independently verifiable                                - Migrate in localized batches\n    - Fit in 1 context window                                 - Contract (delete old form)\n```\n\n| Component | Responsibility | Output Target |\n|---|---|---|\n| **Local Ticket Store** | Atomic Markdown ticket files | `.scratch/<feature-slug>/issues/NN-<slug>.md` |\n| **Tracker Issues** | Remote issue creation with blocking metadata | GitHub, Linear, GitLab issues |\n| **Prefactoring Gate** | Make the change easy before making the easy change | Dedicated blocker ticket #01 |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Context Ingestion & Prefactoring Identification\n- **Action**: Ingest the approved spec and inspect the target codebase area to identify necessary prefactoring.\n- **Key Point**: If the existing code makes the target change difficult, create a dedicated preparatory refactor ticket as the first blocker.\n- **Why**: \"Make the change easy, then make the easy change\" prevents intertwining architectural cleanup with functional feature additions.\n\n### Step 2: Slice Vertical Tracer Bullets & Formulate DAG\n- **Action**: Break the feature into vertical tracer slices and link dependencies:\n  - For standard features: Vertical slices cutting through schema, API, UI, and tests.\n  - For wide refactors: Sequence as Expand $\\rightarrow$ Batch Migration $\\rightarrow$ Contract.\n- **Key Point**: Assign each ticket an unambiguous \"Blocked by\" list. Tickets with no blockers are ready for immediate execution.\n- **Inline Checklist**:\n  - [ ] Every vertical slice delivers an independently verifiable behavior\n  - [ ] Wide refactors partitioned via expand-contract\n  - [ ] Tickets strictly fit in a single fresh context window\n  - [ ] Acceptance criteria are binary and testable\n\n### Step 3: Present Breakdown & Quiz User for Approval\n- **Action**: Present the proposed tickets with titles, blockers, and deliverables to the user.\n- **Key Point**: Prompt the user to verify granularity, dependencies, and ordering.\n- **Why**: Quick human validation ensures ticket sizing matches team velocity and avoids execution roadblocks.\n\n### Step 4: Publish to Tracker\n- **Action**: Publish approved tickets in topological order (blockers first) to the configured issue tracker or `.scratch/<feature-slug>/issues/NN-<slug>.md`.\n- **Key Point**: Apply the `ready-for-agent` triage label to all unblocked tickets.\n- **Why**: Topological creation ensures downstream tickets can cleanly reference live upstream ticket IDs.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"I'll create horizontal tickets: 1 for DB, 1 for backend, 1 for UI.\"* | **Forbidden. Enforce vertical tracer slices.** | Horizontal layers cannot be verified end-to-end and leave systems broken across commits. |\n| *\"This ticket is huge, but one agent can manage it.\"* | **Split tickets exceeding 1 context window.** | Oversized tickets cause context exhaustion, lost requirements, and hallucinations. |\n| *\"Combine the preparatory refactor with the new feature logic.\"* | **Separate prefactoring into a distinct ticket.** | Mixing refactoring with feature delivery obscures regressions in code review. |\n| *\"Skip writing acceptance criteria since the spec has them.\"* | **Mandatory atomic acceptance checklist per ticket.** | Implementer agents require self-contained verification criteria without re-reading the spec. |\n\n"
}