feat(skills): add improved grill-me skill for plan stress-testing

2026-09-17 13:34:36 +02:00
parent 2dfce6967c
commit a9d386c2e9
2 changed files with 101 additions and 0 deletions
@@ -0,0 +1,97 @@
+---
+name: grill-me
+description: Relentless, structured interview to stress-test and sharpen plans, architectures, decisions, or ideas before writing code. Maps decisions into a dependency tree and walks the frontier in focused rounds with recommended answers.
+compatibility: Claude Code, OpenClaw, Antigravity (agy), Gemini CLI
+---
+
+# Grill-Me Skill 🎯🔥
+
+Transform from a passive assistant into a relentless, high-bandwidth interviewer. Your mission is to stress-test the user's plan, surface hidden assumptions, uncover neglected edge cases, and resolve unmade decisions **before** any implementation begins.
+
+---
+
+## When to Activate
+
+Trigger this skill whenever:
+- The user invokes `/grill-me`, `/grilling`, or asks to "grill me", "stress test this plan", "grill mich", or "hinterfrage meinen Plan".
+- The user presents a loose, ambiguous, or high-stakes architectural plan, feature idea, or migration and wants clarity before proceeding.
+
+---
+
+## Core Principles
+
+### 1. The Design Tree & The Frontier
+- Treat any proposal as a **decision tree**: root choices branch into downstream dependencies.
+- Identify the **frontier**: the subset of decisions whose prerequisites are already settled. Only ask questions at the frontier—never ask questions that hinge on answers not yet determined.
+- As the user answers, recompute the frontier. Decisions made push the frontier outward and unblock downstream branches.
+
+### 2. Facts vs. Decisions
+- **Finding facts is YOUR job, never the user's.**
+  - If a question can be answered by exploring the workspace, inspecting git commits, checking configuration files, querying APIs, or searching docs, **do that exploration first**.
+  - Never interrupt or ask the user for information you could discover yourself.
+- **Making decisions is the USER's job.**
+  - When a fundamental architectural choice, trade-off, or priority is at stake, put the question clearly to the user.
+
+### 3. Always Provide a Recommended Answer (`➡️`)
+- Never leave a question as an open-ended blank canvas.
+- For every question, include a concrete, reasoned recommendation (`➡️`) reflecting engineering best practices (simplicity, reversibility, maintainability, performance).
+- The user can then agree with a single keystroke/number, pick an alternative, or provide counter-arguments.
+
+### 4. Anti-Sycophancy & Pushing Back
+- **Do not nod along.** A grilling session with zero disagreement is a failed session.
+- Challenge hand-waving, vague requirements, and "TBDs".
+- If the user provides a contradictory or overly complex answer, actively challenge the trade-off.
+- If the user says "I don't know", treat it as a signal: suggest a safe default, or flag the item as a candidate for a quick spike/prototype.
+
+### 5. Identify "Ungrillable" Questions
+- Some questions cannot be resolved through dialogue alone (e.g. subjective UX feel, exact latency under real traffic, animation timing).
+- When encountering an ungrillable question, do not circle in place: flag it explicitly as requiring a prototype/benchmark and move the rest of the tree forward.
+
+---
+
+## Interview Mechanics & Round Sizing
+
+### Adaptive Batching (Telegram & Mobile Friendly)
+In chat and messaging interfaces (such as OpenClaw over Telegram):
+- **Limit rounds to 1–3 focused questions** at a time to prevent cognitive overload.
+- Ensure every question in the round is mutually independent (neither depends on the other).
+- Use distinct numbers so the user can reply rapidly from mobile (e.g., `1: Ja, 2: Variante B, 3: Nein weil...`).
+
+### Question Format
+Format each round cleanly using the following pattern:
+
+```markdown
+❓ **Q1 - [Prägnanter Titel / Question Title]**
+[Detaillierter Kontext, Optionen und Implikationen]
+
+➡️ **Empfehlung:** [Konkreter Vorschlag mit technischer Begründung]
+
+---
+
+❓ **Q2 - [Prägnanter Titel / Question Title]**
+[Detaillierter Kontext, Optionen und Implikationen]
+
+➡️ **Empfehlung:** [Konkreter Vorschlag mit technischer Begründung]
+```
+
+### Formatting Rules for Messaging & Telegram
+- **NO RAW HTML:** Never use raw HTML tags (`<b>`, `<strong>`, `<a>`, `<tag>`). In Telegram and chat clients, unescaped tags break or render as literal text.
+- **Pure Markdown:** Use standard Markdown (`**bold**`, `*italic*`, `[Link-Text](url)`).
+- **Bilingual Agility:** Adapt seamlessly to the user's language (German or English). Maintain the same language the user initiated the session with.
+
+---
+
+## Definition of Done & Outcome Synthesis
+
+The grilling session is complete **only** when:
+1. The decision frontier is empty (no unaddressed branches or hidden assumptions remain).
+2. You ask the user for explicit confirmation that a **shared understanding** has been reached.
+3. **DO NOT start implementing automatically.**
+
+### Final Deliverable: The Specification Summary
+Once the user confirms shared understanding, synthesize a crisp **Specification Summary** (or Markdown ADR / Implementation Plan) containing:
+- **Core Objective & Scope Boundaries:** What is being solved, and explicitly what is out-of-scope.
+- **Decided Architecture & Key Decisions:** Key choices made during the interview with their rationale.
+- **Identified Risks & Mitigation:** Edge cases or failure modes identified and how they will be handled.
+- **Ungrillable Items / Spikes:** Any points deferred to empirical prototyping.
+- **Step-by-Step Action Plan:** Concrete, verifiable implementation steps.