Update to Matt Skills Curated

{
  "description": "Interview the user relentlessly to sharpen an idea, requirement, or decision before execution. Use when a plan, design, requirement, or decision needs a focused interview to expose ambiguity, missing constraints, trade-offs, or weak assumptions — even if the user just says \"grill me on this\". Do NOT use for repo-stateful domain modeling with doc generation.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 94
    }
  ],
  "name": "grill-me",
  "skill_md_contents": "---\nname: grill-me\ndescription: \"Interview the user relentlessly to sharpen an idea, requirement, or decision before execution. Use when a plan, design, requirement, or decision needs a focused interview to expose ambiguity, missing constraints, trade-offs, or weak assumptions — even if the user just says \\\"grill me on this\\\". Do NOT use for repo-stateful domain modeling with doc generation.\"\n---\n\n# Grill Me\n\nConduct a focused, relentless Socratic interview to stress-test a plan, architectural decision, requirement, or nascent concept before writing code.\n\n---\n\n## Core Invariants\n\n1. **Relentless Frontier Exploration**: Model the design space as a decision tree and exhaust the frontier before declaring alignment.\n2. **One Question Round per Turn**: Batch questions into structured frontier rounds with recommended defaults; never interrogate with one-off dribble.\n3. **Autonomous Fact Extraction**: Retrieve codebase, system, and file facts autonomously; never ask the user what the environment can reveal.\n4. **Active Assumption Invalidation**: Proactively challenge comfortable assumptions, scale bottlenecks, edge-case failure modes, and hidden dependencies.\n5. **No Premature Implementation**: Refuse to write production code or tickets until the interview frontier is completely empty and mutually agreed.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Nascent Idea / Unsettled Decision ] ──► [ Autonomous Codebase Recon ] ──► [ Frontier Question Round ] ──► [ Socratic Refinement ] ──► [ Settled Alignment ]\n```\n\n| Component | Responsibility | Reference / Target |\n|---|---|---|\n| **Autonomous Recon** | Read repo context, ADRs, schemas | Primary source files |\n| **Frontier Tree** | Map open decision nodes & prerequisites | `skills/grilling/SKILL.md` |\n| **Question Round** | Formatted numbered prompts + defaults | User interaction loop |\n| **Settled Alignment** | Clean, unambiguous problem/solution contract | Handoff to `to-spec` |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Autonomous Reconnaissance & Context Gathering\n- **Action**: Inspect relevant codebase files, configurations, documentation, and existing architectural decisions before drafting questions.\n- **Key Point**: Form a grounded mental model of existing constraints without asking the user for baseline facts.\n- **Why**: Asking users for facts available in the repository wastes their cognitive bandwidth and damages credibility.\n\n### Step 2: Formulate Frontier Question Rounds\n- **Action**: Identify all open decisions whose prerequisites are settled and present them in a single batch with explicit recommendations.\n- **Key Point**: Format each question as `❓ **Q[N]** - **[Title]**:` with options and `➡️ [Recommended Default]`.\n- **Why**: Presenting strong recommendations lowers decision fatigue while forcing the user to actively affirm or override specific choices.\n- **Inline Checklist**:\n  - [ ] Every question targets a genuine decision rather than an environmental fact\n  - [ ] Questions are independent and can be answered in parallel\n  - [ ] Concrete recommendation provided for every question\n  - [ ] No implementation code started\n\n### Step 3: Iterate and Deepen the Decision Tree\n- **Action**: Ingest user answers, collapse resolved nodes, uncover new downstream branches, and issue the next frontier round.\n- **Key Point**: Probe edge cases: failure modes, security boundaries, migration paths, and non-happy paths.\n- **Why**: Most architectural failures occur at boundaries that initial proposals casually gloss over.\n\n### Step 4: Verify Alignment and Closure\n- **Action**: Summarize the unified decision contract and ask for explicit user confirmation.\n- **Key Point**: Confirm that the frontier is empty and zero unexamined assumptions remain.\n- **Why**: Clear alignment prevents costly rewrites during implementation.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"The user's initial prompt looks clear enough, let's start coding.\"* | **Mandatory grilling on all non-trivial plans.** | Initial prompts almost always conceal edge-case ambiguities and conflicting constraints. |\n| *\"I'll ask questions one by one across multiple back-and-forth turns.\"* | **Batch the entire frontier into numbered rounds.** | Single-question ping-pong creates conversational fatigue and fragments context. |\n| *\"Ask the user which database schema or library version is used.\"* | **Discover environment facts autonomously.** | Agents must look up facts directly in code and configs rather than burdening the user. |\n| *\"Agree with the user's preferred approach without challenging trade-offs.\"* | **Stress-test every critical design decision.** | Sycophancy allows architectural bugs and scaling bottlenecks to slip into production. |\n\n"
}