oh-my-bakedpotato

oh-my-bakedpotato

Java Spring Boot 멀티모듈 프로젝트를 위한 Claude Code 플러그인입니다.

PRD 작성, 설계, 구현, 리뷰, 커밋/PR까지 전체 개발 사이클을 에이전트 팀이 Q&A 루프로 수행합니다. 각 단계마다 사용자 확인을 거치며, PR 생성까지만 자동화합니다.

---

플러그인 설치

Claude Code에서 아래 두 명령을 실행합니다:

# 1. 마켓플레이스 등록
/plugin marketplace add rnqhstmd/oh-my-bakedpotato

# 2. 플러그인 설치
/plugin install oh-my-bakedpotato@oh-my-bakedpotato

설치 스코프를 선택할 수 있습니다:

스코프	명령	설명
user (기본)	/plugin install oh-my-bakedpotato@oh-my-bakedpotato	모든 프로젝트에서 사용
project	Discover 탭에서 project 스코프 선택	해당 repo 협업자 전체
local	Discover 탭에서 local 스코프 선택	나만 이 repo에서 사용

---

빠른 시작

이 플러그인은 대상 프로젝트의 CLAUDE.md(아키텍처, 컨벤션)와 플러그인의 .claude/(스킬, 에이전트, 규칙)가 합쳐져 동작합니다. 프로젝트 컨벤션이 플러그인의 일반 규칙보다 우선 적용됩니다.

1단계: 환경 확인

/oh-my-bakedpotato:setup

OS를 자동 감지하여 Git, GitHub CLI, JDK 21, Docker 등 필수 도구와 GH 인증을 확인합니다.

2단계: 도메인 컨텍스트 등록 (선택)

/oh-my-bakedpotato:new-context 결제

도메인의 용어, 아키텍처를 등록하면 /dev 실행 시 자동으로 매칭하여 참조합니다. 없어도 모든 스킬이 동작합니다.

3단계: 개발 시작

/oh-my-bakedpotato:dev [JIRA-123] 상품 목록 정렬 기능 추가

PRD → 설계 → 구현 → 리뷰 → 커밋/PR까지 에이전트 팀이 단계별로 수행합니다.

---

/dev: 전체 개발 사이클

호출 방법

/oh-my-bakedpotato:dev <기능/버그 설명> [옵션]

옵션	설명
(없음)	전체 사이클 (setup → requirements → design → implement → review → complete)
--phase <name>	특정 Phase만 실행 (requirements, design, implement, review, complete)
--hotfix	긴급 수정 경량 경로 (설계/리뷰 건너뜀)
--base <branch>	베이스 브랜치 지정 (미지정 시 main/develop/master 자동 감지)
--status	진행 상태 조회 (파이프라인 실행 없이 .dev/state.md 확인)
--resume	이전 작업 재개 (중단된 Step부터 계속)

플래그 제약: --hotfix와 --phase는 동시 사용 불가. --resume은 --phase, --hotfix, --status 및 작업 설명과 동시 사용 불가.

Phase별 흐름

setup → requirements → design → implement → review → complete
         (PO)        (architect  (coder     (qa-manager (PO 인수
                     + critic)  + qa 점검)  + security)  + commit/PR)

Phase	에이전트	사용자 상호작용	산출물
setup	오케스트레이터	없음	브랜치, 코드 맵, .dev/state.md
requirements	product-owner	Q&A 최대 1회 + 승인	.dev/prd.md
design	architect + design-critic (선택적)	Q&A 최대 2회 + 승인	.dev/design.md
implement	coder + qa-manager	자기점검 결과 보고	코드, .dev/self-check.md
review	qa-manager + security-auditor	CERTAIN 확인, QUESTION 답변 (최대 2회)	.dev/trust-ledger.md
complete	product-owner	인수 결과 확인 (재시도 최대 1회)	커밋, PR

setup: 작업 브랜치 생성, 프로젝트 타입 감지, 코드 맵 초기 생성, 도메인 컨텍스트 자동 매칭.

requirements: product-owner가 모호한 요청을 명확한 PRD로 변환합니다. 사용자와 Q&A 1회 후 PRD를 확정합니다.

design: architect가 PRD와 코드 맵을 기반으로 기술 설계를 작성합니다. 필요 시 design-critic(opus 모델)이 암묵적 가정을 도전하고 불필요한 복잡성을 식별합니다. 사용자 승인 후 확정됩니다.

implement: coder가 확정된 설계에 따라 코드를 구현합니다. qa-manager가 자기점검을 수행하여 스펙 충족을 확인합니다. Critical 이슈는 coder가 즉시 수정합니다.

review: qa-manager와 security-auditor가 병렬로 코드 리뷰와 보안 감사를 수행합니다. 확실한 문제(CERTAIN)는 수정하고, 확인이 필요한 사항(QUESTION)은 사용자에게 질문합니다. 최대 2회 반복합니다.

complete: product-owner가 PRD 수용 기준 대비 인수 검증을 수행합니다. 통과하면 커밋과 PR을 생성합니다.

일반 개발 vs --hotfix

항목	정상 경로	--hotfix
PRD	전체 (Q&A 포함)	경량 (배경 + 요구사항 + 수용 기준만)
설계	architect + design-critic	건너뜀 (coder가 PRD + 코드 맵으로 직접 구현)
리뷰	qa-manager + security-auditor 병렬	건너뜀
인수 검증	실행	실행 (PRD 수용 기준 대비 검증)

--hotfix: setup → requirements(경량) → implement → complete
정상:     setup → requirements → design → implement → review → complete

Phase 제어

특정 Phase만 실행하거나, 중단된 작업을 재개할 수 있습니다.

# PRD만 작성
/dev 로그인 기능 추가 --phase requirements

# 설계까지만 (requirements + design)
/dev 로그인 기능 추가 --phase design

# 현재 변경사항을 리뷰만
/dev --phase review

# 커밋/PR만
/dev --phase complete

# 진행 상태 확인
/dev --status

# 이전 작업 재개 (중단된 Step부터)
/dev --resume

--phase implement는 .dev/design.md가 필요합니다. 없으면 --phase design을 먼저 실행하라는 안내가 나옵니다.

정체 감지와 에스컬레이션

implement와 review Phase에서 반복 루프가 진전 없이 정체되면, 자동으로 에스컬레이션 에이전트를 호출합니다.

패턴	감지 기준	1차 대응	2차 대응
SPINNING	동일 에러가 2회 연속 반복	hacker: 제약 우회 분석	researcher: 근본 원인 분석
OSCILLATION	접근법 A→B→A 왕복	architect: 설계 재검토	사용자에게 두 접근법 제시
NO_DRIFT	코드 변경이 실질적으로 없음 (diff 비교)	hacker: 제약 식별 + 우회	researcher: 코드베이스 탐색
DIMINISHING_RETURNS	수정 범위가 줄어드는데 테스트/리뷰 결과 미개선	simplifier: 복잡도 분석 + 범위 축소	사용자에게 방향 전환 확인

---

개별 스킬 가이드

모든 스킬은 /oh-my-bakedpotato:<스킬명> 형식으로 호출합니다.

commit

변경사항을 스테이징하고, 브랜치명에서 타입을 파싱하여 한국어 커밋 메시지를 생성합니다.

/oh-my-bakedpotato:commit              # 자동 생성
/oh-my-bakedpotato:commit 로그인 검증 수정  # 메시지 직접 지정

핵심 동작:

• 커밋 전 프로젝트 타입 감지 후 테스트 실행 (build.gradle 존재 시 ./gradlew test, 실패 시 커밋 중단)
• 브랜치명에서 타입 파싱 (예: feat/login → feat)
• 메시지 형식: {type}: 한국어 요약 + 변경사항 bullet (예: feat: 로그인 기능 추가)
• 민감 파일(.env, credentials 등) 감지 시 경고
• 변경 파일 20개 초과 시 전체 스테이징 여부 확인
• Co-Authored-By 라인 추가 금지

pull-request

커밋 히스토리를 분석하여 PR을 자동 생성합니다.