Update to Matt Skills Curated

{
  "description": "Relentlessly interview the user round-by-round to stress-test thinking and expose unexamined assumptions. Use when the user requests a grilling interview, wants their idea challenged, or uses trigger phrases like \"grill me\" — even if they just say \"poke holes in my plan\". Do NOT use when the user asks for immediate implementation.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 113
    }
  ],
  "name": "grilling",
  "skill_md_contents": "---\nname: grilling\ndescription: \"Relentlessly interview the user round-by-round to stress-test thinking and expose unexamined assumptions. Use when the user requests a grilling interview, wants their idea challenged, or uses trigger phrases like \\\"grill me\\\" — even if they just say \\\"poke holes in my plan\\\". Do NOT use when the user asks for immediate implementation.\"\n---\n\n# Grilling\n\nRelentlessly stress-test thinking, expose hidden assumptions, and map the design space as an expanding decision tree until mutual understanding is reached.\n\n---\n\n## Core Invariants\n\n1. **Frontier-Based Batched Rounds**: Ask all currently unblocked questions together in a single numbered round; never drip questions one by one.\n2. **Mandatory Concrete Recommendations**: Every question must include a definitive recommended answer (`➡️ [Recommendation]`) to streamline decision-making.\n3. **Autonomous Fact Exploration**: Investigate the codebase, configs, and dependencies with background exploration before asking questions; never query the user for discoverable facts.\n4. **Strict Topological Dependency Ordering**: Questions whose answers depend on open decisions must wait for future rounds; never mix dependent questions into the current frontier.\n5. **Verified Exhaustion Gate**: The interview concludes only when the frontier is completely empty and the user explicitly validates the final consensus.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Problem Space / Initial Proposal ]\n                │\n                ▼\n┌───────────────────────────────────────┐\n│ 1. Compute Decision Frontier Tree     │\n│    (Unblocked questions with defaults)│\n└──────────────────┬────────────────────┘\n                   │\n                   ▼\n┌───────────────────────────────────────┐\n│ 2. Issue Formatted Round (Q1..Qn)     │\n│    (Questions + Strong Recommendations)│\n└──────────────────┬────────────────────┘\n                   │\n                   ▼\n┌───────────────────────────────────────┐\n│ 3. Ingest Answers & Advance Frontier  │\n│    (Prune resolved, unlock downstream)│\n└──────────────────┬────────────────────┘\n                   │\n                   ▼\n┌───────────────────────────────────────┐\n│ 4. Verification & Consensus Handshake │\n└───────────────────────────────────────┘\n```\n\n| Phase | Responsibility | Expected Output |\n|---|---|---|\n| **Frontier Extraction** | Identify independent decision nodes | Filtered list of unblocked questions |\n| **Round Formatting** | Apply standardized Markdown question templates | User-facing numbered interview round |\n| **Downstream Unblocking** | Re-evaluate tree based on user decisions | Updated frontier state |\n| **Consensus Handshake** | Synthesize agreed architecture & requirements | Clean brief ready for specification |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Map the Design Space & Compute Frontier\n- **Action**: Analyze the user's intent, identify all decision nodes, and select only those whose prerequisites are fully settled.\n- **Key Point**: Filter out any question that requires guessing the answer to an unresolved peer question.\n- **Why**: Asking dependent questions simultaneously forces the user into speculative, conditional answers that clutter context.\n\n### Step 2: Format and Dispatch the Question Round\n- **Action**: Present the current frontier using the standardized Markdown question format:\n  ```markdown\n  ❓ **Q1** - **<Question Title>**: <Detailed question body and options>\n\n  ➡️ **Recommendation**: <Specific proposed answer and technical rationale>\n\n  ---\n\n  ❓ **Q2** - **<Question Title>**: <Detailed question body and options>\n\n  ➡️ **Recommendation**: <Specific proposed answer and technical rationale>\n  ```\n- **Key Point**: Keep recommendations opinionated, clear, and grounded in industry best practices.\n- **Inline Checklist**:\n  - [ ] Every question numbered and titled\n  - [ ] Concrete recommendation provided for each question\n  - [ ] No dependent questions included in the same round\n\n### Step 3: Ingest Answers & Advance the Frontier Tree\n- **Action**: Parse user responses, record settled decisions, unlock newly available downstream questions, and generate the next round.\n- **Key Point**: If a user response reveals a new unknown in the codebase, dispatch background exploration immediately to resolve it.\n- **Why**: Real-time background discovery prevents passing factual burdens onto the user.\n\n### Step 4: Verify Alignment and Completion\n- **Action**: Once all branches of the decision tree have been explored and no frontier items remain, present a concise synthesis of all resolved decisions.\n- **Key Point**: Require explicit user confirmation before proceeding to specification or execution.\n- **Why**: Mutual alignment guarantees that the subsequent implementation phase proceeds without friction or false assumptions.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"I'll ask just one question now to see what they say.\"* | **Ask the entire frontier in one turn.** | Drip-feeding questions creates annoying latency and loses the macro structure of the design. |\n| *\"Let the user decide without biasing them with my recommendation.\"* | **Mandatory recommended answer for every question.** | Concrete recommendations speed up review and give users a clear baseline to react against. |\n| *\"Ask the user where configuration files or types are defined.\"* | **Discover environment facts autonomously.** | User interviews are exclusively for product and architectural decisions, not repo search. |\n| *\"The user gave a vague answer, but I can guess what they meant.\"* | **Clarify ambiguous answers immediately.** | Guessing user intent during grilling undermines the entire purpose of stress-testing. |\n\n"
}