菜单
Use when component and service structure needs to be designed before implementation, as a conditional INCEPTION stage after workflow-planning.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
아이디어를 설계로 전환하거나, 새로운 기능을 만들거나, 구현 전 구조화된 설계가 필요한 창의적/탐색적 작업에 사용. Use when turning an idea into a design, creating a new feature, or when any creative/exploratory work needs structured design before implementation.
태스크나 unit 구현이 완료되어 머지 전 코드 리뷰가 필요할 때, 또는 사용자가 명시적으로 코드 리뷰를 요청할 때 사용. Use when a task or unit implementation is complete and needs code review before merging, or when the user explicitly requests a code review on their changes.
설계 문서를 상세 구현 계획으로 변환하거나, "구현 계획 작성", "plan 만들어줘" 요청 시 사용. INCEPTION 워크플로우 계획은 aidlc-workflow-planning 사용. Use when a design document needs to be converted into a detailed implementation plan with task breakdown, or when "구현 계획 작성", "plan 만들어줘" is requested. Not for INCEPTION workflow planning — use aidlc-workflow-planning instead.
Use when user explicitly requests "auto 모드", "자동 모드", "auto mode", or "알아서 만들어줘". 초보자를 위한 완전 자동 devflow. greenfield 전용. 요구사항 입력 → inception → construction → build-test를 자동 진행하며 각 flow 종료 시 멀티에이전트 리뷰 필수.
현재 세션에서 구현 계획을 실행할 때 사용. 독립 태스크별 신규 서브에이전트 컨텍스트 활용. Use when executing an implementation plan in the current session with independent tasks that benefit from fresh subagent context per task.
프로덕션 코드 작성, 버그 수정, 리팩토링 시 사용 — 예외 없이 RED-GREEN-REFACTOR 사이클을 강제. Use when writing any production code, fixing bugs, or refactoring — enforces RED-GREEN-REFACTOR cycle with no exceptions.
| name | aidlc-application-design |
| description | Use when component and service structure needs to be designed before implementation, as a conditional INCEPTION stage after workflow-planning. |
| metadata | {"version":"0.6.0","author":"Jay","category":"ai-dlc-workflow","invoke_mode":"orchestrator-only","return_behavior":"stop-no-gate","output_path":"devflow-docs/inception/application-design.md","skill_nature":"hybrid","lifecycle":"active","model_dependency":"모델이 컴포넌트 경계를 임의로 결정함","amplification_notes":"도메인 entity + 서비스 구조 명시적 분해"} |
Design the component and service structure before implementation begins.
일반 호출. 컴포넌트 목록만 생성하고 STOP.
모든 depth에서 application-design.md에 컴포넌트 목록을 저장한다 (Minimal 포함).
호출 텍스트에 DETAIL 키워드 포함 시 활성화:
"aidlc-application-design: DETAIL — 승인된 목록으로 상세 설계 진행"
DETAIL 모드에서는:
devflow-docs/inception/application-design.md 읽기 (목록 단계 결과)application-design.md 업데이트 후 STOPdepth 확인 (Primary): 호출 텍스트에 Depth: [level] 패턴이 있으면 그 값을 사용.
depth 확인 (Fallback): 호출 텍스트에 없으면 devflow-docs/inception/workflow-plan.md의 ## Stage Depths → application-design 행에서 읽는다.
Minimal depth: LIST Mode만 실행. DETAIL 호출 없음.
Read the following files (if they exist):
devflow-docs/inception/requirements.md — functional and non-functional requirementsdevflow-docs/inception/workspace.md — greenfield/brownfield contextDETAIL 모드인 경우 Step 4로 건너뛴다.
각 새 컴포넌트에 대해 아래 정보만 수집 (상세 설계는 DETAIL 모드에서):
반환 형식:
## 컴포넌트 목록 (초안)
| 컴포넌트 | 책임 | 타입 |
|---------|------|------|
| [Name] | [한 줄 책임] | [Type] |
총 [N]개 컴포넌트
LIST 모드에서는 컴포넌트 목록을 devflow-docs/inception/application-design.md에 저장 후 STOP.
Minimal depth 포함 모든 depth에서 저장 필수 (이후 스킬이 이 파일을 참조).
# Application Design
**Mode**: LIST (목록 단계)
**Timestamp**: [ISO 8601]
## 컴포넌트 목록
| 컴포넌트 | 책임 | 타입 |
|---------|------|------|
| [Name] | [한 줄 책임] | [Type] |
session-summary 중간 기록: LIST 완료 후 session-summary.md의 ## Completed Work에 [~] application-design — LIST 완료 ([N]개 컴포넌트) 업데이트.
→ Return to Orchestrator (목록 반환)
DETAIL 모드에서만 실행.
Standard depth: 각 컴포넌트에 대해:
Comprehensive depth: 각 컴포넌트에 대해:
+, -, |, ^, v, >, <)application-design.md를 업데이트하여 상세 섹션 추가:
## 컴포넌트 상세 설계
### [ComponentName]
**Responsibility**: [한 줄]
**Interface**: [메서드 목록]
**Dependencies**: [의존 컴포넌트]
**Data Owned**: [소유 데이터] (Comprehensive만)
**Interactions**: [ASCII 다이어그램] (Comprehensive만)
호출 텍스트에 NFR Design 포함 키워드가 있을 때만 실행.
없으면 이 Step을 스킵하고 Review로 진행.
핵심 원칙: Claude는 정보 정리자이지 의사결정자가 아니다. NFR 설계에는 정답이 없고 트레이드오프만 존재한다.
devflow-docs/inception/nfr-requirements.md 읽기⚠️ 이 선택은 기술 담당자와 상의를 권장합니다 경고 포함application-design.md에 ## NFR Design Patterns 섹션 추가산출물 형식:
## NFR Design Patterns
> ⚠️ NFR 패턴 선택은 운영 환경과 비용에 따라 달라집니다.
> 기술 담당자와 상의를 권장합니다.
### [NFR 카테고리]: [요구사항 값]
| 패턴 | 장점 | 단점 | 비용 영향 |
|------|------|------|----------|
| [패턴 A] | [장점] | [단점] | [비용] |
| [패턴 B] | [장점] | [단점] | [비용] |
| [패턴 C] | [장점] | [단점] | [비용] |
conventions Review Workflow 적용.
session-summary 중간 기록: DETAIL 모드에서 각 컴포넌트 상세 설계 완료 시 [~] application-design — DETAIL [N]/[M] 컴포넌트 완료 업데이트.
conventions 표준 형식. 반환 필드:
LIST Mode:
DETAIL Mode:
시스템이 단일 컴포넌트로 충분하면: