원클릭으로
feature
Write the feature design doc — the WHY + SHAPE for a single feature. No formal requirements yet (those come in /genesis-specify).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Write the feature design doc — the WHY + SHAPE for a single feature. No formal requirements yet (those come in /genesis-specify).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | Feature |
| description | Write the feature design doc — the WHY + SHAPE for a single feature. No formal requirements yet (those come in /genesis-specify). |
| argument-hint | <feature-name> [--update|--fresh] |
Write the feature design doc: why this feature exists, what shape it takes, how it fits the project. It contains no formal requirements, acceptance criteria, or user stories — those come in /genesis-specify. This is the first per-feature pipeline command after that feature's brainstorm.
Gate: the feature's brainstorm phase must be accepted in approvals/master.json (else "Run /genesis-brainstorm and accept it first"). Also requires the project overview to exist.
.genesis/project-state.md (mode).genesis/design/overview.md (required), plus architecture.md, data-model.md, and other design docs.genesis/features/<feature>/brainstorm-log.md (required).genesis/features/<feature>/approvals/master.json (verify brainstorm accepted).genesis/features/<feature>/.design.md from feature-design-template.md. Sections: Overview · Business Rules · User Experience · Edge Cases · Error Handling · Data Requirements · Security Considerations · Performance Considerations · System Diagram · Technology Choices · Design Decisions (institutional memory) · Scope · Future Considerations — plus mode-specific sections..genesis/features/<feature>/design.md — the WHY + SHAPE document.Run /genesis-specify.
- "write the feature design"
- "shape this feature"
- "feature doc for X"
The drift check. Compare what was built against the design doc and master spec. Sets the Double Gate — A3 cannot start until A1 is at zero findings.
Mechanical FR/AC compliance. Walk every functional requirement and acceptance criterion and render a binary Pass/Fail with evidence. No judgment about quality, direction, or architecture.
Code/content quality. Dead code, hardcoded values, leftover TODOs, weak error handling, security holes, performance traps, standards violations. Enforces the Double Gate — blocks until A1 is at zero findings.
Vision-gap analysis. Compared to the perfect-world North Star, what is missing, drifting, or underbuilt — and what to add or change now to close the gap. Not a passive alignment scorecard.
Research the world. Real web research to find what the best teams do for every technology and pattern in the build, then implement superior approaches now (not later). The only lens that brings outside knowledge.
The boundary ritual — review what just landed, record an approval, journal it, and advance the phase. The ONLY step that writes approvals, and it does NO git.