메뉴
Guide for design-driven development with prescribed folder structure. New features use full workflow (HLD → LLD → EARS). Bug fixes skip doc creation but verify intent coherence.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/ericmjl/nxviz --skill design-driven-dev명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | design-driven-dev |
| description | Guide for design-driven development with prescribed folder structure. New features use full workflow (HLD → LLD → EARS). Bug fixes skip doc creation but verify intent coherence. |
This skill guides a structured design-driven development workflow. The goal is to get alignment on what you're building before writing code, which dramatically reduces rework and misunderstandings.
STOP after completing each phase. Present the document to the user for review. Incorporate their numbered feedback. Only proceed to the next phase when explicitly approved.
This is the most important part of the workflow. Don't rush through design to get to code.
Before starting any design work, determine the documentation directory:
DOCS_DIR environment variable or project config?./docs/ - This is the canonical location./docs/ or ./doc/ directories:
X. Use this?"./docs/ for design documents?"Once determined, use DOCS_DIR as the root for all design documents.
DOCS_DIR/
├── high-level-design.md # Single HLD for entire project
└── designs/
└── <feature-name>/
├── LLD.md # Low-level design for feature
├── <sub-feature-1>-EARS.md
├── <sub-feature-2>-EARS.md
└── ...
Example:
docs/
├── high-level-design.md
└── designs/
├── authentication/
│ ├── LLD.md
│ ├── login-EARS.md
│ ├── logout-EARS.md
│ └── password-reset-EARS.md
└── payments/
├── LLD.md
├── checkout-EARS.md
└── refunds-EARS.md
DOCS_DIR/high-level-design.mdDOCS_DIR/designs/<feature>/LLD.mdDOCS_DIR/designs/<feature>/<subfeature>-EARS.mdSee hld-template.md for HLD structure guidance.
Consult this skill for ALL code changes.
Full workflow (create new docs) for:
Coherence check only (skip doc creation) for:
Even when skipping doc creation, verify intent coherence: do existing specs, tests, and code align? If not, fix the docs before changing the code.
If unsure, use the full workflow. Over-designing is safer than under-designing.
File: DOCS_DIR/high-level-design.md
Check if an HLD exists first. For new projects or major features, create an HLD covering:
Required: Link to LLDs
## Related Designs
- [Authentication LLD](./designs/authentication/LLD.md)
- [Payments LLD](./designs/payments/LLD.md)
See hld-template.md for full structure with examples.
Stop and get user approval before proceeding.
File: DOCS_DIR/designs/<feature>/LLD.md
Create one LLD per major feature. Each LLD should include:
Required: Link to HLD and EARS
## Related Documents
- [High-Level Design](../high-level-design.md)
- [Login EARS](./login-EARS.md)
- [Logout EARS](./logout-EARS.md)
See lld-template.md for structure guidance, including when to use narrative vs. structured format.
Stop and get user approval before proceeding.
File: DOCS_DIR/designs/<feature>/<subfeature>-EARS.md
Generate requirements using EARS (Easy Approach to Requirements Syntax). Create one EARS file per sub-feature.
Required: Link to parent LLD
## Related Documents
- [Authentication LLD](./LLD.md)
See ears-syntax.md for full EARS syntax, semantic ID format, and scope disambiguation guidance.
Stop and get user approval before proceeding.
HLD must link to all LLDs:
## Related Designs
- [Authentication LLD](./designs/authentication/LLD.md)
- [Payments LLD](./designs/payments/LLD.md)
LLD must link back to HLD:
## Related Documents
- [High-Level Design](../high-level-design.md)
LLD must link to all its EARS files:
## Requirements
- [Login Form EARS](./login-EARS.md)
- [Password Reset EARS](./password-reset-EARS.md)
EARS must link back to parent LLD:
## Related Documents
- [Authentication LLD](./LLD.md)
There's a chain of documents that translates intent from vision to working code:
HLD → LLDs → EARS → Tests → Code
Each level translates the previous into more specific terms:
The arrow of intent must stay coherent. When one level changes, downstream levels must be reviewed and updated to match.
Mutation, not accumulation. Update docs in place. Delete what's wrong. The documentation should always reflect current intent.
When requirements or understanding change:
Before implementing (or resuming implementation), verify coherence:
Annotate code with @spec comments linking to EARS IDs:
// @spec AUTH-LOGIN-001, AUTH-LOGIN-002, AUTH-LOGIN-003
export function LoginForm({ ... }) {
// Implementation
}
Test files also reference specs:
// @spec AUTH-LOGIN-010
it('validates email format before submission', () => {
expect(validateEmail('invalid')).toBe(false);
});
This creates traceability from requirements → code → tests.
| Benefit | Why It Matters |
|---|---|
| Forced checkpoints | Catches misunderstandings before you've built the wrong thing |
| Progressive reveal | Sparsity of files makes complex features manageable |
| Cross-linking | Always know where to find related context |
| Traceability | @spec annotations link code to requirements |
| Survives session breaks | Docs persist, context doesn't get lost |
| Testable requirements | EARS format ensures requirements are verifiable |