메뉴
Write a specification before writing any implementation code
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | spec-driven-development |
| description | Write a specification before writing any implementation code |
| difficulty | senior |
| domains | ["general"] |
Specification-driven development forces clarity before commitment. A spec written before code reveals ambiguities, surfaces missing requirements, and creates a shared contract between implementer and reviewer. Code written without a spec is often solving the wrong problem correctly.
Write down what you've been asked to build, in plain English, without interpretation. Include the source (ticket, conversation, PR comment).
Answer: Who uses this? How do they know it works? What does failure look like?
List what the system must do. Use "The system shall..." or "When X, then Y." Each requirement must be independently testable.
Document: performance expectations, security constraints, accessibility requirements, scale targets, error handling expectations.
Sketch the inputs, outputs, and state transitions. Identify what data must be stored, what must not be stored, and what can be computed.
For APIs: endpoints, methods, request/response shapes, error codes. For UIs: wireframe or component tree, states (loading, empty, error, populated). For libraries: public function signatures and contracts.
Document every assumption you made and every question you don't have an answer to. Get answers before writing code.
Have the spec reviewed by at least one stakeholder before starting implementation. A spec that nobody reads is not a spec.
"This feature is obvious — I don't need to write it down" If it's obvious, the spec takes 10 minutes. If it's not obvious, the spec saves days. Either way: write it.
"We'll iterate quickly — the spec will be wrong anyway" Iteration is not an excuse to skip specs. It means you write smaller, tighter specs for each iteration. Iterating on code without a spec means iterating in circles.
"The ticket has enough detail" Tickets capture requests, not contracts. A spec translates requests into testable requirements. These are different things.
Before starting implementation:
