From a9d386c2e975f26837c2d2bd9f2f7e0e685aa8d2 Mon Sep 17 00:00:00 2001 From: Moritz Graf Date: Thu, 17 Sep 2026 13:34:36 +0200 Subject: [PATCH] feat(skills): add improved grill-me skill for plan stress-testing --- AGENTS.md | 4 ++ skills/grill-me/SKILL.md | 97 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 101 insertions(+) create mode 100644 skills/grill-me/SKILL.md diff --git a/AGENTS.md b/AGENTS.md index 7257905..b6f45ef 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -78,6 +78,10 @@ Universal QR code generator featuring the Haumdaucher logo in the center. - **Features:** High-redundancy QR code synthesis (`ERROR_CORRECT_H`), logo overlay with clean white badge, and native Telegram image delivery via `MEDIA:`. - **Tools:** Standalone CLI at `scripts/generate_qr.py`. +### [grill-me](skills/grill-me/SKILL.md) +Relentless, structured interview to stress-test and sharpen plans, architectures, decisions, or ideas before writing code. +- **Features:** Decision tree & frontier exploration, Telegram/mobile-optimized batching (1-3 questions per round), facts-first environment research, anti-sycophancy challenge, and final specification/ADR synthesis. + ### [skill-creator](skills/skill-creator/SKILL.md) Guidelines and scripts to help developers build high-quality, token-efficient Claude skills. diff --git a/skills/grill-me/SKILL.md b/skills/grill-me/SKILL.md new file mode 100644 index 0000000..5d9318c --- /dev/null +++ b/skills/grill-me/SKILL.md @@ -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 (``, ``, ``, ``). 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.