القائمة
Use when starting INCEPTION to detect whether the workspace is greenfield or brownfield and analyze existing code structure.
التثبيت باستخدام 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-workspace-detection |
| description | Use when starting INCEPTION to detect whether the workspace is greenfield or brownfield and analyze existing code structure. |
| 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/workspace.md","skill_nature":"amplification","lifecycle":"active"} |
Analyze the current workspace to determine project type and context.
devflow-docs/inception/workspace.md가 이미 존재하는지 확인한다.
존재하지 않으면 → Step 1로 진행 (풀스캔)
존재하면 → 델타 분석 수행:
workspace.md를 읽어 이전 분석 내용을 확보한다. 파싱 실패 시 (비표준 형식, 손상 등) → Step 1로 진행 (풀스캔으로 전환)package.json, go.mod, Cargo.toml, pyproject.toml, pom.xml 등의 존재/부재 변화 또는 내용 변경git log --oneline -5로 최근 커밋이 이전 분석의 Recent Commits와 다른지 확인**Timestamp**만 갱신하여 저장. **Source** 필드에 이전 분석([이전 Timestamp 값]) 기반 — 변경 없음 기록 → Step 3으로 직행**Source** 필드에 이전 분석([이전 Timestamp 값]) 기반 + 델타 업데이트 기록 → Step 3으로 직행변경 유형 → 재분석 섹션 매핑:
| 변경 감지 대상 | 재분석 섹션 |
|---|---|
| 매니페스트 파일 | Technology Stack, Key Dependencies |
| Git 커밋 | Git Activity (Recent Commits, Recent Focus) |
| CLAUDE.md 기술 스택 | Pre-specified Tech Stack |
Check for the following indicators:
Greenfield indicators:
.py, .go, .ts, .js, .rs, .java, etc.)package.json, go.mod, Cargo.toml, pom.xml, pyproject.tomlBrownfield indicators:
| Result | Condition |
|---|---|
| Greenfield | No existing code found |
| Brownfield | Existing code found |
Brownfield일 때만 실행. Greenfield면 이 단계를 건너뛴다.
두 가지를 수집한다:
1) Technology Stack — 매니페스트 파일 파싱:
| 매니페스트 | 언어/런타임 |
|---|---|
package.json | Node.js — dependencies에서 주요 프레임워크 식별 |
go.mod | Go — 모듈 경로 + 주요 의존성 |
Cargo.toml | Rust — [dependencies] 섹션 |
pyproject.toml / requirements.txt | Python — 패키지 + 버전 |
pom.xml / build.gradle | Java — 프레임워크 (Spring 등) |
추가로 빌드 도구, 테스트 프레임워크, 린터 설정 파일도 기록한다.
2) Git Activity — 최근 활동 기반 핫스팟:
git log --oneline -20 # 최근 커밋 20개 요약
git log --pretty=format: --name-only -20 | sort | uniq -c | sort -rn | head -10 # 최근 변경 파일 top 10
수집 항목:
git 저장소가 아니면 이 항목을 스킵한다.
3) Existing Documentation — 기존 문서 감지:
아래 파일/디렉토리 존재 여부를 확인하고, 존재하면 핵심 내용 1~2줄 요약:
| 감지 대상 | 설명 |
|---|---|
README.md | 프로젝트 소개, 설치/실행 방법 |
CLAUDE.md | Claude Code 지시사항 |
CONTRIBUTING.md | 기여 가이드 |
ARCHITECTURE.md | 아키텍처 문서 |
docs/ 디렉토리 | 추가 문서 존재 여부 + 파일 수 |
ADR/ 또는 decisions/ | 아키텍처 결정 기록 |
없는 항목은 기록하지 않는다.
Greenfield/Brownfield 공통. Step 2a와 독립적으로 실행.
CLAUDE.md 파일의 존재를 직접 확인하고, 기술 스택 섹션을 구조적으로 파싱한다.
감지 패턴:
## 헤딩 중 "기술 스택" 또는 "Tech Stack"을 포함하는 것언어:, 프레임워크:, DB:, 테스트:, CI/CD: 등 키-값 쌍감지 결과:
이 단계에서 Coverage 판단은 하지 않는다. 아키텍처 패턴이 아직 결정되지 않았으므로, 감지된 항목 목록만 기록한다. Coverage 판단은 requirements-analysis Step 2b-1에서 수행.
제약:
4) Code Structure — 디렉토리 트리 + 진입점:
main.py, index.ts, cmd/ 등)| 디렉토리 패턴 | 기록할 패턴 |
|---|---|
controllers/ + models/ + views/ | MVC |
routes/ + services/ + repositories/ | 레이어 구조 |
cmd/ + internal/ + pkg/ | Go 표준 레이아웃 |
src/ + tests/ | src 레이아웃 |
| 위에 해당 없음 | "특정 패턴 미감지" |
5) Coding Patterns (Sampled) — 핵심 파일 샘플링:
진입점 파일 중 가장 작은 파일 1~2개를 실제로 읽어 코딩 패턴을 추출한다.
추출 항목:
제약:
src/ 또는 lib/ 내 가장 작은 파일 선택Create devflow-docs/inception/workspace.md:
# Workspace Analysis
**Detected**: [Greenfield | Brownfield]
**Timestamp**: [ISO 8601]
**Project Root**: [현재 작업 디렉토리 절대 경로]
**Requires Path Confirmation**: [true | false]
**Source**: [신규 분석 | 이전 분석([이전 Timestamp 값]) 기반 — 변경 없음 | 이전 분석([이전 Timestamp 값]) 기반 + 델타 업데이트]
## Project Structure
[brief description of what was found]
## Key Files Found
[list of significant files, if brownfield]
<!-- CLAUDE.md에 기술 스택이 명시되어 있을 때만 포함. 없으면 이 섹션 생략. -->
## Pre-specified Tech Stack
- **Source**: CLAUDE.md
- **Items**: [감지된 항목 목록 — 키: 값 형태로 나열]
<!-- Brownfield일 때만 포함. Greenfield는 이 섹션 없이 저장. -->
## Technology Stack
- **Language**: [언어 + 버전]
- **Framework**: [프레임워크]
- **Package Manager**: [패키지 매니저]
- **Test Framework**: [테스트 프레임워크]
- **Key Dependencies**: [주요 의존성 목록]
## Git Activity
- **Last Commit**: [날짜 — 프로젝트 활성 여부]
- **Recent Focus**: [최근 변경 집중 디렉토리/파일 top 5]
- **Recent Commits**: [최근 커밋 메시지 3~5줄 요약]
## Existing Documentation
- [감지된 문서 목록 — 각 1~2줄 요약]
## Code Structure
- **Directory Layout**: [1단계 트리]
- **Entry Points**: [진입점 파일]
- **Observed Patterns**: [관찰된 패턴 — 보이는 것만]
## Coding Patterns (Sampled)
- **Source**: [샘플링한 파일명]
- **Naming**: [네이밍 컨벤션]
- **Imports**: [import 구조]
- **Error Handling**: [에러 핸들링 패턴]
- **Comments**: [주석 스타일]
Requires Path Confirmation 기준:
true (새 프로젝트 디렉토리 위치 미확정)false (기존 코드가 있는 위치가 곧 프로젝트 루트)conventions 표준 형식. 반환 필드: