Menu
Interview the user relentlessly about a plan or design until branch-level decisions are resolved for execution.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Access Figma designs, extract design systems, and retrieve component specifications. Use when implementing UI from Figma mockups, extracting design tokens, or analyzing design files.
Enforce cost-aware MCP usage. Use when a task might trigger heavy external tools, web search, or broad context expansion. Prevents token burn by ensuring MCPs are only used when local context is insufficient.
Navigate the Warmplane mcp0 facade efficiently. Use when the active config exposes provider capabilities through `mcp0_*` tools and you need to discover or call provider tools without brute-force describing large capability sets. Trigger on requests involving mcp0, Warmplane, or provider work through the facade such as Linear, Notion, Figma, New Relic, Context7, grep.app, or Storybook tools.
Use this when the user needs to control Chrome, navigate to a page, inspect a tab, click or fill elements, take screenshots, or automate a browser flow with aeroxy/chrome-devtools-cli.
Guidelines for creating and managing implementation plans with citations
Apply these conventions during planning and implementation from the start (not only after review feedback). Use for frontend and backend changes when deciding whether to add layers, where to place formatting/validation, how much typing to keep, how to place helper files (.dto.ts/.type.ts/.constant.ts/.util.ts), and how to match existing module patterns during /plan and /work.
| name | grill-me |
| description | Interview the user relentlessly about a plan or design until branch-level decisions are resolved for execution. |
Use this skill when a plan/design needs stress-testing or when the user asks to be grilled.
Ask questions until execution-critical branches are actually resolved, not just discussed.
Drive one unresolved branch frontier at a time, and ask a small tightly-coupled set when one question cannot resolve that frontier.
Stay repo-first: if the codebase or saved context answers a branch, resolve it directly and only ask the user for decisions the repo cannot answer.
Keep a clear split between repo-owned branches (structure, precedent, affected files) and human-owned branches (priority pain, trade-offs, anti-goals, success bar).
For broad qualitative asks (improve, simplify, clean up, make nicer), do not stop after scope + one quality axis; keep pressure-testing unresolved human-owned branches that can still change execution.
If a human-owned branch is intentionally defaulted, state the default and rationale, then get explicit user acceptance before treating the interview as complete.
When useful, offer a recommended path to speed decisions, but do not treat one broad answer as /work readiness.
When the interview is complete, persist the resolved contract through the normal planning path (plan_save, plan_context_write when available, otherwise saved plan + notepad_write).
