メニュー
Start here to turn a vague, ambiguous, or high-blast-radius request into a clear, falsified spec through relentless questioning.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
Start here to ship built-and-tested code to its target safely — release steps, rollout, smoke checks, and rollback.
Start here to settle how a non-trivial change will be built — interfaces, contracts, file-level structure, and trade-offs.
Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
Start here to document what shipped — READMEs, API docs, ADRs, and usage — once a feature lands or an interface changes.
| name | requirements-gathering |
| description | Start here to turn a vague, ambiguous, or high-blast-radius request into a clear, falsified spec through relentless questioning. |
| context | fork |
| agent | product-owner |
Run the relentless interrogation from the interrogate skill against the requirements until the work is unambiguous — one question at a time, a recommended answer for each, exploring the codebase instead of asking when you can.
One twist: you can't reach the user — so address your questions to the main thread. Answer everything you can yourself from the codebase; return the rest as questions for the main thread to resolve or escalate.
The unresolved questions, each with your recommended answer, plus a draft spec: the problem; scope (in and out); the requirements — functional (what it does) and nonfunctional / quality-of-service (performance, reliability, security, usability), each measurable and given a stable ID so design, tasks, and tests can trace back to it (see ../../GLOSSARY.md); and risks.
