원클릭으로
spec-driven-development
Use when generating specs/ compatible output after Phase 3, enabling handoff to /orchestrate or /implement workflows.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when generating specs/ compatible output after Phase 3, enabling handoff to /orchestrate or /implement workflows.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Enhanced planning system combining UltraPlan's 6-phase pipeline with Clear Thought's 11 structured thinking frameworks. Takes a plain-English idea and produces a complete, AI-executable implementation plan with rigorous thinking at every phase.
Use when defining API endpoints, designing request/response schemas, or establishing API contracts during framework planning.
Use when documenting architectural decisions, comparing technology options, or recording rationale for framework choices.
Use when selecting architecture patterns (MVC, hexagonal, clean, microservices) for a new project.
Use when creating or updating blueprint files in .framework-blueprints/ directory.
Use when designing CI/CD pipelines or creating GitHub Actions / GitLab CI configuration.
| name | spec-driven-development |
| description | Use when generating specs/ compatible output after Phase 3, enabling handoff to /orchestrate or /implement workflows. |
| allowed-tools | Read, Write, Glob |
After Phase 3 (Planning) produces API contracts and a coding sequence, this skill generates a specs/ directory compatible with /orchestrate and /implement workflows.
Invoke after Phase 3 approval when the user wants to:
/orchestrate for parallel execution/implement to followGenerate specs/[project-name]/ with:
specs/[project-name]/
├── design.md # Architecture overview + key decisions
├── api-contracts.md # Copy of 03-api-planning/api-contracts.md
├── modules.md # Module list with file ownership
├── implementation-order.md # From coding-sequence.md
└── constraints.md # Non-standard paths, API quirks, env vars
# [Project Name] - Design Specification
## Overview
[One paragraph from Phase 1 vision statement]
## Architecture
[Pattern chosen in Phase 2 with rationale]
## Modules
| Module | Purpose | Owner | Files |
|--------|---------|-------|-------|
| [name] | [purpose] | [agent/unassigned] | [file paths] |
## Key Decisions
| ID | Decision | Rationale | Source |
|----|----------|-----------|--------|
| D001 | [decision] | [why] | [URL] |
## Constraints
- [Non-standard paths]
- [API quirks]
- [Required environment variables]
# Module Ownership
> ONE FILE = ONE OWNER. No shared ownership.
| File Path | Module | Owner | Status |
|-----------|--------|-------|--------|
| src/auth/middleware.ts | Auth | unassigned | pending |
| src/users/controller.ts | Users | unassigned | pending |
01-discovery/outline-v1.md for vision01-discovery/decisions-log.md for key decisions02-structure/module-hierarchy.md for module list03-api-planning/api-contracts.md for API specs03-api-planning/coding-sequence.md for implementation order00-project-state.json for critical detailsThe generated specs are compatible with:
/orchestrate - reads modules.md for file ownership, implementation-order.md for sequencing/implement - reads design.md for architecture context, api-contracts.md for endpoints