[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QZ2TVN6M3R8DWS124THCCM":3,"skill-same:01M6QZ2TVN6M3R8DWS124THCCM":72},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6QZ2TVN6M3R8DWS124THCCM","feature-loop-orchestrator",null,"기존(브라운필드) 코드베이스용 루프 엔지니어링 하네스 오케스트레이터. 자연어 기능 요청 한 줄을 코드베이스 분석 기반 작업 분해(tasks.json)→baseline 캡처→회귀 안전 개발 루프의 게이트 상태기계로 자율 완주시킨다. \"이 기능 추가해줘\", \"X 리팩토링\", \"이 코드베이스에 Y 붙여줘\" 등 이미 개발 중\u002F완료된 프로젝트의 기능 추가·수정 요청과 \u002Ffloop-new·\u002Ffloop-run 커맨드 실행 시 적용. MVP의 검증된 루프 인프라(Stop훅 엔진·maker\u002Fchecker 반증·가드레일·.planning 메모리)를 재사용하되 입력은 작업 분해, 게이트는 baseline 회귀 방지. 루프 안에서 스택 플러그인·analyze·test·workflow를 호출. 빈\u002F신규 레포의 기획부터 시작하는 그린필드 신규 서비스에는 발동하지 않음 — mvp 플러그인으로 위임한다.\nLoop-engineering orchestrator for existing (brownfield) codebases: drives a one-line feature request through task decomposition (tasks.json), baseline capture, and a regression-safe gated dev loop, reusing MVP loop infrastructure (Stop-hook engine, maker\u002Fchecker, guardrails). Use when: 'add this feature', 'refactor X', \u002Ffloop-new, \u002Ffloop-run on an existing project — greenfield goes to mvp.","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\u002Ffeature-loop\u002Fskills\u002Ffeature-loop-orchestrator\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"feature loop orchestrator","loop","orchestrator","feature","project","when","request","checker","hook","mvp","line","decomposition","safe","maker","brownfield","regression","analyze","Guardrails","run","tasks","2026-11-10 10:12:30",false,"---\nname: feature-loop-orchestrator\ndescription: |\n  기존(브라운필드) 코드베이스용 루프 엔지니어링 하네스 오케스트레이터. 자연어 기능 요청 한 줄을 코드베이스 분석 기반 작업 분해(tasks.json)→baseline 캡처→회귀 안전 개발 루프의 게이트 상태기계로 자율 완주시킨다. \"이 기능 추가해줘\", \"X 리팩토링\", \"이 코드베이스에 Y 붙여줘\" 등 이미 개발 중\u002F완료된 프로젝트의 기능 추가·수정 요청과 \u002Ffloop-new·\u002Ffloop-run 커맨드 실행 시 적용. MVP의 검증된 루프 인프라(Stop훅 엔진·maker\u002Fchecker 반증·가드레일·.planning 메모리)를 재사용하되 입력은 작업 분해, 게이트는 baseline 회귀 방지. 루프 안에서 스택 플러그인·analyze·test·workflow를 호출. 빈\u002F신규 레포의 기획부터 시작하는 그린필드 신규 서비스에는 발동하지 않음 — mvp 플러그인으로 위임한다.\n  Loop-engineering orchestrator for existing (brownfield) codebases: drives a one-line feature request through task decomposition (tasks.json), baseline capture, and a regression-safe gated dev loop, reusing MVP loop infrastructure (Stop-hook engine, maker\u002Fchecker, guardrails). Use when: 'add this feature', 'refactor X', \u002Ffloop-new, \u002Ffloop-run on an existing project — greenfield goes to mvp.\n---\n\n# Feature Loop Orchestrator (브라운필드)\n\n자연어 기능 요청 한 줄을 **기존 코드베이스 위에서** 회귀 없이 완주시키는 오케스트레이터. Stage A~C 파이프라인을 게이트 기반 상태기계로 관리하고, 각 Stage의 maker\u002Fchecker를 전문 에이전트에게 위임하며, Stage C는 Stop훅 루프 엔진으로 자율 반복한다.\n\n핵심 명제: **\"완료 판정은 모델이 아니라 하네스가 한다.\"** 브라운필드 추가 명제: **\"회귀 없음도 하네스가 baseline 대비로 판정한다.\"**\n\n## When to Apply\n\n**발동:**\n- \"이 기능 추가해줘\", \"X 리팩토링해줘\", \"이 코드베이스에 Y 붙여줘\" — 이미 코드가 있는 프로젝트의 기능 추가·수정·리팩토링\n- 자연어 요청 + 여러 task로 분해해 반복 구현이 필요할 때\n- `\u002Ffloop-new`(시작), `\u002Ffloop-run`(재개) 커맨드 실행 시\n\n**미발동 (위임 경계):**\n- 빈\u002F신규 레포에서 기획(PRD)부터 시작하는 그린필드 신규 서비스 → **mvp 플러그인**\n- 단일 파일 1줄 수정·즉답 가능한 작업 → 루프 불필요, 직접 수행\n- 기획 문서\u002F디자인만 단건 작성 → 해당 플러그인 스킬 직접 사용\n\n## Architecture\n\n- **패턴**: Sequential Pipeline(A~C 상태기계) + Producer-Reviewer(maker\u002Fchecker) + Regression-Safe Loop(Stage C)\n- **실행 모드**: Sub-agents — 메인 세션이 오케스트레이터로 TP\u002FFV를 `Agent` 디스패치. **Stage C의 maker(FB)는 메인 세션이 규율을 체화해 직접 수행**(Stop훅이 메인 세션 종료를 가로채는 구조).\n- **메모리**: `.planning\u002F` + git history = 상태. 매 세션 아티팩트에서 이해 재생성.\n- **MVP 대비 차이**: 생성 단계(PRD·디자인·스캐폴딩) 제거. 대신 **코드베이스 분석 기반 분해 + baseline 캡처**가 입력. 게이트 방향이 \"생성 검증\"에서 \"회귀 방지\"로 전환.\n\n## Team Members\n\n| ID | 에이전트 파일 | 역할 | 산출물 |\n|----|--------------|------|--------|\n| TP | `agents\u002Ftask-planner.md` | 작업 분해 maker — 코드베이스 분석 → tasks.json. **Stage B checker 겸 아님**(분해 반증은 FV). BLOCKED 재분해 | `.planning\u002Ftasks.json` 초안 |\n| FB | `agents\u002Ffeature-builder.md` | 개발 루프 maker(메인 세션 체화) — 미완 task 1개씩 테스트 먼저 → 최소 구현 → 게이트 그린+회귀 0 → FV 검증 후 일괄 커밋 | task별 구현+테스트+`feat: T-xx` 커밋, progress 갱신 |\n| FV | `agents\u002Ffeature-verifier.md` | 회의적 checker — task AC 반증 + **회귀 반증**(baseline 대조) + 사기 적발 + (선택)analyze 렌즈. Edit 미보유 | 반증 리포트, `.planning\u002Fverified\u002F{task-id}` 마커 |\n\n## Orchestration Phases\n\n### Stage A: 인테이크 + baseline 캡처 (`\u002Ffloop-new`)\n\n- **Assigned to**: 메인 세션(오케스트레이터)\n- **Input**: 자연어 요청 한 줄 (+ `--auto`, `--gate-cmd`, `--tasks-max`)\n- **Output**: `.planning\u002Frequest.md`(원본 불변) + 마스터 `floop-{id}.md`(## Goal 불변) + `.planning\u002Fgate-cmd` + `.planning\u002Fbaseline.json`\n- **동작**:\n  1. `request.md` 기록 + 마스터 생성.\n  2. **스택 자동 감지** → gate-cmd 결정 (`build.gradle*`→`.\u002Fgradlew test`, `pyproject.toml`→`pytest -q`, `package.json`+next→`pnpm test`, `go.mod`→`go test .\u002F...`). 모호 시 사용자 확인 또는 `--gate-cmd` 명시.\n  3. **baseline 캡처** — `hooks\u002Fgates\u002Fcapture-baseline.sh` 실행 → `baseline.json`. baseline red면 기존 실패 수를 1줄 경고(회귀 게이트가 fail_count ≤ N로 동작).\n- **게이트**: gate-cmd 실행 가능 확인. 사용자 게이트 없음.\n\n### Stage B: 작업 분해 (`task-planner` maker → `feature-verifier` checker)\n\n- **Assigned to**: TP(Agent 디스패치) → FV(분해 반증) → 메인 세션 사용자 게이트\n- **Input**: `request.md` + 코드베이스\n- **Output**: `.planning\u002Ftasks.json` (`{\"tasks\":[{\"id\":\"T-01\",\"title\",\"acceptance\":[],\"passes\":false}]}`)\n- **결정론 게이트**: `hooks\u002Fgates\u002Fgate-tasks.sh --initial` — jq 스키마 + 개수 2~`FLOOP_TASKS_MAX`(기본 10) + passes 전건 false\n- **사용자 게이트 ★G1 — 작업 목록 승인**(항상; `--auto`면 자동 채택·스탬프): 분해 task 목록 + 영향 파일 + 회귀 위험을 제시하고 승인\n\nTP가 코드베이스를 탐색해 수직 슬라이스로 분해 → FV가 \"이 분해가 틀렸다면 왜?\"로 반증(범위 비대·검증 불가 AC·회귀 보존 AC 누락) → 근거 있는 반증은 TP가 수정. 분해 표준은 `task-decomposition` 스킬 참조.\n\n### Stage C: 회귀 안전 개발 루프 (`feature-builder` 체화 → `feature-verifier` 매 task)\n\n- **Assigned to**: 메인 세션(FB 규율 체화) → FV(매 task Agent 디스패치)\n- **Input**: 확정 tasks.json + gate-cmd + baseline.json + 게이트 그린 상태의 레포\n- **Output**: 전 task `passes:true` + `.planning\u002Fverified\u002F` 마커 전건 + `progress.md`의 `\u003Cpromise>FEATURE_COMPLETE\u003C\u002Fpromise>` + task별 커밋\n- **게이트**: Stop훅 루프 엔진(`hooks\u002Ffloop-loop-stop-hook.sh`)이 매 반복 정지조건 4결합 판정. 사용자 게이트 없음 — 자율, BLOCKED 시만 보고.\n\nStage C 진입은 항상 `\u002Ffloop-run` 절차(`loop-active` 생성·`loop-state.json` 초기화)를 경유. 매 반복 표준 사이클: 미완 task 1개 → 테스트 먼저 → 최소 구현(스택 플러그인 활용) → 게이트 그린+회귀 0 → FV 반증 → verified 마커 → passes:true → 커밋 1회. 상세는 `floop-loop-protocol` 스킬 참조. **완료 후** `workflow:shipping-guide`로 배포 전 체크를 안내(루프 밖, 보고).\n\n#### FV 디스패치 규약 — verify-round 상태 파일\n\ntask AC·회귀 반증(모드 ②) 디스패치의 오케스트레이터 의무 3가지 — SubagentStop 훅이 이 규약을 결정론 집행한다(마커 없는 verifier 종료를 exit 2 차단, round>=2는 최대 2라운드 규약으로 통과 허용).\n\n1. **디스패치 직전**: `.planning\u002Fverify-round\u002F{task-id}`에 `round=1`(maker 수정 후 재검이면 `round=2`) 기록\n2. **결과 규약**: 반증 실패(통과) → FV가 `verified\u002F{task-id}` 생성(기존 규약) \u002F 반증 성공 → `refuted\u002F{task-id}`에 구체 근거(파일:라인·실행 출력·재현 명령) 기록\n3. **결과 처리 후**: `refuted`를 FB 수정 라운드 입력으로 소비하고 `verify-round\u002F{task-id}`를 정리(삭제)한다\n\n훅은 동일 pending 차단을 2회로 제한하고(`blocked=N` 카운터), 초과 시 스테일로 간주해 `verify-round\u002F{task-id}`를 자동 정리한다 — verifier 재디스패치 필요.\n\n#### --cross-check 교차 모델 반증 (opt-in, 기본 off)\n\n`\u002Ffloop-run --cross-check` 지정 시 FV 1라운드 반증 실패 후 **verified 마커 생성 전에** 외부 CLI 교차 반증을 삽입한다 — **외부 반증도 실패해야 마커가 생성**된다(마커 사후 제거·refuted 병기 경로 원천 배제).\n\n- **실행**: 오케스트레이터가 FV 디스패치 프롬프트에 cross-check 지시를 포함 — FV가 마커 생성 직전 etc:with 라우팅 규약(`which` 기반 가용성 감지, Codex `codex exec` \u002F Antigravity `agy -p`)으로 task AC + diff를 외부 CLI에 전달해 독립 반증시킨다. 마커 생성 전 실행이라 SubagentStop 집행과 순서 충돌이 없다.\n- **외부 반증 성공 시**: 마커 미생성 + `refuted\u002F{task-id}`에 외부 근거 기록 → FB 수정 후 round=2 재검. 외부 반증에도 '구체 근거 없는 FAIL 금지' 규약이 동일 적용된다(오반증 방지).\n- **폴백**: 외부 CLI 미설치(`which` 전건 실패) 시 기존 동일 모델 max 2라운드 규약으로 graceful 폴백(1줄 고지).\n\n## Loop Control (Stage C) — 정지조건 4결합\n\n판정 주체는 모델이 아니라 Stop훅:\n\n| # | 조건 | 메커니즘 |\n|---|------|---------|\n| ① | 결정론 게이트 | `.planning\u002Fgate-cmd` 동적 로드(`LOOP_TEST_CMD` 우선) → exit code 우선 AND `jq '[.tasks[].passes]|all'` |\n| ②ᴿ | **baseline 회귀 게이트** | `.planning\u002Fbaseline.json` 기준선 대비 신규 실패 0. baseline green→gate green이 곧 회귀 0 \u002F baseline red→현재 fail_count ≤ 기준선. 부재 시 미적용(호환) |\n| ② | 회의적 Evaluator | `passes:true` 전환은 FV의 `.planning\u002Fverified\u002F{id}` 마커 선행 — `tasks-guard.sh`가 마커 없는 마킹 exit 2 차단 + Stop훅 재검사 |\n| ②ᴱ | E2E 수용 게이트(선택) | `.planning\u002Fe2e-gate-cmd` 존재 시 all-passes 도달 시 1회 실행 |\n| ③ | Completion promise | `progress.md`에 `\u003Cpromise>FEATURE_COMPLETE\u003C\u002Fpromise>` 정확 문자열(grep -qF) |\n\n종료 허용 = **① ∧ ②ᴿ ∧ ②ᴱ ∧ ③** (②는 ①의 all-passes에 마커 재검사로 인입).\n\n**가드레일 5종**: max iterations(`LOOP_MAX_ITER=24` — 세션 내 실효 8, Stop훅 8블록 오버라이드 실측) · no-progress(실패 시그니처 연속 2회) · 시간 상한(`LOOP_MAX_MINUTES=120`) · 킬스위치(`\u002Ffloop-stop`) · circuit breaker(동일 task 3연속 실패 → skip+BLOCKED). **안전핀**: `loop-active` 없으면 Stop훅 무동작(exit 0).\n\n## Gate Policy (자율 통과 + 실패 시만 보고)\n\n| 결과 | 동작 |\n|------|------|\n| **통과** | 사용자 확인 없이 다음 Stage 자동 진행. 1줄 보고 |\n| **실패** | 진행 중단. 실패 Stage·원인·시도·옵션 보고 |\n| **모호** | 진행 중단. 불명확 지점 + 권장안 보고 |\n\n**사용자 게이트는 정확히 1개**: **G1 — 작업 목록 승인**(Stage B 종료). `--auto`면 자동 채택·스탬프(해커톤\u002F실험용 1줄 고지).\n\n## 협업 호출 규약 (루프 안에서 기존 하네스 활용)\n\n| 시점 | 호출 대상 | 용도 |\n|------|----------|------|\n| Stage B 분해 | `workflow:planning-guide`, `workflow:spec-driven-dev` | 수직 슬라이싱·task 사이징 |\n| Stage C 구현(FB) | 스택 플러그인 `*-gen`\u002F`*-guide`(kotlin-spring·python-fastapi·go-mux·nextjs), `test:tdd` | 스택 자동 감지 후 관용 구현·테스트 먼저 |\n| Stage C 검증(FV) | `analyze:arch-reviewer`·`perf-reviewer`, `backend-shared:security-check` | 테스트가 못 잡는 구조·성능·보안 회귀 렌즈 |\n| 완료 후 | `workflow:shipping-guide`, `workflow:review-mr` | 배포 전 체크·MR 리뷰 |\n\n## Agent Dispatch\n\n```\nAgent({\n  description: \"{에이전트명} — {Stage 요약}\",\n  subagent_type: \"{agent-id}\",\n  prompt: \"{읽어야 할 .planning 파일 경로, 코드베이스 탐색 범위, 산출물 작성 경로,\n           통과할 게이트 기준(gates\u002F*.sh 판정 항목). checker에는 '반증 실패 시 통과,\n           반증에는 구체 근거' + baseline.json 회귀 대조를 명시. 출력 형식 지정.}\"\n})\n```\n\n## Completion Criteria\n\n- [ ] `tasks.json` 전 task `passes:true` (jq all-passes 그린)\n- [ ] 모든 `passes:true` task에 `.planning\u002Fverified\u002F{task-id}` 마커 존재\n- [ ] `gate-cmd` 최종 1회 독립 재실행 exit 0\n- [ ] **baseline 회귀 0** — 현재 실패 수 ≤ `baseline.json` 기준선\n- [ ] (E2E 적용 시) `e2e-gate-cmd` 최종 exit 0\n- [ ] `progress.md`에 `\u003Cpromise>FEATURE_COMPLETE\u003C\u002Fpromise>` 정확 문자열\n- [ ] task별 `feat: T-xx` 커밋이 git log에 존재\n- [ ] 마스터 `floop-{id}.md` `status: done` + ## Gates에 G1 승인 스탬프\n- [ ] `loop-active` 삭제 확인\n- [ ] 최종 보고: 완료 task n\u002Fm, 핵심 커밋, 회귀 0 확인, 잔여 리스크, 배포 전 체크 안내\n\n## Error Handling\n\n| 상황 | 대응 |\n|------|------|\n| 게이트 실패 (`gates\u002F*.sh` exit≠0) | Stage 중단. 실패 항목·원인·옵션 보고. maker 수정 후 `\u002Ffloop-gate` 재판정 |\n| **회귀 감지** (②ᴿ exit 2) | 루프가 재주입 — FB가 신규 실패를 구현 수정으로 0 복구(기존 테스트 수정 금지) |\n| no-progress (동일 실패 2회) | 루프 종료 + BLOCKED.md 기록 후 보고 |\n| 시간 상한 초과 | 현 반복 완료 후 종료. `\u002Ffloop-run` 재개 방법 보고 |\n| circuit breaker (동일 task 3연속 실패) | skip + BLOCKED 기록, 다음 task |\n| BLOCKED 에스컬레이션 | **스코프 결함 → TP 재분해** \u002F **구조 한계 → 스택 플러그인 가이드 참조·사용자 보고** |\n| `loop-active` 잔존 | `\u002Ffloop-status`가 감지·수동 해제(`rm .planning\u002Floop-active`) |\n| 테스트 삭제 시도 | `test-guard.sh` exit 2 차단 |\n\n## Boundaries\n\n**Will:**\n- Stage A~C 상태기계 관리, 게이트 판정 위임·결과 보고\n- TP\u002FFV 디스패치와 Producer-Reviewer 라운드 관리\n- Stage C 루프 가동·가드레일 집행·BLOCKED 라우팅\n- baseline 캡처·회귀 게이트 운영, `.planning\u002F` 메모리·재개 프로토콜 유지\n- 루프 안에서 스택 플러그인·analyze·test·workflow 협업 호출\n\n**Will Not:**\n- 게이트 검증 없이 다음 Stage 진행\n- 사용자 게이트(G1 작업 목록)를 `--auto` 없이 자율 통과\n- FV의 verified 마커 없이 `passes:true` 마킹(tasks-guard 차단)\n- 그린필드 신규 서비스 기획(mvp 위임)·실제 운영 배포·인프라 프로비저닝\n","# Feature Loop Orchestrator (브라운필드)\n\n자연어 기능 요청 한 줄을 **기존 코드베이스 위에서** 회귀 없이 완주시키는 오케스트레이터. Stage A~C 파이프라인을 게이트 기반 상태기계로 관리하고, 각 Stage의 maker\u002Fchecker를 전문 에이전트에게 위임하며, Stage C는 Stop훅 루프 엔진으로 자율 반복한다.\n\n핵심 명제: **\"완료 판정은 모델이 아니라 하네스가 한다.\"** 브라운필드 추가 명제: **\"회귀 없음도 하네스가 baseline 대비로 판정한다.\"**\n\n## When to Apply\n\n**발동:**\n- \"이 기능 추가해줘\", \"X 리팩토링해줘\", \"이 코드베이스에 Y 붙여줘\" — 이미 코드가 있는 프로젝트의 기능 추가·수정·리팩토링\n- 자연어 요청 + 여러 task로 분해해 반복 구현이 필요할 때\n- `\u002Ffloop-new`(시작), `\u002Ffloop-run`(재개) 커맨드 실행 시\n\n**미발동 (위임 경계):**\n- 빈\u002F신규 레포에서 기획(PRD)부터 시작하는 그린필드 신규 서비스 → **mvp 플러그인**\n- 단일 파일 1줄 수정·즉답 가능한 작업 → 루프 불필요, 직접 수행\n- 기획 문서\u002F디자인만 단건 작성 → 해당 플러그인 스킬 직접 사용\n\n## Architecture\n\n- **패턴**: Sequential Pipeline(A~C 상태기계) + Producer-Reviewer(maker\u002Fchecker) + Regression-Safe Loop(Stage C)\n- **실행 모드**: Sub-agents — 메인 세션이 오케스트레이터로 TP\u002FFV를 `Agent` 디스패치. **Stage C의 maker(FB)는 메인 세션이 규율을 체화해 직접 수행**(Stop훅이 메인 세션 종료를 가로채는 구조).\n- **메모리**: `.planning\u002F` + git history = 상태. 매 세션 아티팩트에서 이해 재생성.\n- **MVP 대비 차이**: 생성 단계(PRD·디자인·스캐폴딩) 제거. 대신 **코드베이스 분석 기반 분해 + baseline 캡처**가 입력. 게이트 방향이 \"생성 검증\"에서 \"회귀 방지\"로 전환.\n\n## Team Members\n\n| ID | 에이전트 파일 | 역할 | 산출물 |\n|----|--------------|------|--------|\n| TP | `agents\u002Ftask-planner.md` | 작업 분해 maker — 코드베이스 분석 → tasks.json. **Stage B checker 겸 아님**(분해 반증은 FV). BLOCKED 재분해 | `.planning\u002Ftasks.json` 초안 |\n| FB | `agents\u002Ffeature-builder.md` | 개발 루프 maker(메인 세션 체화) — 미완 task 1개씩 테스트 먼저 → 최소 구현 → 게이트 그린+회귀 0 → FV 검증 후 일괄 커밋 | task별 구현+테스트+`feat: T-xx` 커밋, progress 갱신 |\n| FV | `agents\u002Ffeature-verifier.md` | 회의적 checker — task AC 반증 + **회귀 반증**(baseline 대조) + 사기 적발 + (선택)analyze 렌즈. Edit 미보유 | 반증 리포트, `.planning\u002Fverified\u002F{task-id}` 마커 |\n\n## Orchestration Phases\n\n### Stage A: 인테이크 + baseline 캡처 (`\u002Ffloop-new`)\n\n- **Assigned to**: 메인 세션(오케스트레이터)\n- **Input**: 자연어 요청 한 줄 (+ `--auto`, `--gate-cmd`, `--tasks-max`)\n- **Output**: `.planning\u002Frequest.md`(원본 불변) + 마스터 `floop-{id}.md`(## Goal 불변) + `.planning\u002Fgate-cmd` + `.planning\u002Fbaseline.json`\n- **동작**:\n  1. `request.md` 기록 + 마스터 생성.\n  2. **스택 자동 감지** → gate-cmd 결정 (`build.gradle*`→`.\u002Fgradlew test`, `pyproject.toml`→`pytest -q`, `package.json`+next→`pnpm test`, `go.mod`→`go test .\u002F...`). 모호 시 사용자 확인 또는 `--gate-cmd` 명시.\n  3. **baseline 캡처** — `hooks\u002Fgates\u002Fcapture-baseline.sh` 실행 → `baseline.json`. baseline red면 기존 실패 수를 1줄 경고(회귀 게이트가 fail_count ≤ N로 동작).\n- **게이트**: gate-cmd 실행 가능 확인. 사용자 게이트 없음.\n\n### Stage B: 작업 분해 (`task-planner` maker → `feature-verifier` checker)\n\n- **Assigned to**: TP(Agent 디스패치) → FV(분해 반증) → 메인 세션 사용자 게이트\n- **Input**: `request.md` + 코드베이스\n- **Output**: `.planning\u002Ftasks.json` (`{\"tasks\":[{\"id\":\"T-01\",\"title\",\"acceptance\":[],\"passes\":false}]}`)\n- **결정론 게이트**: `hooks\u002Fgates\u002Fgate-tasks.sh --initial` — jq 스키마 + 개수 2~`FLOOP_TASKS_MAX`(기본 10) + passes 전건 false\n- **사용자 게이트 ★G1 — 작업 목록 승인**(항상; `--auto`면 자동 채택·스탬프): 분해 task 목록 + 영향 파일 + 회귀 위험을 제시하고 승인\n\nTP가 코드베이스를 탐색해 수직 슬라이스로 분해 → FV가 \"이 분해가 틀렸다면 왜?\"로 반증(범위 비대·검증 불가 AC·회귀 보존 AC 누락) → 근거 있는 반증은 TP가 수정. 분해 표준은 `task-decomposition` 스킬 참조.\n\n### Stage C: 회귀 안전 개발 루프 (`feature-builder` 체화 → `feature-verifier` 매 task)\n\n- **Assigned to**: 메인 세션(FB 규율 체화) → FV(매 task Agent 디스패치)\n- **Input**: 확정 tasks.json + gate-cmd + baseline.json + 게이트 그린 상태의 레포\n- **Output**: 전 task `passes:true` + `.planning\u002Fverified\u002F` 마커 전건 + `progress.md`의 `\u003Cpromise>FEATURE_COMPLETE\u003C\u002Fpromise>` + task별 커밋\n- **게이트**: Stop훅 루프 엔진(`hooks\u002Ffloop-loop-stop-hook.sh`)이 매 반복 정지조건 4결합 판정. 사용자 게이트 없음 — 자율, BLOCKED 시만 보고.\n\nStage C 진입은 항상 `\u002Ffloop-run` 절차(`loop-active` 생성·`loop-state.json` 초기화)를 경유. 매 반복 표준 사이클: 미완 task 1개 → 테스트 먼저 → 최소 구현(스택 플러그인 활용) → 게이트 그린+회귀 0 → FV 반증 → verified 마커 → passes:true → 커밋 1회. 상세는 `floop-loop-protocol` 스킬 참조. **완료 후** `workflow:shipping-guide`로 배포 전 체크를 안내(루프 밖, 보고).\n\n#### FV 디스패치 규약 — verify-round 상태 파일\n\ntask AC·회귀 반증(모드 ②) 디스패치의 오케스트레이터 의무 3가지 — SubagentStop 훅이 이 규약을 결정론 집행한다(마커 없는 verifier 종료를 exit 2 차단, round>=2는 최대 2라운드 규약으로 통과 허용).\n\n1. **디스패치 직전**: `.planning\u002Fverify-round\u002F{task-id}`에 `round=1`(maker 수정 후 재검이면 `round=2`) 기록\n2. **결과 규약**: 반증 실패(통과) → FV가 `verified\u002F{task-id}` 생성(기존 규약) \u002F 반증 성공 → `refuted\u002F{task-id}`에 구체 근거(파일:라인·실행 출력·재현 명령) 기록\n3. **결과 처리 후**: `refuted`를 FB 수정 라운드 입력으로 소비하고 `verify-round\u002F{task-id}`를 정리(삭제)한다\n\n훅은 동일 pending 차단을 2회로 제한하고(`blocked=N` 카운터), 초과 시 스테일로 간주해 `verify-round\u002F{task-id}`를 자동 정리한다 — verifier 재디스패치 필요.\n\n#### --cross-check 교차 모델 반증 (opt-in, 기본 off)\n\n`\u002Ffloop-run --cross-check` 지정 시 FV 1라운드 반증 실패 후 **verified 마커 생성 전에** 외부 CLI 교차 반증을 삽입한다 — **외부 반증도 실패해야 마커가 생성**된다(마커 사후 제거·refuted 병기 경로 원천 배제).\n\n- **실행**: 오케스트레이터가 FV 디스패치 프롬프트에 cross-check 지시를 포함 — FV가 마커 생성 직전 etc:with 라우팅 규약(`which` 기반 가용성 감지, Codex `codex exec` \u002F Antigravity `agy -p`)으로 task AC + diff를 외부 CLI에 전달해 독립 반증시킨다. 마커 생성 전 실행이라 SubagentStop 집행과 순서 충돌이 없다.\n- **외부 반증 성공 시**: 마커 미생성 + `refuted\u002F{task-id}`에 외부 근거 기록 → FB 수정 후 round=2 재검. 외부 반증에도 '구체 근거 없는 FAIL 금지' 규약이 동일 적용된다(오반증 방지).\n- **폴백**: 외부 CLI 미설치(`which` 전건 실패) 시 기존 동일 모델 max 2라운드 규약으로 graceful 폴백(1줄 고지).\n\n## Loop Control (Stage C) — 정지조건 4결합\n\n판정 주체는 모델이 아니라 Stop훅:\n\n| # | 조건 | 메커니즘 |\n|---|------|---------|\n| ① | 결정론 게이트 | `.planning\u002Fgate-cmd` 동적 로드(`LOOP_TEST_CMD` 우선) → exit code 우선 AND `jq '[.tasks[].passes]|all'` |\n| ②ᴿ | **baseline 회귀 게이트** | `.planning\u002Fbaseline.json` 기준선 대비 신규 실패 0. baseline green→gate green이 곧 회귀 0 \u002F baseline red→현재 fail_count ≤ 기준선. 부재 시 미적용(호환) |\n| ② | 회의적 Evaluator | `passes:true` 전환은 FV의 `.planning\u002Fverified\u002F{id}` 마커 선행 — `tasks-guard.sh`가 마커 없는 마킹 exit 2 차단 + Stop훅 재검사 |\n| ②ᴱ | E2E 수용 게이트(선택) | `.planning\u002Fe2e-gate-cmd` 존재 시 all-passes 도달 시 1회 실행 |\n| ③ | Completion promise | `progress.md`에 `\u003Cpromise>FEATURE_COMPLETE\u003C\u002Fpromise>` 정확 문자열(grep -qF) |\n\n종료 허용 = **① ∧ ②ᴿ ∧ ②ᴱ ∧ ③** (②는 ①의 all-passes에 마커 재검사로 인입).\n\n**가드레일 5종**: max iterations(`LOOP_MAX_ITER=24` — 세션 내 실효 8, Stop훅 8블록 오버라이드 실측) · no-progress(실패 시그니처 연속 2회) · 시간 상한(`LOOP_MAX_MINUTES=120`) · 킬스위치(`\u002Ffloop-stop`) · circuit breaker(동일 task 3연속 실패 → skip+BLOCKED). **안전핀**: `loop-active` 없으면 Stop훅 무동작(exit 0).\n\n## Gate Policy (자율 통과 + 실패 시만 보고)\n\n| 결과 | 동작 |\n|------|------|\n| **통과** | 사용자 확인 없이 다음 Stage 자동 진행. 1줄 보고 |\n| **실패** | 진행 중단. 실패 Stage·원인·시도·옵션 보고 |\n| **모호** | 진행 중단. 불명확 지점 + 권장안 보고 |\n\n**사용자 게이트는 정확히 1개**: **G1 — 작업 목록 승인**(Stage B 종료). `--auto`면 자동 채택·스탬프(해커톤\u002F실험용 1줄 고지).\n\n## 협업 호출 규약 (루프 안에서 기존 하네스 활용)\n\n| 시점 | 호출 대상 | 용도 |\n|------|----------|------|\n| Stage B 분해 | `workflow:planning-guide`, `workflow:spec-driven-dev` | 수직 슬라이싱·task 사이징 |\n| Stage C 구현(FB) | 스택 플러그인 `*-gen`\u002F`*-guide`(kotlin-spring·python-fastapi·go-mux·nextjs), `test:tdd` | 스택 자동 감지 후 관용 구현·테스트 먼저 |\n| Stage C 검증(FV) | `analyze:arch-reviewer`·`perf-reviewer`, `backend-shared:security-check` | 테스트가 못 잡는 구조·성능·보안 회귀 렌즈 |\n| 완료 후 | `workflow:shipping-guide`, `workflow:review-mr` | 배포 전 체크·MR 리뷰 |\n\n## Agent Dispatch\n\n```\nAgent({\n  description: \"{에이전트명} — {Stage 요약}\",\n  subagent_type: \"{agent-id}\",\n  prompt: \"{읽어야 할 .planning 파일 경로, 코드베이스 탐색 범위, 산출물 작성 경로,\n           통과할 게이트 기준(gates\u002F*.sh 판정 항목). checker에는 '반증 실패 시 통과,\n           반증에는 구체 근거' + baseline.json 회귀 대조를 명시. 출력 형식 지정.}\"\n})\n```\n\n## Completion Criteria\n\n- [ ] `tasks.json` 전 task `passes:true` (jq all-passes 그린)\n- [ ] 모든 `passes:true` task에 `.planning\u002Fverified\u002F{task-id}` 마커 존재\n- [ ] `gate-cmd` 최종 1회 독립 재실행 exit 0\n- [ ] **baseline 회귀 0** — 현재 실패 수 ≤ `baseline.json` 기준선\n- [ ] (E2E 적용 시) `e2e-gate-cmd` 최종 exit 0\n- [ ] `progress.md`에 `\u003Cpromise>FEATURE_COMPLETE\u003C\u002Fpromise>` 정확 문자열\n- [ ] task별 `feat: T-xx` 커밋이 git log에 존재\n- [ ] 마스터 `floop-{id}.md` `status: done` + ## Gates에 G1 승인 스탬프\n- [ ] `loop-active` 삭제 확인\n- [ ] 최종 보고: 완료 task n\u002Fm, 핵심 커밋, 회귀 0 확인, 잔여 리스크, 배포 전 체크 안내\n\n## Error Handling\n\n| 상황 | 대응 |\n|------|------|\n| 게이트 실패 (`gates\u002F*.sh` exit≠0) | Stage 중단. 실패 항목·원인·옵션 보고. maker 수정 후 `\u002Ffloop-gate` 재판정 |\n| **회귀 감지** (②ᴿ exit 2) | 루프가 재주입 — FB가 신규 실패를 구현 수정으로 0 복구(기존 테스트 수정 금지) |\n| no-progress (동일 실패 2회) | 루프 종료 + BLOCKED.md 기록 후 보고 |\n| 시간 상한 초과 | 현 반복 완료 후 종료. `\u002Ffloop-run` 재개 방법 보고 |\n| circuit breaker (동일 task 3연속 실패) | skip + BLOCKED 기록, 다음 task |\n| BLOCKED 에스컬레이션 | **스코프 결함 → TP 재분해** \u002F **구조 한계 → 스택 플러그인 가이드 참조·사용자 보고** |\n| `loop-active` 잔존 | `\u002Ffloop-status`가 감지·수동 해제(`rm .planning\u002Floop-active`) |\n| 테스트 삭제 시도 | `test-guard.sh` exit 2 차단 |\n\n## Boundaries\n\n**Will:**\n- Stage A~C 상태기계 관리, 게이트 판정 위임·결과 보고\n- TP\u002FFV 디스패치와 Producer-Reviewer 라운드 관리\n- Stage C 루프 가동·가드레일 집행·BLOCKED 라우팅\n- baseline 캡처·회귀 게이트 운영, `.planning\u002F` 메모리·재개 프로토콜 유지\n- 루프 안에서 스택 플러그인·analyze·test·workflow 협업 호출\n\n**Will Not:**\n- 게이트 검증 없이 다음 Stage 진행\n- 사용자 게이트(G1 작업 목록)를 `--auto` 없이 자율 통과\n- FV의 verified 마커 없이 `passes:true` 마킹(tasks-guard 차단)\n- 그린필드 신규 서비스 기획(mvp 위임)·실제 운영 배포·인프라 프로비저닝\n",{"name":5,"description":7},"main","e9f37e996e3d2b1b6ac9c879e9dfba1223b597c3","archive\u002Ffeature-loop\u002Fskills\u002Ffeature-loop-orchestrator",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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Dokkabei97\u002Fdokkabei-harness --skill feature-loop-orchestrator",{"tool":64,"command":65},"bunx","bunx skills add Dokkabei97\u002Fdokkabei-harness --skill feature-loop-orchestrator",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Dokkabei97\u002Fdokkabei-harness --skill feature-loop-orchestrator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDokkabei97\u002Fdokkabei-harness\u002Fblob\u002Fmain\u002Farchive\u002Ffeature-loop\u002Fskills\u002Ffeature-loop-orchestrator\u002FSKILL.md",true,[],[73,101,130,153,172,195],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":82,"publishedAt":44},"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",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[83,84,85,86,87,88,89,90,91,92,93,94,95,96,28,97,98,99,100,29],"sync","claude md","sync claude md","MCP","commit","architecture","pr","update","ci","integrations","use","diff","only","minimal","make","reviews","pending","mr",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":113,"publishedAt":44},"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",[107,108],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[114,115,116,117,118,119,120,121,43,122,123,124,125,126,28,27,127,128,129,29],"spec","spec driven","dev","spec driven dev","driven","review","workflow","change","code","plan","ask","never","human","for","vague","features",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":44},"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",[],[137,138,139,140,141,142,143,123,144,145,93,146,147,27,148,149,150,151,152,29],"shipping","guide","shipping guide","launch","monitoring","lifecycle","feature flags","template","rollback","rollout","flags","thresholds","post","with","pre-launch","rollback plan",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":44},"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",[],[155,119,83,43,42,160,25,161,162,163,164,165,95,166,167,168,169,170,171,29],"harness","evolve","write","edit","proposals","session","up","dry","learned","Session Retrospective","lessons","mistakes",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":44},"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",[178],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},[180,28,181,182,183,122,184,185,186,187,94,95,188,189,190,191,192,193,194,29],"Rules","project rules","core","generate","git","audit","stack","orm","es","drift","layout","runtime","-specialist","path","scoped",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":205,"publishedAt":44},"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",[201,204],{"categoryNo":202,"categoryName":203,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},[206,207,149,208,209,90,210,211,212,166,213,214,215,216,217,218,219,220,100,29],"merge","post merge","documentation","cleanup","batch","wiki","just","issue","tracker","close","closing","follow-up","true","plane","single"]