메뉴
Turns a vague idea or feature into an executable spec using the 5 questions (context, goal, constraints, tasks and verification) before writing any code. Use it when the user describes something they want to build and asks for a spec, or to plan the work before implementing.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | scope |
| description | Turns a vague idea or feature into an executable spec using the 5 questions (context, goal, constraints, tasks and verification) before writing any code. Use it when the user describes something they want to build and asks for a spec, or to plan the work before implementing. |
Turn the user's idea into a spec and save it to specs/<slug>.md. Read CLAUDE.md / AGENTS.md first if they exist (that's where the global conventions and constraints come from). Ask only if you're blocked. Don't write code yet.
You work in two beats:
## Flow section with TWO ASCII diagrams (sequence + flow) and stop: show them to the user and ask them to confirm that's the behavior they want. This is where you get sign-off on the decisions the agent would otherwise invent (time windows, edge cases, what happens when there's no data). Don't move on until you get the "yes".The spec must have exactly these sections:
# <Feature name>
## Context
- What exists today (stack, folders) that you must respect.
- Patterns to follow (name a file in the repo that already does it well).
- Decisions already made (so they aren't re-litigated).
## Goal
The concrete, bounded outcome. One sentence, not "improve X".
## Flow
SEQUENCE diagram. By default deliver the **compact** version (an ordered list of steps); only if the user asks for the detail, give the **full** one with lifelines.
Compact (default):
SEQUENCE (chronological order ↓)
Full (only if asked) — each participant with its vertical lifeline (`│`), time going DOWN; calls solid arrow (`──▶`), returns dashed (`◀ ─ ─`):
Actor Component OtherComp │ │ │ │ action │ │ │────────────▶│ │ │ │ call() │ │ │─────────────▶│ │ │◀ ─ return ─ ─│ │◀─ response ─│ │ ▼ ▼ ▼
FLOW diagram (the decisions and branches — this is where the edge cases live):
input │ ▼ condition? ──no──▶ branch A │ yes ▼ action ──▶ result
## Constraints
- What NOT to touch (auth, data model, API contracts).
- No new dependencies unless necessary and justified.
## Out of scope
- What does NOT go in this feature.
## Tasks
### T1: <short title>
- **Do:** <specific change>
- **Files:** <paths it will touch>
- **Verify:** <specific command or manual check>
### T2: ...
## Done (final validation)
- [ ] <build/test command passes>
- [ ] Manual: <what to check end-to-end>
Rules when writing it:
When you're done, run the completeness test on yourself: could a fresh agent, with no context beyond this spec, implement T1? If not, detail is missing.
Revisa los cambios (el diff) como un ingeniero senior contra la spec, mirando alcance, correctitud, simplicidad y consistencia. Úsala antes de commitear o mergear, cuando se pida revisar el código o el diff.
Reviews the changes (the diff) as a senior engineer against the spec, looking at scope, correctness, simplicity and consistency. Use it before committing or merging, when a review of the code or the diff is requested.
Implements ONE single task from an existing spec, without touching anything else. Use it when a spec file exists in the specs folder and the user asks to run or implement a concrete task (for example T1 or T2).
Verifies that a task is actually done by running its Verify step and showing the real output, no self-reporting. Use it after implementing a task, when you want to confirm it truly works and not just that the agent claims so.
Writes the commit message for the staged changes, in conventional commits format and explaining the why. Use it when you want to commit or generate the commit message.
Draws, in ASCII, the sequence diagram and the flow diagram of a piece of existing code, to understand how it works before modifying it. Use it when the user wants to understand an existing flow, function or feature, or before scoping over legacy code.