メニュー
Selectively stress-test a plan or design by asking only high-leverage questions that could materially change the outcome. Use when user wants to be grilled, stress-test a plan, pressure-test a design, or mentions "grill me".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Choose an appropriate test level and use red-green-refactor when test-first work is requested. Use when the user asks for TDD, red-green-refactor, test-first development, integration tests, or help deciding coverage. Prefer integration tests for meaningful behavior across boundaries, unit tests for nontrivial isolated logic requiring little or no mocking, and no new test for trivial behavior adequately covered by types or existing tests.
Expert guidance for Effect-TS architecture, typed error design, Layers, services, concurrency, resource management, and meaningful Effect refactoring. Use when the user explicitly asks for Effect patterns or the task materially changes Effect architecture. Do not use merely because a file imports Effect or a repository uses Effect.
Use for pnpm dependency management, workspace configuration, catalogs, patches, overrides, or package-resolution problems. Do not use for routine `pnpm test`, `pnpm build`, `pnpm lint`, or `pnpm type-check` commands.
Prepare, publish, and maintain GitHub pull requests with template-faithful descriptions, fewer pushes, and CI follow-through. Use when creating, updating, pushing, or checking a GitHub PR, or when the user asks to open, ship, publish, or polish a PR.
Review software implementation plans before execution. Use when a programming plan, technical approach, implementation checklist, or execution brief needs approval, critique, validation, or readiness review before an execution agent starts work.
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
| name | grill-me |
| description | Selectively stress-test a plan or design by asking only high-leverage questions that could materially change the outcome. Use when user wants to be grilled, stress-test a plan, pressure-test a design, or mentions "grill me". |
Stress-test the user's plan like a sharp collaborator, not a survey form.
Before asking anything, identify the 2-4 highest-risk uncertainties. Prefer questions about:
Skip questions when the answer is obvious, low-impact, stylistic, or easy to infer.
Ask one question at a time. For each question:
Do not ask for details you can discover by reading files, running safe commands, or inspecting the codebase. Go explore instead.
Aim for the fewest questions needed to de-risk the plan, usually 3-7 total. Stop grilling when the remaining uncertainty would not materially change what to do next; summarize the working assumptions and move toward a concrete plan.
