메뉴
Use for standard or complex new work before coding or planning. Also handles vague goals — clarifies before designing.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use at ship time to merge the spec into the living documentation, delete the staging spec and plan, and ask how to finish.
Use when taking over an existing codebase that has no living document. Produces a factual record of what already exists.
Use when all plan tasks are done and green to review, archive planning artifacts, and ask how to finish.
Use at session start to learn how Praxis skills are invoked and why triage runs before every task.
Use when the goal is vague or vision-level and can't be defined well enough for design questions.
Use after design approval for milestone plans with executable acceptance.
| name | design |
| description | Use for standard or complex new work before coding or planning. Also handles vague goals — clarifies before designing. |
<gate> No code until user approves the spec. </gate>
Goal too vague to name what to build, for whom, or what success looks like? Ask one question per turn until it's concrete. Don't propose solutions until then. Working notes can hold hypotheses, experiments, ruled-out directions (spike code → temporary worktree).
Goal clear? Propose 2-3 approaches with trade-offs; recommend one. Then write the spec.
A spec answers the open questions for THIS change. Typical:
Do spec idiomatically.
No question -> no section. Don't fill "Risks" / "Non-goals" if empty.
Use declarations, not narrative:
contract: <interface>
invariant: <what must hold>
test: <how we'll know>
deferred: <not deciding now>
Reference code by path; never paste it.
Before handoff, close only decisions that affect implementation: contract, data, failure, test. Unresolved Working notes in those areas become decisions, deferred, or questions.
docs/staging/specs/YYYY-MM-DD-<topic>.md## Working notes: scratch, open questions, hypotheses, ruled-out directions (stripped at ship).docs/ROADMAP.md already exists?
docs/ROADMAP.md.docs/ROADMAP.md does not exist?
docs/ROADMAP.md:
- [ ] M1: <one-line goal>
- [ ] M2: <one-line goal>
- [ ] M3: <one-line goal>
Stubs are intent, not commitment; update before expanding.
If roadmap exists or was created, reference the current milestone in staging spec:
milestone: M1 (see docs/ROADMAP.md)
If the user decides not to proceed after clarification, stop here. No spec, no plan, no ship. Record reason briefly in working notes. If exploration produced a knowledge artifact (protocol spec, RE findings, data structure map), save it to docs/decisions/ via archive.
<gate>
docs/staging/specs/YYYY-MM-DD-<topic>.md must exist on disk before handing off to plan.</gate>