Stats
Actions
Tags
How this skill is triggered — by the user, by Claude, or both
Slash command
/oh-my-bakedpotato:devThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
오케스트레이터. 직무 기반 Agent 팀과 Q&A 피드백 루프로 전체 개발 사이클을 관리한다.
오케스트레이터. 직무 기반 Agent 팀과 Q&A 피드백 루프로 전체 개발 사이클을 관리한다.
항상 한국어로 응답한다.
이 스킬의 파일들은 프로젝트 루트의 .claude/skills/dev/ 하위에 위치한다.
Phase 파일이나 다른 스킬을 Read할 때, 현재 작업 디렉토리(프로젝트 루트)를 기준으로 절대 경로를 구성한다.
다른 스킬의 프로세스를 실행할 때 아래 경로에서 Read한다:
<프로젝트 루트>/.claude/skills/commit/SKILL.md<프로젝트 루트>/.claude/skills/pull-request/SKILL.md<프로젝트 루트>/.claude/skills/worktree/SKILL.mdARGS[0] (필수): 기능 또는 버그 설명 (e.g., "[JIRA-123] 로그인 기능 추가")--phase requirements|design|implement|review|complete: 특정 Phase만 실행--hotfix: 긴급 버그 수정용 경량 경로. 설계/리뷰를 건너뛰되 경량 PRD와 인수 검증은 실행 (setup → requirements → implement → complete)--base <branch>: 베이스 브랜치 지정 (미지정 시 자동 감지)--status: 현재 파이프라인 진행 상태를 조회한다. 다른 플래그/인자와 함께 사용 불가.--resume: 이전 파이프라인을 명시적으로 재개한다. state.md가 없거나 completed이면 에러.ARGS[0]이 없고 --status도 --resume도 없으면 다음을 응답:
"구현할 기능이나 수정할 버그를 설명해주세요. 예: /dev [JIRA-123] 로그인 기능 추가"
--status가 지정되면 파이프라인을 실행하지 않고 현재 상태만 출력한다:
.dev/state.md를 탐색한다.## 파이프라인 상태
- 작업: {args}
- 브랜치: {branch} (base: {base})
- 프로젝트: {project-type} ({project-root})
- 현재 Phase: {phase} ({status})
- 플래그: {flags}
- 시작: {started}
### Phase 진행
- setup: {status}
- requirements: {status}
- ...
| Agent | 분류 | 역할 | 관점 | 모델 |
|---|---|---|---|---|
| product-owner | PRODUCT | PRD 작성 + 인수 검증 | "뭘 만들지" / "비즈니스 의도대로 됐나" | sonnet |
| architect | PLANNING | 설계 | "어떻게 만들지" / "구조적 일관성" | sonnet |
| design-critic | REVIEW | 설계 비판 검토 | "이 가정이 맞나" / "더 단순하게 안 되나" | opus |
| coder | EXECUTION | 구현 + 수정 | "만든다" | inherit |
| qa-manager | REVIEW | 코드 리뷰 + 스펙 충족 검증 | "스펙대로 됐나" | sonnet |
| security-auditor | REVIEW | 정책/보안/허점 감사 | "뭘 놓쳤나" | sonnet |
| researcher | ANALYSIS | 코드베이스 조사 + 기술 비교 | "이해한다" (독립 호출 전용) | sonnet |
| hacker | RECOVERY | 제약 우회 + 정체 탈출 | "다른 길이 있다" (정체 감지 시 호출) | sonnet |
| simplifier | RECOVERY | 복잡도 제거 + 범위 축소 | "더 작게 만들자" (정체 감지 시 호출) | sonnet |
| Phase | 파일 | 주 Agent | Q&A Loop |
|---|---|---|---|
| setup | 작업환경 준비 | (inline) | No |
| requirements | PRD Q&A | product-owner | Yes (max 1) |
| design | 설계 Q&A | architect + design-critic (선택적) | Yes (max 2) |
| implement | 구현 + 자기점검 | coder + qa-manager | Self-check (1회) |
| review | 검토 + 감사 | qa-manager + security-auditor (병렬) | Yes (max 2) |
| complete | 완료 | product-owner (인수) + (스킬 참조) | 인수 재시도 (max 1) |
--hotfix)긴급 버그 수정용 경량 경로. 설계/리뷰를 건너뛰지만, 경량 PRD와 인수 검증은 실행한다:
--hotfix: setup → requirements (경량) → implement → complete (인수검증 포함)
정상: setup → requirements → design → implement → review → complete
Phase에 진입할 때 반드시 해당 Phase 파일을 Read한 후 실행한다:
Read(`<프로젝트 루트>/.claude/skills/dev/phases/phase-{name}.md`)
예: phase-setup.md, phase-requirements.md, phase-design.md, phase-implement.md, phase-review.md, phase-complete.md
Phase 파일의 지시에 따라 실행하고, 완료 후 다음 Phase로 진행한다.
오케스트레이터가 관리하는 누적 문서. 관련 파일의 경로와 역할을 기록한다.
구조:
## 코드 맵: <기능 설명>
### 핵심 파일
- <파일경로:라인> → 역할 설명
- ...
### 참조 파일
- <파일경로:라인> → 역할 설명
- ...
### 설정
- <파일경로> → 역할 설명
- ...
생성: phase-setup의 Step 0.4에서 초기 맵을 생성한다.
누적: 각 agent 출력에 "탐색 추가 항목" 섹션이 있으면 해당 항목을 맵에 append한다. 누적 맵은 최대 25개로 제한한다. 초과 시 참조 파일부터 제거한다.
저장: 코드 맵이 갱신될 때마다 .dev/codemap.md에 Write한다.
전달: 모든 agent 호출 시 현재 코드 맵을 프롬프트에 포함한다.
security-auditor의 감사 결과를 누적하는 문서. 오케스트레이터가 관리한다.
구조:
## Trust Ledger
### 통합 감사 (review)
- [분류/심각도] 항목 설명
- 근거: ...
- 권고: ...
생성: phase-review에서 ZT 통합 감사 완료 시 생성.
저장: .dev/trust-ledger.md에 저장한다.
전달: PR 본문에 감사 결과 요약으로 포함한다.
phase-setup에서 결정된 변수를 이후 모든 Phase에서 사용한다:
GIT_PREFIX: 항상 git. 소비 프로젝트 루트에서 직접 실행한다.PROJECT_ROOT: 항상 ./ (현재 디렉토리). worktree 사용 시에는 worktree 경로 기준.DIFF_FILE: 변경사항 diff를 저장하는 파일 경로. .dev/diff.txt. Diff 수집 규칙에 따라 phase-implement(자기점검), phase-review, phase-complete에서 갱신된다.DOMAIN_CONTEXT: phase-setup 0.3에서 context/*/PROJECTS.md 매칭으로 로드된 도메인 용어(glossary)와 아키텍처 정보. 매칭되지 않으면 빈 상태.PROJECT_ROOT 경로를 항상 전달하여 파일 도구(Read/Write/Edit/Glob/Grep)의 기준점으로 사용하게 한다../gradlew, npm, pytest 등)을 PROJECT_ROOT에서 실행할 때, Bash 작업 디렉토리가 변경되지 않도록 서브셸을 사용한다: (cd ${PROJECT_ROOT} && ./gradlew build). 괄호 ()로 감싸면 서브셸에서 cd가 실행되어 부모 셸의 작업 디렉토리가 유지된다.--base가 지정되었으면 해당 브랜치를 사용한다. 미지정이면 자동 감지:
git branch --list main master develop로 존재하는 브랜치를 확인한다.main이 존재하면 → 베이스로 자동 선택.main이 없으면 → 존재하는 develop/master를 선택지로 사용자에게 제시한다 (AskUserQuestion). 하나도 없으면 직접 입력을 요청한다.확정된 베이스 브랜치를 이후 phase-review (diff 계산), phase-complete (PR 생성)에서 사용한다.
Agent prompt 크기를 관리하기 위해:
Agent 출력을 사용자에게 전달할 때, Phase 상태에 따라 전문 표시 여부를 결정한다:
이후 Phase에서 이전 산출물이 필요하면 파일을 Read하여 Agent prompt에 포함하되, 오케스트레이터 자신의 출력에는 포함하지 않는다. 각 Phase 파일에서 구체적인 요약 포맷을 정의한다.
.dev/prd.md에 저장한다..dev/design.md에 저장한다..dev/trust-ledger.md에 저장한다..dev/codemap.md에 저장한다 (갱신 시마다)..dev/self-check.md에 저장한다 (phase-implement 자기점검 완료 시)..gitignore 보강은 phase-setup의 Step 0.5a에서 프로젝트 타입별로 처리한다 (.dev/ 포함).파이프라인 진행 상태를 .dev/state.md에 기록하여 세션 재개를 지원한다.
state.md 구조:
phase: implement
status: in_progress
branch: JIRA-123
base: main
project-type: kotlin-gradle
project-root: ./
args: "[JIRA-123] 로그인 기능 추가"
flags: --hotfix
started: 2026-02-17T10:30:00
current-step: "자기점검"
phases:
setup: completed
requirements: completed
design: completed
implement: in_progress
steps:
implement:
- coder 구현: completed
- 자기점검: in_progress
review:
- mechanical-gate: pending
- qa-review-1: pending
execution-log:
- phase: implement
agent: coder
result: completed
steps-reported: 5/5
- phase: implement
agent: qa-manager (자기점검)
result: "Critical 1건, Warning 2건"
- phase: implement
agent: coder (수정)
result: "Critical 1건 해소"
- phase: review
step: mechanical-gate
result: "build ✓, test ✓"
- phase: review
agent: qa-manager
result: "CERTAIN 0건, QUESTION 1건"
- phase: review
agent: security-auditor
result: "CRITICAL 0건"
갱신 규칙:
phase: {name}, phases.{name}: in_progress로 갱신.phases.{name}: completed로 갱신.current-step과 steps 갱신.--resume 시 current-step에서 재개한다 (Phase 처음부터가 아닌 중단 Step부터).execution-log에 엔트리 추가 (agent명, result 요약).execution-log에 기록한다.execution-log 엔트리에 stagnation: {패턴} 필드를 추가한다.status: completed로 갱신.설계서와 PRD를 Agent에게 전달할 때, 역할에 따라 필요한 섹션만 전달하여 컨텍스트 효율을 높인다:
DIFF_FILE) + 코드 맵--hotfix이면 설계서 대신 PRD + 코드 맵.DIFF_FILE) + 코드 맵각 에이전트에 전달하는 입력 크기가 .claude/config.json의 contextLimits를 초과하면, 우선순위가 낮은 섹션부터 요약 또는 생략한다.
읽기 전용 Agent(product-owner, architect, design-critic, qa-manager, security-auditor, researcher, hacker, simplifier)는 서로 병렬 실행이 가능하다. 병렬 실행 시:
Task() 호출을 동시에 발행한다.phase-implement(구현→자기점검 루프)와 phase-review(QA→수정→재리뷰 루프)에서 적용한다. 각 루프의 최대 반복은 기존과 동일하다. 정체 감지 시 반복을 소진하지 않고 에스컬레이션으로 전환한다.
| 패턴 | 감지 기준 | 유형 |
|---|---|---|
| SPINNING | 동일 에러 메시지가 2회 연속 반복 | 기계적 (텍스트 비교) |
| OSCILLATION | 접근법 A→B→A 왕복이 감지됨 | 정성적 (LLM 판단) |
| NO_DRIFT | 이전 반복과 비교해 코드 변경이 실질적으로 없음 (diff 비교) | 반기계적 (diff stat) |
| DIMINISHING_RETURNS | 수정 범위가 줄어드는데 테스트/리뷰 결과가 개선되지 않음 | 정성적 (LLM 판단) |
| 감지 패턴 | 1차 대응 | 2차 대응 (1차 실패 시) |
|---|---|---|
| SPINNING | hacker에 제약 우회 분석 위임 | researcher에 근본 원인 분석 위임 |
| OSCILLATION | architect에 설계 재검토 요청 | 사용자에게 두 접근법 제시, 선택 요청 |
| NO_DRIFT | hacker에 제약 식별 + 우회 경로 요청 | researcher에 코드베이스 탐색 위임 |
| DIMINISHING_RETURNS | simplifier에 복잡도 분석 + 범위 축소 요청 | 사용자에게 현재 상태 보고, 방향 전환 여부 확인 |
phase-review.md의 Step 3~4에 정의. QA + ZT 결과를 합산하고 심각도별로 처리한다.
Agent에게 변경사항 diff를 전달할 때, 메인 컨텍스트 절약을 위해 파일 리다이렉트 + 경로 전달을 사용한다.
핵심 원칙: diff 출력이 Bash 결과로 메인 컨텍스트에 진입하지 않도록, 셸 리다이렉트로 파일에 직접 쓴다.
DIFF_FILE = .dev/diff.txt. 매 수집 시 mkdir -p .dev를 실행하여 디렉토리 존재를 보장한다.git diff --cached > .dev/diff.txt
wc -l < .dev/diff.txt로 줄 수를 확인한다.--stat 요약을 파일 앞에 추가하고, 파일 끝에 "변경된 파일을 Read 도구로 직접 확인하라"는 안내를 추가한다:
git diff --cached --stat > .dev/diff.txt
echo "---" >> .dev/diff.txt
echo "위는 요약입니다. 변경된 파일을 Read 도구로 직접 확인하라." >> .dev/diff.txt
변경사항 diff: .dev/diff.txt
이 파일을 Read하여 변경사항을 확인하라.
이 규칙은 모든 diff 패턴에 적용한다: git diff --cached (스테이징), git diff <base>...HEAD (브랜치 비교) 등. 브랜치 비교 시에는 해당 diff 명령으로 리다이렉트한다.
--hotfix와 --phase는 동시 사용 불가. 둘 다 있으면: "--hotfix와 --phase는 동시에 사용할 수 없습니다." 에러 후 중단.--resume과 --phase, --hotfix, --status는 동시 사용 불가. 함께 있으면: "--resume은 다른 모드 플래그와 동시에 사용할 수 없습니다." 에러 후 중단.--resume은 ARGS[0] 없이 단독 사용한다. ARGS[0]이 함께 있으면: "--resume은 작업 설명 없이 단독으로 사용합니다." 에러 후 중단.--phase가 지정되면 해당 Phase만 실행한다:
--phase requirements: setup (필요 시) + requirements만 실행 (PRD 작성).--phase design: setup (필요 시) + requirements + design만 실행. 대화 맥락에 요구사항이 없고 .dev/prd.md도 없으면 requirements부터 시작.--phase implement: 환경 감지 + implement 실행. 대화 맥락에 설계서가 없고 .dev/design.md도 없으면: "설계서가 필요합니다. /dev --phase design을 먼저 실행하거나 설계 내용을 입력해주세요." 후 중단.--phase review: 환경 감지 + 베이스 브랜치 감지 + review 실행 (현재 변경사항을 리뷰).--phase complete: 환경 감지 + 베이스 브랜치 감지 + complete 실행 (test, commit, PR).환경 감지: 위 3개 모드는 phase-setup을 건너뛰므로, Phase 진입 전에 다음을 수행한다:
git rev-parse --is-inside-work-tree로 git repo 확인.PROJECT_ROOT= 현재 디렉토리. 완료.
./gradlew test, npm test, npm install 등)에는 timeout: 300000(5분)을 설정한다.npx claudepluginhub rnqhstmd/oh-my-bakedpotato --plugin oh-my-bakedpotatoAutomates the full development lifecycle: analysis, design check, implementation, testing, commit, and PR creation. Responds to Korean natural language commands like '이거 만들어줘'.
Routes sessions in long-task projects to the correct phase skill by checking files like bugfix-request.json, feature-list.json, design docs, and codebase state.