القائمة
Use when user requirements need to be analyzed, structured into a requirements document, or when open questions from a previous analysis need resolution.
التثبيت باستخدام 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-requirements-analysis |
| description | Use when user requirements need to be analyzed, structured into a requirements document, or when open questions from a previous analysis need resolution. |
| 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/requirements.md","skill_nature":"amplification","lifecycle":"active"} |
Analyze and document requirements at a depth appropriate to the request's complexity.
일반 호출. Step 1부터 순서대로 실행.
호출 텍스트에 QUESTIONS 키워드 포함 시 활성화:
"aidlc-requirements-analysis: QUESTIONS — 기존 분석 유지, 미해결 질문만 처리"
QUESTIONS 모드에서는:
devflow-docs/inception/requirements.md 읽기## Open Questions 섹션의 미해결 질문만 one-at-a-time으로 처리## Assumptions 또는 해당 요구사항 섹션에 반영requirements.md 업데이트 후 STOPStep 1, 2, 3, 4는 실행하지 않는다.
미해결 질문이 남아있으면 열린 질문: [N]개 패턴을 포함하여 반환. 모두 해결되면 열린 질문: 0개.
호출 텍스트에 UPDATE 키워드 포함 시 활성화:
"aidlc-requirements-analysis: UPDATE — 기존 분석 유지, [변경 내용] 반영"
UPDATE 모드에서는:
devflow-docs/inception/requirements.md 읽기 (기존 분석)## Change Log 섹션에 변경 내역 기록: - [ISO 8601] UPDATE: [변경 요약]requirements.md 업데이트 후 STOP도구 선택: 부분 업데이트에는 반드시 Edit 도구를 사용한다. Write 도구로 전체 덮어쓰기 금지.
Step 1, 2, 3, 4, 5는 실행하지 않는다.
UPDATE 범위 제한: User Intent 자체를 변경하는 요청은 UPDATE 대상이 아니다. "방향을 바꾸고 싶다"는 요청에는 "전체 재분석이 필요합니다"라고 안내하고 일반 모드로 재호출을 유도한다.
호출 텍스트에서 complexity 확인 (Primary):
호출 텍스트에 Complexity: [level] 패턴이 있으면 그 값을 사용:
devflow-state에서 확인 (Fallback):
호출 텍스트에 complexity 정보가 없으면 devflow-docs/devflow-state.md의 ## Complexity 필드를 읽는다.
해당 필드도 없으면 기존 기준으로 자체 판단:
Choose Minimal if ALL of:
Choose Comprehensive if ANY of:
Otherwise: Standard
Skip this step entirely if depth is Minimal.
For Standard and Comprehensive, ask: "이 요청에 동등하게 유효한 해석이 2가지 이상 존재하는가?"
판단 기준 — 해석이 분기되는 신호:
해석이 분기되지 않으면: Step 3으로 바로 진행.
해석이 분기되면: 2-3가지 해석을 제시하고 사용자의 확인을 받은 후 Step 3으로 진행.
이 요청은 다음 중 어떤 방향인가요?
A) [해석 1] — [한 줄 설명]
B) [해석 2] — [한 줄 설명]
C) [해석 3] — [한 줄 설명, 있는 경우]
직접 설명하셔도 됩니다.
선택된 해석을 requirements.md의 ## User Intent에 반영한다.
session-summary 중간 기록: 해석 확정 후 session-summary.md의 ## Completed Work에 [~] requirements-analysis — 해석 확정([선택]안) 업데이트 + ## For Next Session에 미결 질문 목록 기록.
해석 선택 후, 다음 모호성 신호를 탐지한다:
신호 감지 시: 후속 질문 ONE at a time:
[이전 답변]을 더 구체화해야 합니다.
A와 B 중에서 상충할 때 어느 쪽을 우선하시겠어요?
모호성이 해소될 때까지 반복.
사용자가 "그냥 진행해" 또는 "계속해" 요청 시:
## Assumptions에 기록Minimal depth에서도 실행한다. 기술 스택은 이후 모든 단계의 전제 조건이므로.
다음 3가지 소스를 순서대로 확인한다:
| 우선순위 | 소스 | 확인 방법 |
|---|---|---|
| 1 | CLAUDE.md 사전 지정 | workspace.md의 ## Pre-specified Tech Stack 섹션 존재 여부. 있으면 해당 항목은 확정 |
| 2 | Brownfield 감지 | workspace.md의 ## Technology Stack (Brownfield) 섹션. Language, Framework, DB 등이 감지되었으면 해당 항목은 확정 |
| 3 | 사용자 프리셋 | tech-stack-defaults.md의 ## 사용자 프리셋 섹션 확인 |
스킵 판단 결과:
[기술 스택: 사전 지정 — 질문 스킵] 기록, Step 3으로미커버 계층에 대해 순서대로 처리:
1. 프리셋 확인: tech-stack-defaults.md에 해당 계층의 프리셋이 있으면:
[계층] 기술 스택에 프리셋이 있습니다:
→ [프리셋 기술 조합]
이대로 사용하시겠습니까? (Y/n)
2. 카탈로그 선택: tech-stack-catalog.md의 해당 계층 섹션을 Read
tech-stack-catalog.md가 없으면 카탈로그 선택을 스킵하고, 해당 계층을 자유 입력으로 질문한다.(권장) 표시 (question-format-guide.md 원칙)tech-stack-defaults.md의 정책 모드에 따름:
X) 직접 입력 포함X) 직접 입력 (사유 필수) — 선택 시 사유 질문 → requirements.md에 기록결과 기록: requirements.md의 ## Technology Stack 섹션에:
## Technology Stack
| 계층 | 선택 | 소스 | 비고 |
|------|------|------|------|
| [계층명] | [기술명] | [CLAUDE.md | Brownfield 감지 | 프리셋 | 카탈로그 선택 | 직접 입력] | [비고] |
guided 모드에서 카탈로그 외 기술 선택 시 ## 기술 스택 결정 섹션에 사유 테이블 추가.
[~] requirements-analysis — 질문 N/M 완료 업데이트.| Depth | 해석 분기 | 핵심 질문 | Ambiguity Loop |
|---|---|---|---|
| Minimal | 없음 | 없음 | 없음 |
| Standard | 있음 | 최대 2개 (each → loop) | 있음 |
| Comprehensive | 있음 | 제한 없음 (each → loop) | 있음 |
열린 질문이 있는 경우, 질문을 시작하기 전에 맥락을 먼저 선언한다:
요구사항을 확정하기 전에 몇 가지 질문을 드리겠습니다.
[질문 수]개의 열린 질문이 있습니다.
그 후 ONE question at a time. Wait for answer before asking next.
Create devflow-docs/inception/requirements.md:
# Requirements Analysis
**Depth**: [Minimal | Standard | Comprehensive]
**Timestamp**: [ISO 8601]
## User Intent
[What the user wants to achieve — Step 2에서 확정된 해석 포함]
## Functional Requirements
[List of requirements]
## Non-Functional Requirements
[Performance, security, etc.]
## Technology Stack
| 계층 | 선택 | 소스 | 비고 |
|------|------|------|------|
[Step 2b 결과]
## Assumptions
[List of assumptions made]
## Open Questions
[Any unresolved questions]
conventions Review Workflow 적용.
conventions 표준 형식. 반환 필드:
요청이 너무 모호하면: