skills/peach-setup-harness/SKILL.md
대상 프로젝트에 피치 하네스 시스템을 설정합니다. CLAUDE.md를 최소 진입점으로 정리하고, AGENTS.md를 95~130줄 규모로 생성/업데이트합니다. Use when: "하네스 설정", "프로젝트 초기 설정", "CLAUDE.md 정리", "AGENTS.md 업데이트", "세션 시작 설정" 키워드.
npx skillsauth add peachsolution/peach-harness peach-setup-harnessInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
대상 프로젝트의 CLAUDE.md와 AGENTS.md를 하네스 시스템에 맞게 설정한다. CLAUDE.md는 20줄 이내 최소 진입점, AGENTS.md는 95~130줄 핵심 규칙.
하네스 시스템 설정 전문가. CLAUDE.md에서 AGENTS.md와 중복되는 내용을 제거하고, AGENTS.md 5개 섹션을 점검하여 누락 시 보완한다. cursor rules는 삭제한다.
다음을 확인한다:
# CLAUDE.md 존재 여부 + 내용
cat CLAUDE.md 2>/dev/null || echo "CLAUDE.md 없음"
# AGENTS.md 존재 여부 + 내용
cat AGENTS.md 2>/dev/null || echo "AGENTS.md 없음"
# 프로젝트 구조 감지
ls -d api/ front/ 2>/dev/null || echo "모노레포 아님"
# Controller 프레임워크 감지 (Koa vs Elysia)
head -3 api/src/modules/test-data/controller/test-data.controller.ts 2>/dev/null || echo "controller 없음"
# DAO 라이브러리 감지 (bunqldb vs sql-template-strings)
head -5 api/src/modules/test-data/dao/test-data.dao.ts 2>/dev/null || echo "dao 없음"
# DB 종류 감지
grep -i "host\|database\|mysql\|postgres" api/env.local.yml 2>/dev/null | head -5 || echo "env.local.yml 없음"
# cursor rules 존재 여부
ls api/.cursor/rules/ 2>/dev/null && echo "api cursor rules 존재" || echo "api cursor rules 없음"
ls front/.cursor/rules/ 2>/dev/null && echo "front cursor rules 존재" || echo "front cursor rules 없음"
ls .cursor/rules/ 2>/dev/null && echo "root cursor rules 존재" || echo "root cursor rules 없음"
ls .cursorrules 2>/dev/null && echo ".cursorrules 존재" || echo ".cursorrules 없음"
분석 결과를 정리:
api/ + front/ 모노레포 / 단독 api/ / 단독 front/AGENTS.md가 존재하는 경우, 아래 5개 섹션이 있는지 확인한다:
grep -l "공통 원칙\|_common.*import" AGENTS.md 2>/dev/null && echo "§1.공통원칙 존재" || echo "§1.공통원칙 누락"
grep -l "백엔드 규칙\|ErrorHandler" AGENTS.md 2>/dev/null && echo "§2.백엔드 존재" || echo "§2.백엔드 누락"
grep -l "프론트엔드 규칙\|computed" AGENTS.md 2>/dev/null && echo "§3.프론트엔드 존재" || echo "§3.프론트엔드 누락"
grep -l "테스트\|TDD" AGENTS.md 2>/dev/null && echo "§4.테스트 존재" || echo "§4.테스트 누락"
grep -l "Bounded Autonomy\|Must Follow" AGENTS.md 2>/dev/null && echo "§5.BA 존재" || echo "§5.BA 누락"
누락 섹션 발견 시 아래 references를 소스로 사용한다:
| 섹션 | 소스 파일 |
|------|---------|
| 1. 공통 원칙 | peach-setup-harness/references/01-common.md |
| 2. 백엔드 규칙 (Koa) | peach-setup-harness/references/02-backend-koa.md |
| 2. 백엔드 규칙 (Elysia) | peach-setup-harness/references/02-backend-elysia.md |
| 3. 프론트엔드 규칙 | peach-setup-harness/references/03-frontend.md |
| 4. 테스트 및 품질 | peach-setup-harness/references/04-testing.md |
| 5. Bounded Autonomy | peach-setup-harness/references/05-bounded-autonomy.md |
Koa/Elysia 분기: 02번 파일 선택만으로 처리
01 + 02-backend-koa + 03 + 04 + 0501 + 02-backend-elysia + 03 + 04 + 05Elysia 감지 시 추가 확인:
grep -l "Plugin System\|try-catch 금지" AGENTS.md 2>/dev/null && echo "Elysia 규칙 존재" || echo "Elysia 규칙 누락"
누락 섹션 목록을 기록한다.
선택 섹션 (api/ 존재 시):
# DB 데이터 확인 섹션 존재 여부
grep -l "개발 DB 데이터 확인\|psql.*DATABASE_URL\|peach-db-query" AGENTS.md 2>/dev/null && echo "§6.DB조회 존재" || echo "§6.DB조회 누락"
peach-setup-harness/references/06-db-query.md 소스로 추가사용자에게 변경 계획을 제시한다:
CLAUDE.md 변경:
AGENTS.md 변경:
cursor rules 삭제 (존재하는 경우):
변경 계획에 대해 사용자 동의를 받는다. 수정 요청이 있으면 반영한다.
승인 후 변경을 적용한다:
CLAUDE.md 정리
AGENTS.md 생성 또는 업데이트
cursor rules 삭제 (존재하는 경우)
api/.cursor/rules/ 디렉토리 삭제front/.cursor/rules/ 디렉토리 삭제.cursor/rules/ 디렉토리 삭제.cursorrules 파일 삭제적용 결과를 출력한다:
AGENTS.md를 새로 생성하거나 보완할 때 아래 원칙을 적용한다.
핵심: "가이드 코드가 말 못하는 것만 남긴다." 스킬 미사용 케이스를 별도로 고려하지 않는다.
유지 (4가지 카테고리):
| 카테고리 | 내용 |
|---------|------|
| 금지사항 | _common만 import, FK 금지, 도메인 핵심 타입의 불필요한 옵셔널/null/undefined 금지, try-catch 금지(Elysia), isLoading 금지 |
| 설계 철학 | 에러 처리(200+success:false / ErrorHandler), 완전 독립 도메인, TDD/실DB/모킹 금지 |
| 컨벤션 | 네이밍 4종(snake_case/kebab-case/PascalCase/camelCase), PK seq 접미사, 감사 칼럼, DB Boolean CHAR(1) |
| 포인터 | 가이드 코드 경로, 품질 검증 명령어, DB 마이그레이션 명령어 |
제거:
파일 경로 참조 1줄로 대체목표 크기: 95~130줄 (5섹션 풀스택 구성: 공통+백엔드+프론트+테스트+자율성. 4섹션 단독 구성인 peach-setup-ui-proto는 70~90줄)
대상 프로젝트의 CLAUDE.md를 아래 형식으로 정리한다. 프로젝트별 고유 지침은 별도 섹션으로 보존한다.
# {프로젝트명}
{한 줄 설명}
## 규칙 참조
모든 개발 규칙은 @AGENTS.md 를 참조하라.
## 세션 시작
`git status && git branch`로 현재 상태를 확인하세요.
## 가이드 코드
코드 생성 = **가이드 코드 참조(기본 골격)** → 도메인 분석 → 더 나은 구조라면 AI 자율 조정 → Adapt 사유 기록
- Backend: `api/src/modules/test-data/`
- Frontend: `front/src/modules/test-data/`
> 가이드 코드는 강제 표준이 아니다. "단일 사용처 추상화 금지" 원칙이 가이드 패턴보다 우선한다.
> 상세 원칙은 `peach-setup-harness/references/05-bounded-autonomy.md` 참조.
Backend: api/src/modules/test-data/ + Frontend: front/src/modules/test-data/Frontend: front/src/modules/test-data/기본:
추가:
tools
기능 브랜치용 git worktree 라이프사이클을 관리하는 스킬. 생성(create) / 상태 진단(status) / PR 준비(finish) / 병합 후 정리(closeout) / 정리(cleanup) 모드를 자동 판단한다. "워크트리 만들어줘", "worktree 생성", "워크트리 정리", "워크트리 삭제", "기능 브랜치 워크트리", "워크트리 상태", "마무리", "PR 생성", "PR 머지 후 정리", "feature worktree" 키워드로 트리거. PR 전 base 비교와 안전한 동기화 필요 여부를 진단한다. 개발 완료 후 finish/closeout 모드에서는 한 번의 통합 체크포인트로 push/PR/merge/cleanup을 안전하게 진행한다.
development
Karpathy LLM Wiki 패턴 기반 지식 관리 스킬. 코드 프로젝트와 옵시디언 노트 모두 지원. Raw Source(코드·문서)를 읽어 docs/wiki/에 누적형 지식베이스를 구축·유지한다. "wiki", "위키", "ingest", "인제스트", "wiki 점검", "wiki lint", "wiki 업데이트", "문서화해줘", "아키텍처 설명해줘", "어떻게 동작해?" 키워드로 트리거. qmd 검색 도구와 연동하여 토큰 절약 + 높은 검색 정확도 제공.
development
Backend 없이 Mock 데이터 기반 프로토타입 UI를 생성·검증하는 기획 구체화 산출물 스킬. Vue 3 + TypeScript + NuxtUI v4. 별도 ui-proto 저장소(예: peach-ui-proto-backoffice)의 src/modules-task 폴더에 태스크별 화면을 누적한다. "프로토타입 만들어줘", "Mock 화면", "proto UI", "기획 화면 빠르게", "ui-proto 작업", "기획자 검토용 화면", "태스크 폴더 추가", "팀 ui-proto" 키워드로 트리거. 기획자가 직접 작업하는 화면 기획 + 현업 검토용 산출물 스킬이며, 개발용 Spec은 후속 peach-gen-spec이 생성한다. 실제 API 연동이 필요하면 peach-gen-ui를 사용한다.
development
Spec 필수 + ui-proto 보조 기준으로 E2E 환경 세팅 + 단위 시나리오 자동 분할 + 통합 suite 생성 + 실행 + 부합 검증을 한 번에 처리하는 통합 팀 스킬. "e2e 검증해줘", "통합 검증", "전체 흐름 테스트", "팀 e2e", "스펙대로 동작하는지 확인", "ui-proto와 다른지 확인", "최종 검증", "릴리스 전 검증" 키워드로 트리거. peach-e2e-setup + peach-e2e-scenario + peach-e2e-suite 3개 스킬의 패턴을 공유하고, 검증 기준은 본 프로젝트 Spec을 필수 기준으로 삼고, ui-proto는 화면/흐름 보조 기준으로 사용한다. peach-team-dev와 함께 하나의 개발-검증 납품 흐름을 이루되, 구현 컨텍스트와 검증 컨텍스트는 분리한다. 팀 실행 방식은 E2E 범위와 런타임 도구 가용성을 분석해 single-agent / role-queue / agent-team 중 선택한다. 단순 코드 동작 검증을 넘어, 기획 의도와 부합하는지 자동 검증하는 게 핵심 차별점.