메뉴
yogieat-server 기능 개발 전체 워크플로우를 자동화하는 오케스트레이터. 새 기능, API 추가, 도메인 확장 요청 시 분석 → 구현 → QA 파이프라인을 실행한다. '기능 추가', '도메인 만들어', 'API 구현', '새로운 엔드포인트', 'CRUD 만들어', '~기능 개발해줘' 등의 요청에 반드시 이 스킬을 사용할 것.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when deciding whether a Yogieat prompt should stay on the main thread or consider repo-local agents. Classifies prompts, maps them to `feature_mapper`, `architecture_guard`, `validation_triager`, or `harness_curator`, and keeps delegation intentionally minimal.
Use when deciding where new Yogieat code belongs or when reviewing architecture drift. Focuses on Service vs Facade boundaries, validator extraction, processor naming, transaction placement, dependency minimization, and preserving the existing multi-module structure.
Use when adding or extending a Yogieat feature in the Java 25 multi-module Spring Boot architecture. Maps the request to the smallest consistent slice across `apps:api/admin`, `apps:domain`, `storage`, `external`, and `support` while preserving the current Service, Facade, Processor, and Validator conventions.
Use when repeated Yogieat prompts, review comments, or misunderstandings should be translated into harness candidates or stable rules. Classifies new observations, applies the candidate-to-promotion policy, and keeps harness updates intentional rather than noisy.
Use when validating Yogieat changes or choosing the smallest Java 25 Gradle proof command. Applies Spotless first, then compile, then module-local or full tests based on repo-specific escalation rules.
Use when writing, refactoring, or reviewing Yogieat tests. Focuses on behavior-first assertions, boundary-only mocking, test layer choice, and smell detection for spy-heavy or verify-heavy tests.
| name | yogieat-develop |
| description | yogieat-server 기능 개발 전체 워크플로우를 자동화하는 오케스트레이터. 새 기능, API 추가, 도메인 확장 요청 시 분석 → 구현 → QA 파이프라인을 실행한다. '기능 추가', '도메인 만들어', 'API 구현', '새로운 엔드포인트', 'CRUD 만들어', '~기능 개발해줘' 등의 요청에 반드시 이 스킬을 사용할 것. |
yogieat-server의 멀티모듈 클린 아키텍처에 맞게 기능을 개발하는 전체 워크플로우를 조율한다.
파이프라인 패턴. 각 Phase의 산출물이 다음 Phase의 입력이 된다.
| 에이전트 | subagent_type | 역할 | 출력 |
|---|---|---|---|
| architect | architect | 요구사항 분석 + 구현 계획 수립 | _workspace/01_architect_plan.md |
| implementor | implementor | 멀티모듈 코드 구현 | 코드 파일 생성/수정 |
| qa-inspector | qa-inspector | 통합 정합성 검증 + 빌드 | _workspace/04_qa_report.md |
_workspace/ 디렉토리를 생성한다architect 에이전트를 호출하여 구현 계획을 수립한다.
Agent(
description: "기능 설계",
subagent_type: "architect",
model: "opus",
prompt: "다음 기능 요구사항에 대한 구현 계획을 수립하라.
요구사항: {사용자 요구사항}
프로젝트 루트: /Users/yunbeom/ybcha/nexters/yogieat-server
1. 기존 코드베이스에서 유사 도메인 패턴을 탐색하라
2. 영향받는 모듈과 생성/수정할 파일을 full package path로 명시하라
3. 의존성 방향 위반이 없는지 확인하라
4. 결과를 _workspace/01_architect_plan.md에 저장하라"
)
계획 산출물을 Read하여 합리성을 검토한다. 문제가 있으면 사용자에게 확인 후 수정.
implementor 에이전트를 호출하여 코드를 구현한다.
Agent(
description: "코드 구현",
subagent_type: "implementor",
model: "opus",
prompt: "architect의 구현 계획에 따라 코드를 구현하라.
프로젝트 루트: /Users/yunbeom/ybcha/nexters/yogieat-server
구현 계획: _workspace/01_architect_plan.md를 Read하라
구현 가이드: .claude/skills/spring-multimodule-implement/SKILL.md를 Read하라
구현 순서를 반드시 따르라:
domain model → repository interface → service → facade → entity → core repository → controller + DTO → tests
구현 완료 후 ./gradlew spotlessApply를 실행하라"
)
qa-inspector 에이전트를 호출하여 통합 정합성을 검증한다.
Agent(
description: "QA 검증",
subagent_type: "qa-inspector",
model: "opus",
prompt: "구현된 코드의 멀티모듈 통합 정합성을 검증하라.
프로젝트 루트: /Users/yunbeom/ybcha/nexters/yogieat-server
QA 체크리스트: .claude/skills/yogieat-qa/SKILL.md를 Read하라
구현 계획: _workspace/01_architect_plan.md를 참조하라
git diff로 변경된 파일을 확인하고 6가지 검증을 수행하라.
결과를 _workspace/04_qa_report.md에 저장하라"
)
QA 리포트를 Read한다. FAIL 항목이 있으면:
Agent(
description: "QA 위반 수정",
subagent_type: "implementor",
model: "opus",
prompt: "QA 검증에서 다음 위반이 발견되었다. 수정하라.
{QA 리포트의 FAIL 항목 전문}
수정 완료 후 ./gradlew spotlessApply를 실행하라"
)
_workspace/ 디렉토리는 보존한다 (사후 검증용)사용자 요구사항
↓
[architect] → _workspace/01_architect_plan.md
↓
[implementor] → 코드 파일 생성/수정
↓
[qa-inspector] → _workspace/04_qa_report.md
↓ (FAIL 시)
[implementor] → 수정 ←→ [qa-inspector] → 재검증 (최대 2회)
↓
결과 요약 → 사용자
| 상황 | 전략 |
|---|---|
| architect 실패 | 사용자에게 요구사항 명확화 요청 |
| implementor 컴파일 에러 | QA에서 에러 메시지 수집 → implementor 재호출 |
| QA 경계면 위반 | 구체적 위반 사항 → implementor 수정 (최대 2회) |
| 2회 수정 후에도 FAIL | 남은 이슈를 사용자에게 보고, 수동 해결 제안 |
| gradle 타임아웃 | 빌드 스킵, 경계면 검증만 수행 후 보고 |
@Entity import 추가