[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QZ84KBZM18A33VG4PPB26X":3,"skill-same:01M6QZ84KBZM18A33VG4PPB26X":67},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6QZ84KBZM18A33VG4PPB26X","mvp-loop-protocol",null,"MVP 개발 루프(Stage 4) 운영 프로토콜. 매 반복 표준 사이클(스토리 선택→메인 세션 구현→\nmvp-verifier 반증→verified 마커→passes:true→progress 갱신→일괄 커밋), \u002Fmvp-run 재개 프로토콜\n4단계, 정지조건 3결합(결정론 게이트+verified 마커+completion promise), 환경변수 튜닝\n(LOOP_TEST_CMD·LOOP_PROMISE·LOOP_MAX_ITER·LOOP_MAX_MINUTES), loop-active 플래그 수명주기,\n가드레일 5종, BLOCKED.md 에스컬레이션을 정의한다. \u002Fmvp-run으로 루프를 시작·재개할 때,\n중단된 루프를 복구할 때, 가드레일 기본값을 조정할 때, BLOCKED 상태를 처리할 때 참조.\nOperating protocol for the MVP dev loop (Stage 4): the per-iteration cycle, the \u002Fmvp-run\nresume protocol, stop conditions, env-var tuning (LOOP_TEST_CMD, LOOP_PROMISE,\nLOOP_MAX_ITER, LOOP_MAX_MINUTES), loop-active flag lifecycle, 5 guardrails, and BLOCKED.md\nescalation. Use when: starting or resuming via \u002Fmvp-run, recovering an interrupted loop,\ntuning guardrails, or handling BLOCKED state.","Dokkabei97\u002Fdokkabei-harness","Dokkabei97","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F69792585?v=4","01M6QYPVTYK6CGF609W541QNSD","JangMK","01M6QYPVYXBP1GRYHZ7ZABCZC6",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Farchive\u002Fmvp\u002Fskills\u002Fmvp-loop-protocol\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"protocol","mvp loop protocol","mvp","loop","tuning","escalation","stop","max","cycle","promise","active","iteration","verifier","progress","operating","Guardrails","verified","for","when","run","2026-11-10 10:12:30",false,"---\nname: mvp-loop-protocol\ndescription: |\n  MVP 개발 루프(Stage 4) 운영 프로토콜. 매 반복 표준 사이클(스토리 선택→메인 세션 구현→\n  mvp-verifier 반증→verified 마커→passes:true→progress 갱신→일괄 커밋), \u002Fmvp-run 재개 프로토콜\n  4단계, 정지조건 3결합(결정론 게이트+verified 마커+completion promise), 환경변수 튜닝\n  (LOOP_TEST_CMD·LOOP_PROMISE·LOOP_MAX_ITER·LOOP_MAX_MINUTES), loop-active 플래그 수명주기,\n  가드레일 5종, BLOCKED.md 에스컬레이션을 정의한다. \u002Fmvp-run으로 루프를 시작·재개할 때,\n  중단된 루프를 복구할 때, 가드레일 기본값을 조정할 때, BLOCKED 상태를 처리할 때 참조.\n  Operating protocol for the MVP dev loop (Stage 4): the per-iteration cycle, the \u002Fmvp-run\n  resume protocol, stop conditions, env-var tuning (LOOP_TEST_CMD, LOOP_PROMISE,\n  LOOP_MAX_ITER, LOOP_MAX_MINUTES), loop-active flag lifecycle, 5 guardrails, and BLOCKED.md\n  escalation. Use when: starting or resuming via \u002Fmvp-run, recovering an interrupted loop,\n  tuning guardrails, or handling BLOCKED state.\n---\n\n# MVP Loop Protocol\n\nmvp-orchestrator의 Stage 4(개발 루프)를 운영하는 단일 규약. 루프 엔진은 Stop훅\n(`${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Fmvp-loop-stop-hook.sh`)이며, 완료 판정의 주체는 모델이 아니라\n훅이다(\"Completion lives outside the model\"). 이 스킬은 매 반복의 행동 순서, 중단·재개 절차,\n정지조건과 가드레일의 동작·튜닝법을 규정한다.\n\n## When to Apply\n\n다음 상황에서 이 프로토콜을 참조한다:\n- `\u002Fmvp-run`으로 개발 루프를 시작하거나, 중단된 루프를 재개할 때 (재개 프로토콜 4단계)\n- 루프가 가드레일(max-iter·no-progress·시간 상한)로 멈췄거나 `status: paused`에서 복구할 때\n- `LOOP_MAX_ITER`·`LOOP_MAX_MINUTES` 등 가드레일 기본값을 프로젝트 규모에 맞게 튜닝할 때\n- 스토리가 BLOCKED 처리되어 에스컬레이션(스코프 재협상 vs 구조 재설계)을 판단할 때\n- `loop-active` 플래그가 잔존하여 세션 종료가 비정상적으로 차단될 때 (수동 해제)\n- prd-guard·test-guard 훅이 작업을 차단(exit 2)한 이유를 해석할 때\n\n## .planning\u002F 메모리 레이아웃\n\n상태는 컨텍스트가 아니라 디스크에 둔다. 모든 경로는 프로젝트 루트 기준 상대경로다.\n\n```\n.planning\u002F\n├── mvp-{id}.md       # 마스터: ## Goal(불변) \u002F ## Stage \u002F ## Gates(승인 스탬프) \u002F ## Checklist\n│                     #        \u002F ## Iteration \u002F ## Feedback + status: in_progress|paused|blocked|done\n├── prd.md            # G1 승인본\n├── prd.json          # {\"stories\":[{\"id\":\"S-01\",\"title\":...,\"acceptance\":[...],\"passes\":false}]}\n├── design-spec.md    # [story: S-xx] 태그\n├── stack-decision.md # G2 기록(후보·트레이드오프·선택·근거)\n├── gate-cmd          # 결정론 게이트(단위\u002F통합) 명령 1줄(tech-architect 기록, 훅이 로드)\n├── e2e-gate-cmd      # (선택) E2E 수용 게이트 명령 1줄 — 있으면 all-passes 도달 시 1회 실행, 없으면 미적용\n├── progress.md       # 반복 로그 1줄\u002F회 + \u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>\n├── loop-state.json   # {iteration, last_fail_sig, started_at(epoch 초), max_iter, max_minutes}\n├── loop-active       # 루프 가동 플래그(빈 파일) — \u002Fmvp-run 생성, 훅 종료 경로에서 삭제\n├── verified\u002F         # mvp-verifier 승인 마커 S-01, S-02 ...\n└── BLOCKED.md        # 시도·차단 원인·권장 다음 행동\n```\n\n## 매 반복 표준 사이클\n\n한 반복 = 스토리 정확히 1개. 단계와 산출 파일을 건너뛰거나 순서를 바꾸지 않는다.\n\n| # | 단계 | 수행 주체 | 명령·파일 |\n|---|------|----------|-----------|\n| 1 | 스토리 선택 | 메인 세션 | `jq -r '[.stories[] \\| select(.passes == false)][0].id' .planning\u002Fprd.json` — 미완(passes:false) 최우선 스토리 **1개만** |\n| 2 | 구현 | 메인 세션(`mvp-builder` 규율 체화) | 테스트 먼저 → 최소 구현 → `.planning\u002Fgate-cmd`의 명령으로 게이트 그린 확인. **passes 직접 마킹 금지**. 예외: 병렬 feature 구현 시에만 `mvp-builder`를 worktree 격리 서브에이전트로 디스패치(코드 작성까지만 — 커밋·마킹은 메인 세션 통합 시) |\n| 3 | 반증 | `mvp-verifier` 디스패치 | AC 반증 시도: 엣지케이스 직접 실행, 테스트가 AC를 실제 검증하는지, assertion 약화·skip·삭제 사기 적발, gate-cmd 독립 재실행 |\n| 4 | verified 마커 | `mvp-verifier` | 반증 **실패 시에만** `.planning\u002Fverified\u002F{story-id}` 생성(내용 = 반증 시도 요약). 반증 성공 시 마커 없이 지적 사항 반환 → 2단계로 회귀 |\n| 5 | passes:true | 메인 세션 | 마커 확인 후 `.planning\u002Fprd.json`의 해당 스토리 `passes`를 true로 갱신. prd-guard 훅(PostToolUse)이 마커 존재를 재검사 — 없으면 jq로 false 되돌림 + exit 2 |\n| 6 | progress 갱신 | 메인 세션 | `.planning\u002Fprogress.md`에 1줄 추가: `iter N \\| S-xx verified \\| passes n\u002Fm`. 마스터 파일 Checklist·Iteration·Feedback도 동기 갱신 |\n| 7 | 커밋 | 메인 세션 | `git add -A && git commit -m \"feat(mvp): S-xx \u003C변경 요지>\"` — **커밋 1회에 구현+prd.json+progress.md 일괄 포함**, descriptive 커밋, 스토리 id 필수 |\n\n전 스토리 `passes:true` 도달 시 **(E2E 수용 게이트 적용 프로젝트)**: promise 기록 전에 먼저\n`.planning\u002Fe2e-gate-cmd`(또는 `\u002Fe2e`)를 직접 실행해 전체 유저플로우가 동작하는지 확인한다.\n- E2E 그린 → progress.md 마지막 줄에 `\u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>`를 정확히 기록(앞뒤 변형 금지)하고 마스터 `status: done`으로 전환 → Stop훅이 정지조건(① ∧ ②ᴱ ∧ ③)을 재검사하고 종료를 허용한다.\n- E2E 레드 → promise를 기록하지 않는다. 깨진 플로우를 커버하는 스토리를 보완(필요 시 PS에 E2E 스토리 추가 요청)해 다시 단위 그린 → E2E 그린을 만든다. 성급히 promise를 적어도 Stop훅이 E2E 재검사로 종료를 차단한다.\n\nE2E 게이트 미적용(`e2e-gate-cmd` 없음) 프로젝트는 전 스토리 `passes:true` 도달 즉시 promise를\n기록하면 된다(기존 동작과 동일). promise 정확 기록 + 마스터 `status: done` 후 Stop훅이 종료를 허용한다.\n\n## 재개 프로토콜 (4단계)\n\n루프가 어떤 이유로든 끊긴 뒤(`\u002Fmvp-run` 재실행, 새 세션, SessionStart 훅의 재개 안내),\ncompaction된 기억에 의존하지 말고 매번 아티팩트에서 이해를 재생성한다:\n\n1. **마스터 읽기** — `.planning\u002Fmvp-{id}.md`를 읽어 `status: in_progress`면 복구 모드 진입.\n   `paused`면 `\u002Fmvp-stop` 이력 확인 후 사용자 의사 확인(단 `\u002Fmvp-run` 명시 호출은 재개 의사로\n   간주, 별도 확인 생략), `blocked`면 BLOCKED.md부터 읽는다. `BLOCKED.md`가 존재하면 status와\n   무관하게 blocked로 간주 — 요약을 제시하고 해소를 확인한 뒤 진행한다.\n2. **이력 파악** — `git log --oneline -10` + `.planning\u002Fprogress.md`로 직전 진행 지점과\n   마지막 커밋 스토리를 파악한다 (git history = 상태).\n3. **미완 스토리 1개 선택** — 표준 사이클 1단계와 동일한 jq 질의. 한 번에 하나만.\n4. **작업·갱신** — 표준 사이클 2~7단계 수행: 작업→검증→마커→커밋→progress·Checklist·Feedback\n   갱신. 다음 세션을 위한 깨끗한 핸드오프를 남긴다.\n\n## 정지조건 3결합 (판정 주체 = Stop훅)\n\n| # | 조건 | 검사 방식 |\n|---|------|-----------|\n| ① | 결정론 게이트 | `.planning\u002Fgate-cmd` 파일에서 명령 동적 로드(`LOOP_TEST_CMD` env가 있으면 그것이 우선) → **exit code 우선 판정**(출력의 `grep -Ei 'fail\\|error'`는 보조 시그널 — exit 0인데 grep만 매칭되면 오탐 방지를 위해 통과로 본다) **AND** `jq -e '[.stories[].passes] \\| all' .planning\u002Fprd.json`. all-passes 확인 시 passes==true인 각 id의 `.planning\u002Fverified\u002F{id}` 마커 존재까지 재검사 — 마커 없는 passes:true 발견 시 미충족(exit 2)으로 해당 id와 \"mvp-verifier 반증을 통과시켜 마커를 생성하라\" 안내를 재주입(prd-guard가 못 잡는 Bash 리다이렉션 우회의 최종 방어선) |\n| ② | 회의적 Evaluator | passes:true 전환은 mvp-verifier의 `.planning\u002Fverified\u002F{story-id}` 마커가 선행 필수. PostToolUse 훅 `prd-guard.sh`가 마커 없는 마킹을 exit 2로 차단하고 jq로 false 되돌림. **Evaluator의 확률적 판정을 파일 마커로 물화해 결정론 검사로 변환**한 것이 이 설계의 핵심 |\n| ②ᴱ | E2E 수용 게이트(선택) | `.planning\u002Fe2e-gate-cmd`(또는 `LOOP_E2E_CMD` env)가 있으면 **all-passes 도달 시점에만 1회** 실행 → exit 0 그린 필수. 파일 없으면 미적용(통과 간주, 회귀 0). 전체 유저플로우의 최종 동작 보증 — 단위 게이트가 못 잡는 통합 실패를 끝물에 차단 |\n| ③ | Completion promise | `.planning\u002Fprogress.md`에 `\u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>` 정확 문자열 존재 — `grep -qF` 검사(정규식 금지) |\n\n종료 허용 = **① ∧ ②ᴱ ∧ ③**. ②(마커)는 별도 평가 항목이 아니라 ①의 all-passes 검사에 전제로\n인입된다(passes:true가 되려면 마커가 반드시 선행하므로). ②ᴱ는 e2e-gate-cmd가 없으면 자동 통과라\n기존 동작에 영향이 없다. 하나라도 미충족이면 훅이 exit 2로 종료를 차단하고 stderr로 미충족\n사유·테스트\u002FE2E 출력 tail을 재주입한다.\n\n## 환경변수\n\n| 변수 | 기본값 | 용도 | 오버라이드 방법 |\n|------|--------|------|-----------------|\n| `LOOP_TEST_CMD` | 미설정 (`.planning\u002Fgate-cmd` 사용) | 결정론 게이트(단위\u002F통합) 명령을 일시적으로 강제 지정 (예: 부분 테스트로 빠른 반복) | 세션 시작 전 셸에서 `export LOOP_TEST_CMD=\"pytest -q tests\u002Funit\"`. 영구 변경은 env가 아니라 gate-cmd 파일 수정 |\n| `LOOP_E2E_CMD` | 미설정 (`.planning\u002Fe2e-gate-cmd` 사용, 없으면 E2E 미적용) | E2E 수용 게이트 명령 지정 — all-passes 도달 시 1회 실행. 비대화형·exit code 필수 | `export LOOP_E2E_CMD=\"npx playwright test\"`. 영구 적용은 `.planning\u002Fe2e-gate-cmd` 파일에 1줄 기록 |\n| `LOOP_PROMISE` | `\u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>` | 완료 약속문(정확 문자열 일치 대상) | `export LOOP_PROMISE=...` — 변경 시 progress.md 기록 문자열도 반드시 일치시킬 것 |\n| `LOOP_MAX_ITER` | `24` (권장: 스토리 수 × 3, 세션 내 실효 8) | 반복 상한 — 무한 spin 차단. ⚠️ Stop 훅은 연속 8블록 후 오버라이드됨(2026-09-20 실측 3\u002F3) | `\u002Fmvp-run --max-iter \u003Cn>`(`loop-state.json`의 `max_iter` 필드에 기록) 또는 `export LOOP_MAX_ITER=\u003Cn>`. 훅 로드 순서: env > loop-state.json 필드 > 기본값 |\n| `LOOP_MAX_MINUTES` | `120` | 시간 상한 — `loop-state.json`의 `started_at`(epoch 초) 대비 경과 분 | `\u002Fmvp-run --max-minutes \u003Cn>`(`loop-state.json`의 `max_minutes` 필드에 기록) 또는 `export LOOP_MAX_MINUTES=\u003Cn>`. 훅 로드 순서: env > loop-state.json 필드 > 기본값 |\n\n튜닝 지침: 스토리 8개 MVP라면 `--max-iter 24`(기본)가 적정. 스토리 10개 이상 대형 MVP는\n단일 세션 컨텍스트 비대를 피해 headless 레시피(mvp-orchestrator의\n`references\u002Fheadless-recipe.md`) 전환을 권장 — 동일 게이트·동일 `.planning\u002F`을 공유하므로\n엔진을 바꿔도 정지조건은 불변이다.\n\n## loop-active 플래그 수명주기\n\n`.planning\u002Floop-active`(빈 파일)는 \"루프 가동 중\"의 유일한 스위치다.\n\n1. **생성**: `\u002Fmvp-run`만 생성한다. 훅·에이전트가 임의 생성하지 않는다.\n2. **안전핀**: Stop훅 최상단 `[ -f \"$PROJ\u002F.planning\u002Floop-active\" ] || exit 0` — 루프 미가동\n   세션의 종료를 절대 방해하지 않는다(무한 재주입으로 인한 $3600\u002Fday 과금 사고 대응).\n3. **삭제**: 모든 종료 경로에서 훅이 삭제한다 — 정지조건 충족·max-iter 도달·no-progress 감지·\n   시간 상한 초과. `\u002Fmvp-stop`(킬스위치)도 즉시 삭제한다.\n4. **잔존 시 수동 해제**: 훅 타임아웃·강제 종료 등으로 플래그가 남으면 다음 세션에서 종료가\n   계속 차단될 수 있다. `\u002Fmvp-status`가 잔존 여부를 보여주며, 해제는\n   `rm .planning\u002Floop-active` 한 줄이다. 삭제해도 진행 상태(prd.json·progress.md)는 보존된다.\n\n## 가드레일 5종\n\n| 가드 | 기본값\u002F트리거 | 동작 |\n|------|--------------|------|\n| max iterations | `LOOP_MAX_ITER=24` (권장: 스토리 수×3, 세션 내 실효 8) | 도달 시 exit 0 + 미완 상태 보고. promise만으론 부족(과제가 어려우면 무한 spin). 8 블록 오버라이드는 미감지 — 핸드오프 없이 종료 |\n| no-progress | 실패 시그니처(fail\u002Ferror 라인에서 숫자 토큰 제거 정규화 후 md5) 연속 2회 동일 — 소요시간 등 숫자 비결정 출력에 대응하되, 그 외 비결정 문자열이 섞이면 max-iter가 backstop | exit 0 + BLOCKED.md에 iteration·시그니처·테스트 출력 tail 기록 |\n| 시간 상한 | `LOOP_MAX_MINUTES=120` (`loop-state.json` `started_at` 대비) | 초과 시 현 반복 완료 후 exit 0 + 재개 방법(`\u002Fmvp-run`) 보고 |\n| 킬스위치 | `\u002Fmvp-stop` (사용자 수동) | loop-active 삭제 → 훅 즉시 무력화, 핸드오프 기록, 마스터 `status: paused` |\n| circuit breaker | 동일 스토리 연속 3회 실패 (훅이 아닌 오케스트레이터 정책 — progress.md 로그로 감지) | 해당 스토리 skip + BLOCKED.md 기록 후 다음 미완 스토리로 진행 |\n\n발동 순서: 실패가 **동일하게** 반복되면 no-progress(2회)가 max-iter보다 먼저 멈춘다.\n실패 양상이 매번 달라지는 경우에만 max-iter가 backstop으로 작동한다. 둘 다 있어야\n\"stuck\"과 \"느린 진전\" 양쪽을 막는다.\n\n## BLOCKED.md 양식과 에스컬레이션\n\n차단이 발생하면(no-progress·circuit breaker·test-guard 차단·구조적 한계) 아래 양식으로\n`.planning\u002FBLOCKED.md`에 누적 기록한다(기존 항목 삭제 금지):\n\n```markdown\n## [2026-06-12 14:30] S-03 차단\n- 유형: no-progress | circuit-breaker | 테스트 정합성 | 스코프 결함 | 구조적 한계\n- iteration: 11 \u002F 24\n- 시도한 것: 시도별 접근과 결과 요약 (각 1줄)\n- 차단 원인: 실패 시그니처 또는 에러 요약 + 테스트 출력 tail\n- 권장 다음 행동: 에스컬레이션 대상과 구체적 제안\n```\n\n**에스컬레이션 분기** — 차단의 근본 원인으로 판단한다:\n\n| 원인 유형 | 판단 신호 | 처치 |\n|-----------|----------|------|\n| 스코프 결함 | AC가 검증 불가능, 스토리 범위 비대(1반복 초과), 페르소나-스토리 불일치 | **스코프 재협상 = `product-strategist` 재투입** — prd.md·prd.json 수정. 스코프는 G1 승인 사항이므로 변경 요지를 사용자에게 1줄 보고 후 반영 |\n| 구조적 한계 | 스택·레포 골격·아키텍처가 스토리 구현을 원천 차단(의존성 충돌, 골격 결함, gate-cmd 부적합) | **구조 재설계 = `tech-architect` 단독 재투입** — 골격·gate-cmd 보수 후 게이트 그린 재확인, 루프 복귀 |\n\n빌더 재시도로 해결될 문제(단순 버그·플레이크)는 에스컬레이션 대상이 아니다 — circuit breaker\n이전까지는 표준 사이클 안에서 해소한다.\n\n## 테스트 삭제·약화 금지 (test-guard 훅 연계)\n\n루프의 결정론 게이트는 테스트가 신뢰할 수 있을 때만 의미가 있다. 게이트를 \"통과시키기 위해\"\n테스트를 건드리는 것은 사기다.\n\n- **삭제 차단(결정론)**: PreToolUse 훅 `test-guard.sh`가 loop-active 존재 시\n  `rm` 대상에 비알파벳 경계의 `test|spec` 패턴(`tests\u002F` 디렉토리, `.spec.` 파일 등)이 포함된\n  Bash 명령을 exit 2로 차단한다. 경계 검사로 `latest.log` 류는 오탐하지 않으며, 그 외 오탐 시\n  사유를 사용자에게 1줄 보고하고 확인 후 진행한다.\n- **약화 적발(검증자)**: assertion 제거·완화, `skip`\u002F`xit`\u002F`@Disabled` 처리, 기대값을 구현\n  출력에 맞춰 역수정하는 행위는 `mvp-verifier`가 반증 단계에서 적발하며, 적발 시 verified\n  마커를 생성하지 않는다(passes 전환 불가).\n- **정당한 테스트 수정 경로**: 테스트 자체가 잘못된 경우 삭제·우회가 아니라 BLOCKED.md에\n  사유를 기록하고, 수정본이 여전히 해당 스토리의 AC를 검증함을 mvp-verifier 반증으로\n  확인받은 뒤 진행한다.\n\n## References\n\n- 루프 운영 개념·레시피 원전: utils\u002Fharness `team-harness` 스킬의 `references\u002Floop-harness-guide.md`\n- Stage 전체 흐름·게이트 정책: 같은 플러그인의 `mvp-orchestrator` 스킬\n- 루프 엔진 구현: `${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Fmvp-loop-stop-hook.sh` (정지조건 3결합·가드레일)\n- 가드 훅: `${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Fprd-guard.sh` (마커 강제), `${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Ftest-guard.sh` (테스트 삭제 차단)\n","# MVP Loop Protocol\n\nmvp-orchestrator의 Stage 4(개발 루프)를 운영하는 단일 규약. 루프 엔진은 Stop훅\n(`${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Fmvp-loop-stop-hook.sh`)이며, 완료 판정의 주체는 모델이 아니라\n훅이다(\"Completion lives outside the model\"). 이 스킬은 매 반복의 행동 순서, 중단·재개 절차,\n정지조건과 가드레일의 동작·튜닝법을 규정한다.\n\n## When to Apply\n\n다음 상황에서 이 프로토콜을 참조한다:\n- `\u002Fmvp-run`으로 개발 루프를 시작하거나, 중단된 루프를 재개할 때 (재개 프로토콜 4단계)\n- 루프가 가드레일(max-iter·no-progress·시간 상한)로 멈췄거나 `status: paused`에서 복구할 때\n- `LOOP_MAX_ITER`·`LOOP_MAX_MINUTES` 등 가드레일 기본값을 프로젝트 규모에 맞게 튜닝할 때\n- 스토리가 BLOCKED 처리되어 에스컬레이션(스코프 재협상 vs 구조 재설계)을 판단할 때\n- `loop-active` 플래그가 잔존하여 세션 종료가 비정상적으로 차단될 때 (수동 해제)\n- prd-guard·test-guard 훅이 작업을 차단(exit 2)한 이유를 해석할 때\n\n## .planning\u002F 메모리 레이아웃\n\n상태는 컨텍스트가 아니라 디스크에 둔다. 모든 경로는 프로젝트 루트 기준 상대경로다.\n\n```\n.planning\u002F\n├── mvp-{id}.md       # 마스터: ## Goal(불변) \u002F ## Stage \u002F ## Gates(승인 스탬프) \u002F ## Checklist\n│                     #        \u002F ## Iteration \u002F ## Feedback + status: in_progress|paused|blocked|done\n├── prd.md            # G1 승인본\n├── prd.json          # {\"stories\":[{\"id\":\"S-01\",\"title\":...,\"acceptance\":[...],\"passes\":false}]}\n├── design-spec.md    # [story: S-xx] 태그\n├── stack-decision.md # G2 기록(후보·트레이드오프·선택·근거)\n├── gate-cmd          # 결정론 게이트(단위\u002F통합) 명령 1줄(tech-architect 기록, 훅이 로드)\n├── e2e-gate-cmd      # (선택) E2E 수용 게이트 명령 1줄 — 있으면 all-passes 도달 시 1회 실행, 없으면 미적용\n├── progress.md       # 반복 로그 1줄\u002F회 + \u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>\n├── loop-state.json   # {iteration, last_fail_sig, started_at(epoch 초), max_iter, max_minutes}\n├── loop-active       # 루프 가동 플래그(빈 파일) — \u002Fmvp-run 생성, 훅 종료 경로에서 삭제\n├── verified\u002F         # mvp-verifier 승인 마커 S-01, S-02 ...\n└── BLOCKED.md        # 시도·차단 원인·권장 다음 행동\n```\n\n## 매 반복 표준 사이클\n\n한 반복 = 스토리 정확히 1개. 단계와 산출 파일을 건너뛰거나 순서를 바꾸지 않는다.\n\n| # | 단계 | 수행 주체 | 명령·파일 |\n|---|------|----------|-----------|\n| 1 | 스토리 선택 | 메인 세션 | `jq -r '[.stories[] \\| select(.passes == false)][0].id' .planning\u002Fprd.json` — 미완(passes:false) 최우선 스토리 **1개만** |\n| 2 | 구현 | 메인 세션(`mvp-builder` 규율 체화) | 테스트 먼저 → 최소 구현 → `.planning\u002Fgate-cmd`의 명령으로 게이트 그린 확인. **passes 직접 마킹 금지**. 예외: 병렬 feature 구현 시에만 `mvp-builder`를 worktree 격리 서브에이전트로 디스패치(코드 작성까지만 — 커밋·마킹은 메인 세션 통합 시) |\n| 3 | 반증 | `mvp-verifier` 디스패치 | AC 반증 시도: 엣지케이스 직접 실행, 테스트가 AC를 실제 검증하는지, assertion 약화·skip·삭제 사기 적발, gate-cmd 독립 재실행 |\n| 4 | verified 마커 | `mvp-verifier` | 반증 **실패 시에만** `.planning\u002Fverified\u002F{story-id}` 생성(내용 = 반증 시도 요약). 반증 성공 시 마커 없이 지적 사항 반환 → 2단계로 회귀 |\n| 5 | passes:true | 메인 세션 | 마커 확인 후 `.planning\u002Fprd.json`의 해당 스토리 `passes`를 true로 갱신. prd-guard 훅(PostToolUse)이 마커 존재를 재검사 — 없으면 jq로 false 되돌림 + exit 2 |\n| 6 | progress 갱신 | 메인 세션 | `.planning\u002Fprogress.md`에 1줄 추가: `iter N \\| S-xx verified \\| passes n\u002Fm`. 마스터 파일 Checklist·Iteration·Feedback도 동기 갱신 |\n| 7 | 커밋 | 메인 세션 | `git add -A && git commit -m \"feat(mvp): S-xx \u003C변경 요지>\"` — **커밋 1회에 구현+prd.json+progress.md 일괄 포함**, descriptive 커밋, 스토리 id 필수 |\n\n전 스토리 `passes:true` 도달 시 **(E2E 수용 게이트 적용 프로젝트)**: promise 기록 전에 먼저\n`.planning\u002Fe2e-gate-cmd`(또는 `\u002Fe2e`)를 직접 실행해 전체 유저플로우가 동작하는지 확인한다.\n- E2E 그린 → progress.md 마지막 줄에 `\u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>`를 정확히 기록(앞뒤 변형 금지)하고 마스터 `status: done`으로 전환 → Stop훅이 정지조건(① ∧ ②ᴱ ∧ ③)을 재검사하고 종료를 허용한다.\n- E2E 레드 → promise를 기록하지 않는다. 깨진 플로우를 커버하는 스토리를 보완(필요 시 PS에 E2E 스토리 추가 요청)해 다시 단위 그린 → E2E 그린을 만든다. 성급히 promise를 적어도 Stop훅이 E2E 재검사로 종료를 차단한다.\n\nE2E 게이트 미적용(`e2e-gate-cmd` 없음) 프로젝트는 전 스토리 `passes:true` 도달 즉시 promise를\n기록하면 된다(기존 동작과 동일). promise 정확 기록 + 마스터 `status: done` 후 Stop훅이 종료를 허용한다.\n\n## 재개 프로토콜 (4단계)\n\n루프가 어떤 이유로든 끊긴 뒤(`\u002Fmvp-run` 재실행, 새 세션, SessionStart 훅의 재개 안내),\ncompaction된 기억에 의존하지 말고 매번 아티팩트에서 이해를 재생성한다:\n\n1. **마스터 읽기** — `.planning\u002Fmvp-{id}.md`를 읽어 `status: in_progress`면 복구 모드 진입.\n   `paused`면 `\u002Fmvp-stop` 이력 확인 후 사용자 의사 확인(단 `\u002Fmvp-run` 명시 호출은 재개 의사로\n   간주, 별도 확인 생략), `blocked`면 BLOCKED.md부터 읽는다. `BLOCKED.md`가 존재하면 status와\n   무관하게 blocked로 간주 — 요약을 제시하고 해소를 확인한 뒤 진행한다.\n2. **이력 파악** — `git log --oneline -10` + `.planning\u002Fprogress.md`로 직전 진행 지점과\n   마지막 커밋 스토리를 파악한다 (git history = 상태).\n3. **미완 스토리 1개 선택** — 표준 사이클 1단계와 동일한 jq 질의. 한 번에 하나만.\n4. **작업·갱신** — 표준 사이클 2~7단계 수행: 작업→검증→마커→커밋→progress·Checklist·Feedback\n   갱신. 다음 세션을 위한 깨끗한 핸드오프를 남긴다.\n\n## 정지조건 3결합 (판정 주체 = Stop훅)\n\n| # | 조건 | 검사 방식 |\n|---|------|-----------|\n| ① | 결정론 게이트 | `.planning\u002Fgate-cmd` 파일에서 명령 동적 로드(`LOOP_TEST_CMD` env가 있으면 그것이 우선) → **exit code 우선 판정**(출력의 `grep -Ei 'fail\\|error'`는 보조 시그널 — exit 0인데 grep만 매칭되면 오탐 방지를 위해 통과로 본다) **AND** `jq -e '[.stories[].passes] \\| all' .planning\u002Fprd.json`. all-passes 확인 시 passes==true인 각 id의 `.planning\u002Fverified\u002F{id}` 마커 존재까지 재검사 — 마커 없는 passes:true 발견 시 미충족(exit 2)으로 해당 id와 \"mvp-verifier 반증을 통과시켜 마커를 생성하라\" 안내를 재주입(prd-guard가 못 잡는 Bash 리다이렉션 우회의 최종 방어선) |\n| ② | 회의적 Evaluator | passes:true 전환은 mvp-verifier의 `.planning\u002Fverified\u002F{story-id}` 마커가 선행 필수. PostToolUse 훅 `prd-guard.sh`가 마커 없는 마킹을 exit 2로 차단하고 jq로 false 되돌림. **Evaluator의 확률적 판정을 파일 마커로 물화해 결정론 검사로 변환**한 것이 이 설계의 핵심 |\n| ②ᴱ | E2E 수용 게이트(선택) | `.planning\u002Fe2e-gate-cmd`(또는 `LOOP_E2E_CMD` env)가 있으면 **all-passes 도달 시점에만 1회** 실행 → exit 0 그린 필수. 파일 없으면 미적용(통과 간주, 회귀 0). 전체 유저플로우의 최종 동작 보증 — 단위 게이트가 못 잡는 통합 실패를 끝물에 차단 |\n| ③ | Completion promise | `.planning\u002Fprogress.md`에 `\u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>` 정확 문자열 존재 — `grep -qF` 검사(정규식 금지) |\n\n종료 허용 = **① ∧ ②ᴱ ∧ ③**. ②(마커)는 별도 평가 항목이 아니라 ①의 all-passes 검사에 전제로\n인입된다(passes:true가 되려면 마커가 반드시 선행하므로). ②ᴱ는 e2e-gate-cmd가 없으면 자동 통과라\n기존 동작에 영향이 없다. 하나라도 미충족이면 훅이 exit 2로 종료를 차단하고 stderr로 미충족\n사유·테스트\u002FE2E 출력 tail을 재주입한다.\n\n## 환경변수\n\n| 변수 | 기본값 | 용도 | 오버라이드 방법 |\n|------|--------|------|-----------------|\n| `LOOP_TEST_CMD` | 미설정 (`.planning\u002Fgate-cmd` 사용) | 결정론 게이트(단위\u002F통합) 명령을 일시적으로 강제 지정 (예: 부분 테스트로 빠른 반복) | 세션 시작 전 셸에서 `export LOOP_TEST_CMD=\"pytest -q tests\u002Funit\"`. 영구 변경은 env가 아니라 gate-cmd 파일 수정 |\n| `LOOP_E2E_CMD` | 미설정 (`.planning\u002Fe2e-gate-cmd` 사용, 없으면 E2E 미적용) | E2E 수용 게이트 명령 지정 — all-passes 도달 시 1회 실행. 비대화형·exit code 필수 | `export LOOP_E2E_CMD=\"npx playwright test\"`. 영구 적용은 `.planning\u002Fe2e-gate-cmd` 파일에 1줄 기록 |\n| `LOOP_PROMISE` | `\u003Cpromise>MVP_COMPLETE\u003C\u002Fpromise>` | 완료 약속문(정확 문자열 일치 대상) | `export LOOP_PROMISE=...` — 변경 시 progress.md 기록 문자열도 반드시 일치시킬 것 |\n| `LOOP_MAX_ITER` | `24` (권장: 스토리 수 × 3, 세션 내 실효 8) | 반복 상한 — 무한 spin 차단. ⚠️ Stop 훅은 연속 8블록 후 오버라이드됨(2026-09-20 실측 3\u002F3) | `\u002Fmvp-run --max-iter \u003Cn>`(`loop-state.json`의 `max_iter` 필드에 기록) 또는 `export LOOP_MAX_ITER=\u003Cn>`. 훅 로드 순서: env > loop-state.json 필드 > 기본값 |\n| `LOOP_MAX_MINUTES` | `120` | 시간 상한 — `loop-state.json`의 `started_at`(epoch 초) 대비 경과 분 | `\u002Fmvp-run --max-minutes \u003Cn>`(`loop-state.json`의 `max_minutes` 필드에 기록) 또는 `export LOOP_MAX_MINUTES=\u003Cn>`. 훅 로드 순서: env > loop-state.json 필드 > 기본값 |\n\n튜닝 지침: 스토리 8개 MVP라면 `--max-iter 24`(기본)가 적정. 스토리 10개 이상 대형 MVP는\n단일 세션 컨텍스트 비대를 피해 headless 레시피(mvp-orchestrator의\n`references\u002Fheadless-recipe.md`) 전환을 권장 — 동일 게이트·동일 `.planning\u002F`을 공유하므로\n엔진을 바꿔도 정지조건은 불변이다.\n\n## loop-active 플래그 수명주기\n\n`.planning\u002Floop-active`(빈 파일)는 \"루프 가동 중\"의 유일한 스위치다.\n\n1. **생성**: `\u002Fmvp-run`만 생성한다. 훅·에이전트가 임의 생성하지 않는다.\n2. **안전핀**: Stop훅 최상단 `[ -f \"$PROJ\u002F.planning\u002Floop-active\" ] || exit 0` — 루프 미가동\n   세션의 종료를 절대 방해하지 않는다(무한 재주입으로 인한 $3600\u002Fday 과금 사고 대응).\n3. **삭제**: 모든 종료 경로에서 훅이 삭제한다 — 정지조건 충족·max-iter 도달·no-progress 감지·\n   시간 상한 초과. `\u002Fmvp-stop`(킬스위치)도 즉시 삭제한다.\n4. **잔존 시 수동 해제**: 훅 타임아웃·강제 종료 등으로 플래그가 남으면 다음 세션에서 종료가\n   계속 차단될 수 있다. `\u002Fmvp-status`가 잔존 여부를 보여주며, 해제는\n   `rm .planning\u002Floop-active` 한 줄이다. 삭제해도 진행 상태(prd.json·progress.md)는 보존된다.\n\n## 가드레일 5종\n\n| 가드 | 기본값\u002F트리거 | 동작 |\n|------|--------------|------|\n| max iterations | `LOOP_MAX_ITER=24` (권장: 스토리 수×3, 세션 내 실효 8) | 도달 시 exit 0 + 미완 상태 보고. promise만으론 부족(과제가 어려우면 무한 spin). 8 블록 오버라이드는 미감지 — 핸드오프 없이 종료 |\n| no-progress | 실패 시그니처(fail\u002Ferror 라인에서 숫자 토큰 제거 정규화 후 md5) 연속 2회 동일 — 소요시간 등 숫자 비결정 출력에 대응하되, 그 외 비결정 문자열이 섞이면 max-iter가 backstop | exit 0 + BLOCKED.md에 iteration·시그니처·테스트 출력 tail 기록 |\n| 시간 상한 | `LOOP_MAX_MINUTES=120` (`loop-state.json` `started_at` 대비) | 초과 시 현 반복 완료 후 exit 0 + 재개 방법(`\u002Fmvp-run`) 보고 |\n| 킬스위치 | `\u002Fmvp-stop` (사용자 수동) | loop-active 삭제 → 훅 즉시 무력화, 핸드오프 기록, 마스터 `status: paused` |\n| circuit breaker | 동일 스토리 연속 3회 실패 (훅이 아닌 오케스트레이터 정책 — progress.md 로그로 감지) | 해당 스토리 skip + BLOCKED.md 기록 후 다음 미완 스토리로 진행 |\n\n발동 순서: 실패가 **동일하게** 반복되면 no-progress(2회)가 max-iter보다 먼저 멈춘다.\n실패 양상이 매번 달라지는 경우에만 max-iter가 backstop으로 작동한다. 둘 다 있어야\n\"stuck\"과 \"느린 진전\" 양쪽을 막는다.\n\n## BLOCKED.md 양식과 에스컬레이션\n\n차단이 발생하면(no-progress·circuit breaker·test-guard 차단·구조적 한계) 아래 양식으로\n`.planning\u002FBLOCKED.md`에 누적 기록한다(기존 항목 삭제 금지):\n\n```markdown\n## [2026-06-12 14:30] S-03 차단\n- 유형: no-progress | circuit-breaker | 테스트 정합성 | 스코프 결함 | 구조적 한계\n- iteration: 11 \u002F 24\n- 시도한 것: 시도별 접근과 결과 요약 (각 1줄)\n- 차단 원인: 실패 시그니처 또는 에러 요약 + 테스트 출력 tail\n- 권장 다음 행동: 에스컬레이션 대상과 구체적 제안\n```\n\n**에스컬레이션 분기** — 차단의 근본 원인으로 판단한다:\n\n| 원인 유형 | 판단 신호 | 처치 |\n|-----------|----------|------|\n| 스코프 결함 | AC가 검증 불가능, 스토리 범위 비대(1반복 초과), 페르소나-스토리 불일치 | **스코프 재협상 = `product-strategist` 재투입** — prd.md·prd.json 수정. 스코프는 G1 승인 사항이므로 변경 요지를 사용자에게 1줄 보고 후 반영 |\n| 구조적 한계 | 스택·레포 골격·아키텍처가 스토리 구현을 원천 차단(의존성 충돌, 골격 결함, gate-cmd 부적합) | **구조 재설계 = `tech-architect` 단독 재투입** — 골격·gate-cmd 보수 후 게이트 그린 재확인, 루프 복귀 |\n\n빌더 재시도로 해결될 문제(단순 버그·플레이크)는 에스컬레이션 대상이 아니다 — circuit breaker\n이전까지는 표준 사이클 안에서 해소한다.\n\n## 테스트 삭제·약화 금지 (test-guard 훅 연계)\n\n루프의 결정론 게이트는 테스트가 신뢰할 수 있을 때만 의미가 있다. 게이트를 \"통과시키기 위해\"\n테스트를 건드리는 것은 사기다.\n\n- **삭제 차단(결정론)**: PreToolUse 훅 `test-guard.sh`가 loop-active 존재 시\n  `rm` 대상에 비알파벳 경계의 `test|spec` 패턴(`tests\u002F` 디렉토리, `.spec.` 파일 등)이 포함된\n  Bash 명령을 exit 2로 차단한다. 경계 검사로 `latest.log` 류는 오탐하지 않으며, 그 외 오탐 시\n  사유를 사용자에게 1줄 보고하고 확인 후 진행한다.\n- **약화 적발(검증자)**: assertion 제거·완화, `skip`\u002F`xit`\u002F`@Disabled` 처리, 기대값을 구현\n  출력에 맞춰 역수정하는 행위는 `mvp-verifier`가 반증 단계에서 적발하며, 적발 시 verified\n  마커를 생성하지 않는다(passes 전환 불가).\n- **정당한 테스트 수정 경로**: 테스트 자체가 잘못된 경우 삭제·우회가 아니라 BLOCKED.md에\n  사유를 기록하고, 수정본이 여전히 해당 스토리의 AC를 검증함을 mvp-verifier 반증으로\n  확인받은 뒤 진행한다.\n\n## References\n\n- 루프 운영 개념·레시피 원전: utils\u002Fharness `team-harness` 스킬의 `references\u002Floop-harness-guide.md`\n- Stage 전체 흐름·게이트 정책: 같은 플러그인의 `mvp-orchestrator` 스킬\n- 루프 엔진 구현: `${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Fmvp-loop-stop-hook.sh` (정지조건 3결합·가드레일)\n- 가드 훅: `${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Fprd-guard.sh` (마커 강제), `${CLAUDE_PLUGIN_ROOT}\u002Fhooks\u002Ftest-guard.sh` (테스트 삭제 차단)\n",{"name":5,"description":7},"main","e9f37e996e3d2b1b6ac9c879e9dfba1223b597c3","archive\u002Fmvp\u002Fskills\u002Fmvp-loop-protocol",0,"https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness","https:\u002F\u002Fdokkabei97.github.io\u002Fdokkabei-harness\u002F","https:\u002F\u002Fgithub.com\u002FDokkabei97","Contact: wkdrn970@gmail.com","2026-10-29 06:49:16",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Dokkabei97\u002Fdokkabei-harness --skill mvp-loop-protocol",{"tool":59,"command":60},"bunx","bunx skills add Dokkabei97\u002Fdokkabei-harness --skill mvp-loop-protocol",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Dokkabei97\u002Fdokkabei-harness --skill mvp-loop-protocol","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Farchive\u002Fmvp\u002Fskills\u002Fmvp-loop-protocol\u002FSKILL.md",true,[],[68,99,129,152,171,194],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"publishedAt":39},"01M6QZQTNF815AWYMAMJ3B25GY","sync-claude-md","커밋·푸시·PR\u002FMR 직전에 이번 변경이 프로젝트 CLAUDE.md 를 낡게 만드는지 검토하고, 필요할 때만 갱신 diff 를 제안한다 — 아키텍처·디렉터리 구조, 새 통합\u002FMCP, 컨벤션, 빌드·CI·도구, 주요 의존성 변화가 대상. 해당 없으면 한 줄로 끝낸다.\nReviews whether pending changes make the project CLAUDE.md stale (architecture, integrations, conventions, build\u002FCI\u002Ftooling, major dependencies) and proposes a minimal update diff only when needed.\nUse when: \"CLAUDE.md 갱신 필요해?\", \"CLAUDE.md 동기화\", 커밋\u002F푸시\u002FMR 전에 구조·도구가 바뀐 변경을 정리할 때, sync CLAUDE.md, check CLAUDE.md before commit or PR.","https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Fplugins\u002Fworkflow\u002Fskills\u002Fsync-claude-md\u002FSKILL.md",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,37],"sync","claude md","sync claude md","MCP","commit","architecture","pr","update","ci","integrations","use","diff","only","minimal","project","make","reviews","pending","mr",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":111,"publishedAt":39},"01M6QZQEK94G00N955VQH9EFQN","spec-driven-dev","새 기능·프로젝트·큰 변경을 코드보다 스펙 먼저로 진행하는 게이트 워크플로(SPECIFY → PLAN → TASKS → IMPLEMENT) — 가정 명시, 측정 가능한 성공 기준, Always\u002FAsk\u002FNever 경계, 단계별 사람 검토로 범위 이탈과 재작업을 줄인다.\nSpec-before-code gated workflow for new features or significant changes: explicit assumptions, measurable success criteria, boundaries, and a human review between stages.\nUse when: \"스펙 먼저\", \"기능 명세\", \"요구사항 정리\", starting a new feature or project, a significant change with vague requirements. 단순 버그 수정·1~2줄 변경엔 불필요.","https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Fplugins\u002Fworkflow\u002Fskills\u002Fspec-driven-dev\u002FSKILL.md",[105,106],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[112,113,114,115,116,117,118,119,120,121,122,123,124,125,94,126,36,127,128,37],"spec","spec driven","dev","spec driven dev","driven","review","workflow","change","tasks","code","plan","ask","never","human","feature","vague","features",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":39},"01M6QZQA9F6QVGTVDMJ28YQGDV","shipping-guide","프로덕션 배포 전후 가이드 — 배포 전 체크리스트, 피처 플래그 수명주기, 단계적 롤아웃과 진행\u002F보류\u002F롤백 임계값, 롤백 계획 템플릿, 배포 후 모니터링.\nProduction shipping guide: pre-launch checklist, feature-flag lifecycle, staged rollout with go\u002Fhold\u002Frollback thresholds, rollback plan template, post-launch monitoring.\nUse when: \"배포 준비\", \"릴리즈 전 점검\", \"롤아웃 계획\", \"롤백 계획\", preparing a production deploy, staged rollout, feature flags.","https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Fplugins\u002Fworkflow\u002Fskills\u002Fshipping-guide\u002FSKILL.md",[],[136,137,138,139,140,141,142,122,143,144,90,145,146,126,147,148,149,150,151,37],"shipping","guide","shipping guide","launch","monitoring","lifecycle","feature flags","template","rollback","rollout","flags","thresholds","post","with","pre-launch","rollback plan",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":39},"01M6QZQ3M962PCWYM6YH62D76Z","retro","세션 회고·교훈 컴파운딩 — 이번 세션의 교정·실수·발견을 추출해 품질 기준(재현·일반화·판정 가능성)으로 거르고, 컨벤션 변화는 sync-claude-md 위임, 반복 실수는 tasks\u002Flessons.md(#가드-훅-후보 태그), 스킬 지식 갱신은 수정 제안으로 나눈다. 모든 적용은 승인 후.\nSession retrospective that turns corrections, mistakes, and discoveries into vetted lessons routed to CLAUDE.md sync, tasks\u002Flessons.md, or skill-edit proposals, with user approval before any write.\nUse when: \"회고\", \"레트로\", \"교훈 정리\", \"같은 실수 반복\", \"재발 방지 규칙\", retrospective, lessons learned, wrapping up a task, review, or loop. 여러 실행에 걸친 하네스 개선은 harness:evolve.","https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Fplugins\u002Fworkflow\u002Fskills\u002Fretro\u002FSKILL.md",[],[154,117,80,120,38,159,22,160,161,162,163,164,92,165,166,167,168,169,170,37],"harness","evolve","write","edit","proposals","session","up","dry","learned","Session Retrospective","lessons","mistakes",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":39},"01M6QZPPDATJ7DAGNP0JCXFGRV","project-rules","현재 프로젝트의 스택(빌드 파일 버전, 마이그레이션 도구, ORM 유무, ES 사용, git 호스트)을 감지해 프로젝트 루트 AGENTS.md 의 마커 블록(스택 사실 + 항상 적용되는 스페셜리스트 핵심 ≤15줄 — Claude Code·Codex·Antigravity 공통)과 CLAUDE.md 의 `@AGENTS.md` 연결, Claude 전용 경로 한정 .claude\u002Frules\u002F\u003Cstack>-specialist.md(해당 버전에 실제로 맞는 상세 함정)를 diff 로 제안하고, 스택 플러그인을 런타임별로 프로젝트 범위에서 켜는 법을 안내한다. 이전 버전 출력(CLAUDE.md 블록·specialist-core.md)은 AGENTS.md 로 이전을 제안. --check 는 버전 불일치·사라진 ID·크기 한도·연결 누락을 점검.\nDetects the project's stack and proposes a cross-runtime AGENTS.md block (stack facts + always-on specialist core) linked from CLAUDE.md via @AGENTS.md, plus Claude-only path-scoped specialist rules; migrates the older CLAUDE.md-block layout; --check audits drift.\nUse when: \"이 프로젝트 세팅\", \"프로젝트 규칙 생성\", \"AGENTS.md\u002FCLAUDE.md 점검\", project setup, generate project rules, audit AGENTS.md or CLAUDE.md drift.","https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Fplugins\u002Fworkflow\u002Fskills\u002Fproject-rules\u002FSKILL.md",[177],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},[179,94,180,181,182,121,183,184,185,186,91,92,187,188,189,190,191,192,193,37],"Rules","project rules","core","generate","git","audit","stack","orm","es","drift","layout","runtime","-specialist","path","scoped",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":204,"publishedAt":39},"01M6QZPF3S8YAM27F297F6GVD7","post-merge","MR 머지 완료 후 Plane 이슈 종료와 Outline 문서 업데이트를 자동으로 처리하는 오케스트레이터 스킬입니다.\nissue-tracker와 document-latest 스킬을 연계 실행하여 머지 후 후속 작업을 일괄 처리합니다.\nOrchestrates post-merge follow-up after an MR is merged: chains the issue-tracker and document-latest skills to close the Plane issue and update Outline wiki docs in a single batch. Use when: an MR was just merged, closing tickets and syncing documentation after a merge, post-merge cleanup.","https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Fplugins\u002Fworkflow\u002Fskills\u002Fpost-merge\u002FSKILL.md",[200,203],{"categoryNo":201,"categoryName":202,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},[205,206,148,207,208,87,209,210,211,165,212,213,214,215,216,217,218,219,98,37],"merge","post merge","documentation","cleanup","batch","wiki","just","issue","tracker","close","closing","follow-up","true","plane","single"]