Update to Matt Skills Curated

{
  "description": "Build a throwaway prototype to answer a specific design, state model, or UI exploration question. Use when evaluating whether an interface feels right, exploring UI concepts, or testing logic before committing to a full spec — even if the user says \"mock this up\". Do NOT use for production implementation.",
  "included_files": [
    {
      "relative_path": "LOGIC.md",
      "size_in_bytes": 6036
    },
    {
      "relative_path": "UI.md",
      "size_in_bytes": 6913
    },
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 100
    }
  ],
  "name": "prototype",
  "skill_md_contents": "---\nname: prototype\ndescription: \"Build a throwaway prototype to answer a specific design, state model, or UI exploration question. Use when evaluating whether an interface feels right, exploring UI concepts, or testing logic before committing to a full spec — even if the user says \\\"mock this up\\\". Do NOT use for production implementation.\"\n---\n\n# Prototype\n\nBuild throwaway exploratory code designed to answer a single load-bearing architectural, state machine, or UI question rapidly without production overhead.\n\n---\n\n## Core Invariants\n\n1. **Throwaway By Construction**: Prototypes must be explicitly marked throwaway with zero production persistence or abstraction overhead.\n2. **Branch Isolation**: Separate logic/state-machine prototypes (`LOGIC.md`) from visual UI variant explorations (`UI.md`).\n3. **Single-Command Launch**: UI prototypes run with one command (`pnpm dev`, `bun run ...`); logic prototypes are single double-clickable HTML/JS files.\n4. **Transparent State Exposure**: Every action or transition must visually expose the complete underlying state payload.\n5. **Decisions-Only Mainline Merge**: Merge only the validated decision/type into main; commit the prototype code to a separate scratch branch.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Load-Bearing Design Question ] ──► [ Select Exploration Branch ] ──► [ Minimal Runnable Prototype ] ──► [ Extract Settled Decision ]\n                                                 │\n                        ┌────────────────────────┴────────────────────────┐\n                        ▼                                                 ▼\n             [ Logic / State Prototype ]                         [ UI Variant Explorer ]\n             - Single HTML/JS file                               - Multi-variant route\n             - Free-play + guided tabs                           - Bottom floating bar\n             - Full state visualizer                             - URL parameter toggle\n```\n\n| Branch | Question Answered | Artifact Format |\n|---|---|---|\n| **Logic / State** | \"Does this state machine or business rule feel right?\" | `skills/prototype/LOGIC.md` |\n| **UI Variations** | \"What should this visual interaction look like?\" | `skills/prototype/UI.md` |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Identify the Question & Exploration Branch\n- **Action**: Determine whether the core uncertainty is logical/stateful or visual/experiential.\n- **Key Point**: Check if the component has complex transition states (choose Logic) or styling/layout decisions (choose UI).\n- **Why**: Choosing the wrong format wastes time building UI for logical edge cases or state machines for static layouts.\n\n### Step 2: Implement the Minimal Runnable Prototype\n- **Action**: Create the prototype with zero database persistence and minimal abstractions:\n  - Logic: Self-contained HTML with state buttons, transition logs, and guided walkthrough scenarios.\n  - UI: Dedicated scratch route with 2–4 radically different variants toggled via query params.\n- **Inline Checklist**:\n  - [ ] Marked as throwaway in filenames and comments\n  - [ ] Launches via single standard command or browser click\n  - [ ] Displays live internal state on every interaction\n\n### Step 3: Interactive Evaluation & Decision Extraction\n- **Action**: Walk the user through the prototype to evaluate edge cases and record the verdict.\n- **Key Point**: Extract the validated data shape, state machine reducer, or component layout into the issue tracker or spec.\n- **Why**: Capturing the distilled finding prevents throwaway prototype code from accidentally morphing into production spaghetti.\n\n### Step 4: Archive Prototype & Clean Main\n- **Action**: Commit the prototype to a scratch branch (`prototype/<name>`), link it in the ticket, and keep `main` clean.\n- **Key Point**: Never merge un-linted prototype hacks directly into main branches.\n- **Why**: Strict separation keeps the main codebase pristine while retaining historical design context.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"Let's build this prototype directly inside the main production file.\"* | **Forbidden. Keep prototypes in isolated scratch paths.** | Inlining prototypes into production code creates accidental dependencies and tech debt. |\n| *\"Add full unit tests and error handling to the prototype.\"* | **Skip production hardening in throwaway prototypes.** | Hardening exploratory code slows learning cycles and creates emotional attachment. |\n| *\"Merge the entire prototype into main since it works.\"* | **Extract decisions only; archive prototype branch.** | Prototypes lack production safety, validation, error boundaries, and documentation. |\n\n"
}