forge 스킬 상세

README의 「스킬 카탈로그」를 풀어 쓴 문서. 각 스킬의 입력·출력·다음 단계, 그리고 트리거·동작·근거 ADR을 담는다. 한눈에 보는 요약 표는 README를 보라.

스킬 카탈로그 (전체 6열)

스킬	단계	한 줄 역할	입력	출력	다음
fg-ask	① 질의·계획	grill-with-docs 원문 그대로 — 계획을 도메인·용어·결정에 대고 그릴링	사용자 요청	.forge/backlog/<slug>.md + CONTEXT/ADR	fg-run
fg-run	② 실행	호스트 어댑터로 실행 — Claude Code는 Dynamic Workflow, Codex는 collaboration/subagent; 위임 불가 시 직렬 fallback	.forge/backlog/, plan.md	결과 + .forge/run.md + STATUS.md (또는 executed/)	fg-learn
fg-learn	③ 회고	학습을 문서로 승급(기계 확인 가능한 학습은 eval — 영속 회귀 체크 — 로 승급), 다음 질의 도출	.forge/run.md, plan.md, executed/	.forge/retro/*.md + 승급	fg-done (크게 어긋났으면 fg-ask로 재그릴링)
fg-done	④ 완료	한 바퀴 정리 — 회고 확인, STATUS.md를 done으로 마감, 아카이브, 활성 상태 비우기, 루프 닫기. 기계적 봉인은 결정론 스크립트(forge-done.sh/.js)가 처리(ADR-0030). all 모드는 실행된 작업 일괄 봉인(회고 skip·백로그 불가침)	.forge/*	.forge/done/<날짜-slug>/	fg-ask / 종료
fg-map	유틸리티(루프 밖)	병렬 서브에이전트로 코드베이스를 .forge/codebase/에 매핑해, 그릴링이 코드를 다시 탐색하지 않고 지도를 읽게 한다(context rot 감소)	코드베이스	.forge/codebase/*.md (7개 문서)	— (fg-ask가 소비)
fg-quick	경량 차선(루프 밖)	사소한 작업용 — 가볍게 그릴링한 뒤 형식 산출물(ADR/plan/회고) 없이 바로 실행; 비-trivial로 드러나면 fg-ask로 bail	사용자 요청	.forge/quick/LOG.md에 항목 하나	— (자체 완결)
fg-status	리포터(루프 밖)	읽기 전용 — .forge/를 조사해 모든 작업의 현황과 지금 필요한 다음 단계 하나를 출력; 아무것도 쓰지 않고 자동 실행도 안 함	.forge/* (읽기 전용)	출력 보고(파일 없음)	— (다음 단계 제안)
fg-next	오케스트레이터(루프 밖)	fg-status의 상태 머신으로 다음 단계 하나를 도출해 한 줄로 알린 뒤 그 스킬을 곧바로 실행 — 보고만 하지 않음, one-shot; fg-status는 보고, fg-next는 행동	.forge/* (자신은 읽기 전용)	없음 — 호출한 스킬에 위임	— (다음 스킬을 호출)
fg-loop	오케스트레이터(루프 밖)	goal 주도 한정 재계획 루프 — 정지 체크·fix-forward 범위·상한을 못 박고 run → UAT → 회고 skip → 봉인을 주행; failed active task는 제자리 수리, 빈 슬롯의 실패 체크는 새 plan 생성	goal(질의), .forge/loop.md, backlog/	봉인된 작업들 + repaired-by 제자리 수리 / generated-by fix-forward plan	— (종료 보고; 추후 fg-learn으로 일괄 승급)
fg-config	설정(루프 밖)	.forge/config.json 여섯 키(simple·eco·tdd·driveCommit·driveCommitMessage·defaultBranch)의 통합 설정 진입점 — fg-config(무인자)는 전체 설정 표+변경 메뉴, fg-config <key> <값>은 설정. simple은 자동 봉인 모드(fg-run이 UAT 후 같은 턴에 회고 skip+봉인, 검증 게이트 불가침), eco·tdd 의미론은 불변. 옛 키별 토글 스킬 대체(ADR 260905-212045)	<key> <값>/(없음)	.forge/config.json	— (설정만)
fg-merge	통합기(루프 밖)	git merge 뒤 브랜치 forge root 통합 — **결정론 스크립트(forge-merge.sh/.js)**가 시간ID ADR을 그대로 이동(충돌 시 다음 글자, cascade 재번호 없음)·task 번호 재부여·CONTEXT/retro/done/backlog 병합, 구조 충돌 시 nonzero exit(AI 없이 CI 게이트 가능). 코어 스크립트는 git-free(CI)·fg-merge <branch>는 대화형에서 git merge 대행(ADR 260717-10a)·fg-merge to main은 feature 브랜치에서 커밋→머지→통합→커밋까지(ADR 261006-102435)	.forge/branch/<branch>/	통합된 .forge/ 문서	— (통합 단계)
fg-cleanup	은퇴기(루프 밖)	오래된/대체된 ADR을 활성 결정 집합에서 은퇴 — 후보를 근거와 함께 제시하고, 승인 시 각 ADR을 .forge/adr/retired/<NNNN>-slug.md로 이동+supersede/retire 마킹. 번호 불변·재사용 금지·삭제 안 함. fg-ask는 retired/를 정답소스로 안 읽음	.forge/adr/*.md	.forge/adr/retired/*	— (ADR 정비)
fg-statusline	설정 유틸리티(루프 밖)	statusline에 forge 진행 상태를 두 모드 중 하나로 표시 — 방법 1(append)은 기존 statusline을 아래 별도 줄로 자동 래핑(얇은 forge fragment, ADR-0017), 방법 2(merge)는 daleseo식 시스템 정보(모델·디렉터리·⎇git·Context/크기+그라디언트 바+$비용/±라인/경과)+forge 진행을 의미 단위 그룹 대괄호로 한 스크립트에 출력하며 compact/full 밀도 토글(command 인자)까지 갖춘 통합 스크립트 설치(ADR-0029)	기존 settings.json	~/.claude/의 statusline 스크립트 + statusLine 설정	— (터미널 표시)
fg-adversarial-review	리뷰 유틸리티(루프 밖)	fg-run↔fg-learn 사이 선택적 적대적 리뷰 — findings 기록, 승인된 코드 결함은 fix-forward plan으로 적재; 원 작업을 회고·봉인해 슬롯을 비운 뒤 fix plan 실행	active plan.md·run.md·작업트리 diff·CONTEXT/ADR	.forge/review.md + (승인 시) fix-forward backlog plan	fg-learn → fg-done → fg-run
fg-doctor	health check(루프 밖)	읽기 전용 무결성 검사 — 결정론 스크립트(forge-doctor.sh/.js, exit 0/1/2로 AI 없이 CI 게이트)가 .forge/ 상태 계약(고아·STATUS 필드·slug 페어링·half-sealed·고아 브랜치 루트=fg-merge 잊음)과 문서/매니페스트 정합(버전 4곳 동기·README 이중언어·CLAUDE.md 스킬 목록·두 형식 ADR ID 유일성), 그리고 스킬 본문의 상호참조 정합(§N 자기참조 — 조건부 분할이 남긴 빈 포인터를 잡는 부분 가드)을 검사해 위반을 severity·수정 안내와 함께 보고; 아무것도 안 쓰고 자동 수정 안 함	.forge/*·매니페스트·README·CLAUDE.md (읽기 전용)	출력 보고(파일 없음)	— (fg-quick/fg-ask로 수정)
fg-help	도움말 리포터(루프 밖)	읽기 전용 사용법 도움말 — /forge:fg-help(무인자)는 forge 스킬 전체를 루프 4단계 + 루프 밖 유틸리티로 그룹핑한 개요를, /forge:fg-help <명령>은 개별 스킬의 4줄 상세(무엇·언제·트리거·다음단계)를 출력. 각 skills/*/SKILL.md의 frontmatter description을 단일 소스(사본 0)로 읽어 사용자 언어로 LLM 렌더 — 번역이 스크립트로 불가해 결정론 트윈 없음(fg-status/fg-doctor와 다른 점). 아무것도 안 쓰고 자동 실행 안 함	skills/*/SKILL.md — Glob path를 플러그인 skills/로 고정 (읽기 전용)	출력 보고(파일 없음)	— (문서 유틸리티)
fg-drop	폐기 유틸리티(루프 밖)	미완 작업 폐기 — 단일/소수/다수에 맞는 선택 UI, goal 루프는 loop.md+멤버 미완 상태를 통째로 삭제/보관(done·비멤버 불변); forge 상태만 지움	.forge/*(미봉인)	하드 삭제 또는 .forge/dropped/<slug>/	— (자체 완결)
fg-agents	생성 유틸리티(루프 밖)	대화형 그릴링으로 프로젝트 도메인을 캐 역할을 도출하고 표준 .claude/agents/<role>.md 카드 생성(description에 "언제 쓰이나" 포함 → fg-run이 slice↔role 자동 매핑). 활성 ADR을 연료로 읽어 카드에 프로젝트 결정을 가볍게 반영. 카드는 세션 시작 시 로드되므로 생성 후 재시작 필요(ADR-0024). graceful·선택적	.forge/codebase/·CONTEXT.md·활성 .forge/adr/(선택 연료)	.claude/agents/<role>.md 카드	— (재시작 후 fg-run이 활용)
fg-showme	시각 유틸리티(루프 밖)	브라우저 시각 컴패니언 — obra/superpowers v6.1.1 Visual Companion vendoring(MIT 귀속, v6.3.0까지 엔진 동일 확인 — 포팅할 업스트림 변경 없음). zero-dependency Node 서버가 에이전트가 push하는 HTML(목업·다이어그램·A/B 시각 비교)을 브라우저 탭에 실시간 표시하고, 사용자의 클릭·텍스트 입력을 이벤트(JSONL)로 받아 에이전트가 답으로 되읽음. event_wake 지원 호스트에서는 선택형 화면의 필수 확정 버튼이 터미널 턴 없이 에이전트를 깨우며, 미지원 호스트에서는 확정 뒤 터미널 입력 한 번이 필요하다(탐색 클릭은 깨우지 않음), fg-ask 그릴링 중 시각적 질문에서 just-in-time 1회 제안(거절 시 재제안 없음), 이 스킬은 단독 진입점(ADR 260719-224442·260730-224259·260805-005436)	에이전트가 push하는 HTML	모든 브랜치 최상위 .forge/showme/<세션>/(휘발·전역 예외) + 클릭 이벤트(JSONL)	— (fg-showme stop으로 종료)
fg-agenda	계획 유틸리티(루프 밖)	결정 대기열 — 아직 내리지 않은 결정이 사는 자리. 목적지를 사람과 먼저 정하고 breadth-first 그릴링으로 결정해야 할 것을 캐내 .forge/agenda.md 한 파일(목적지·결정된 것·열린 질문·아직 또렷하지 않은 것(fog)·범위 밖)에 담은 뒤, 질문을 하나씩 fg-ask의 방법으로 해소하고 열린 질문이 0이면 스스로 삭제한다. 캐내는 것은 에이전트, 답은 전부 사람(기둥 1)	느슨한 아이디어(open) 또는 기존 .forge/agenda.md(working)	.forge/agenda.md + 해소가 낳은 조건부 ADR (빌드 가능해진 결정은 fg-ask가 백로그 plan으로)	— (같은 대화에서 계속 다음 질문; 빌드 가능해지면 fg-ask)
fg-security	감사 유틸리티(루프 밖)	코드베이스 보안 감사 — cloudflare 방법론 vendoring; 산출물은 리포 밖; 심각도 게이트 통과분이 fix-forward plan	코드베이스 전체 + 이전 run의 findings.json(복수 실행으로 기존 finding 건너뛰고 빈틈 노림)	~/security-audit-skill/<repo>/run-N/(REPORT.md·FINDINGS-DETAIL.md·findings.json — 리포 밖) + 승인 시 .forge/backlog/*.md	fg-run(승인된 fix-forward plan 실행) — 봉인 게이트 아님
fg-debug	진단 유틸리티(루프 밖)	어려운 버그의 대화형 진단 규율 — diagnosing-bugs vendoring(MIT); red를 낼 수 있는 피드백 루프 구축·재현·최소화·가설 순위화, 진단 전용(수정은 루프의 것)	버그 리포트 + 프로젝트 워킹 트리	활성 실패면 기존 fg-run 복귀; 독립 진단이면 trivial은 fg-quick, non-trivial은 승인된 .forge/backlog/*.md; red 명령은 영속할 때만 eval, 원본 캡처는 리포 밖에서 전 종료 cleanup	fg-run(활성 실패 복귀 또는 승인된 fix plan 실행)

핸드오프 표 — 모든 다음 단계 안내의 공통 형태

스킬이 끝에서 내는 다음 단계 안내는 고정 4행 핸드오프 표(방금 한 것 · 다음 단계 · 시작하는 법 · 대안)로 렌더된다. 다음 단계가 산문 사이에 묻혀 안 보이던 문제를 형태로 고친 것이며(통증은 길이가 아니라 찾기 어려움이었다), eco 게이트와 무관하게 항상 적용된다 — ADR 260805-231104.

• 표는 사용자 언어로 렌더된다. 라벨의 canonical 이름은 영문(Just did · Next step · How to start · Alternative)이고 — 스킬 문서가 영문이므로 셀을 가리킬 때 쓰는 이름이다 — 화면에 나갈 때 사용자 언어로 번역된다(한국어 세션이면 위 네 라벨). 경로·.forge/ 필드·/명령만 verbatim이며, 자연어 트리거는 verbatim이 아니라 스킬 description에 등록된 한/영 트리거 중 사용자 언어에 맞는 것을 골라 채운다.

• 적용 15곳 — 루프 4단계(fg-ask·fg-run·fg-learn·fg-done) + 가리킬 다음 단계가 실재하는 유틸리티 11개(fg-status·fg-next·fg-loop·fg-quick·fg-map·fg-doctor·fg-agenda·fg-adversarial-review·fg-agents·fg-security·fg-debug).

• 제외 7곳 — fg-config·fg-statusline은 토글·설정이라 가리킬 다음이 없고 본문 한 줄이 표보다 짧다. fg-cleanup·fg-drop·fg-showme·fg-help은 다음 단계 안내를 애초에 내지 않는다. fg-merge는 가장 좁은 근거로 제외됐다 — 그것이 내는 것은 git 상태 복구 지시("충돌 해소 → git commit → fg-merge 재실행")이지 루프 핸드오프가 아니다.

• 표는 메뉴가 아니다. 진술형은 불변이다(ADR-0015) — AskUserQuestion으로 내지 않고, 대안 행은 고르라는 질문이 아니며, 알리고 멈춘다. 체이닝은 여전히 fg-next의 몫이다.

• 조건부 다음 단계는 우선순위 규칙으로 채운다. 한 분기를 행에 못 박고 나머지를 대안으로 밀면 표가 스킬이 방금 하지 말라고 한 것을 지시하게 된다(fg-run·fg-learn의 divergence 규칙이 그 예다).

• 무인 주행에서는 위임 스킬이 표를 렌더하지 않는다 — fg-next all·fg-loop에서 주행자가 억제하고 자기 단계(벽·완료)에만 낸다. 위임된 "fg-learn 실행" 안내가 사용자에게 새어 나가면 주행이 정지한다(DRIVE.md).

• eco 요약 표와는 다른 것이다 — 그쪽은 무엇을 했나(축은 슬라이스, eco: true에서만), 이쪽은 다음에 무엇을. 둘이 함께 뜨는 지점에서는 각자 상대가 소유한 행을 뺀다.

단일 정의는 skills/fg-next/HANDOFF.md 하나이며 15곳이 이를 참조한다(복붙 금지 — skills/fg-run/FORGE-ROOT.md·skills/fg-next/DRIVE.md와 같은 관례).

Explaining forge — forge가 자기 어휘를 설명하는 방식 (항상)

forge 출력은 자기 어휘를 독자가 안다고 가정해 왔다 — verified: failed·unsealed tail·"기둥 1"·wall: stalled-waiting은 문서를 안 읽은 사람에게 암호다. 그래서 22개 SKILL.md 전부가 **Language** 규칙 옆에 항상-on **Explaining forge** 규율을 담는다. eco 게이트와 무관하다 — ADR 260824-134246.

• 규칙 3개 — ① forge 전문용어는 한 메시지 안 첫 등장에서 즉시 주석(몇 단어, 문단 아님) ② 목적을 메커니즘보다 먼저 ③ 결론을 먼저 내고 사용자에게 갖는 의미로 닫기.
• eco에 넣지 않은 것이 핵심 결정이다. eco 기본값은 false이고, 주석을 가장 필요로 하는 사람 — forge를 방금 설치한 사용자 — 이 바로 eco를 켜 봤을 리 없는 사람이다. eco에 번들하면 규율이 거꾸로 배달된다. ADR-0014가 caveman을 eco에 번들한 것과 의도적으로 다른 결정이며, 차이의 근거는 caveman이 토큰 절약(축=비용)이고 이것은 정확한 전달(축=품질)이라는 것이다.
• ECO.md의 간결 규칙과 분업한다 — 간결 규칙은 형태(길이·군더더기), 이 규율은 어휘를 지배한다. 주석은 군더더기가 아니므로 간결함이 주석을 지우지 않는다. eco off = 장문+주석, on = 간결+주석 — 주석은 두 상태에서 불변이다.
• dreambigou의 eli5(MIT)에서 개념만 각색했다 — 코드 vendoring이 아니다(파일 복사 0). 청중 표(나이·학년·관계·직무 24행)는 버렸다: forge 출력을 5살이나 배우자나 디자이너가 읽지 않으므로 남길 청중 축이 없고, 청중 변화는 사람 사이가 아니라 숙련도 사이에 있다.
• 단일정의 문서를 만들지 않고 인라인했다 — 규칙이 3문장 1줄이라 참조 한 줄이 규칙 본문과 길이가 비슷해진다(HANDOFF.md·ECO.md는 파일을 벌지만 3줄은 못 번다). 대가인 22중 복제 드리프트는 fg-doctor 검사 B17이 막는다 — canonical 본문의 단일 정의(scripts/explaining-forge.rule.txt)를 22곳 전부에서 verbatim 포함으로 요구하므로, 헤딩만 남기고 본문을 삭제·축약·약화·반대로 쓴 경우까지 잡힌다. 포함(동일성 아님)이라 fg-ask의 의도된 상위집합(문장 하나 추가)은 예외 목록 없이 통과한다. severity는 warning — 형제 산문 드리프트 검사(B12·B13·B15·B16)와 같은 rubric이고, 스타일 문단 누락은 릴리스 파손이 아니다. 적용은 forge 리포에 한정된다(사용자 프로젝트의 자기 스킬은 오탐이 되므로 최상위 매니페스트 name으로 스코프를 좁혔다 — 중첩된 "author": {"name": "forge"}는 발동시키지 못한다).

루프 스킬 (4단계)

fg-ask — ① 질의·계획

fg-ask가 루프의 진입점이다 — 질의·분류와 그릴링을 함께 맡는다(기존 별도 fg-plan 단계를 fg-ask로 통합). "forge 시작", "새 작업", "이거 작업하자", "계획 다듬자" 같은 발화에서 트리거된다.

시작 시 미봉인 잔여를 닫는다 (STEP 0). 새 작업을 시작하려는데 지난 작업이 봉인 안 된 채 남아 있으면, 남은 판단의 양에 따라 갈린다 — 판단이 없으면(검증이 봉인 가능값이고 회고도 해결됨, 또는 회고만 밀렸는데 run.md의 divergence가 미미함) 묻지 않고 봉인하고 한 줄만 보고한 뒤 같은 턴에 그릴링을 계속한다. 판단이 남았으면(고-divergence·verified: pending·verified: failed·멈춘 goal 루프) 종전처럼 묻지만, 당신의 새 요청을 붙들고 있다가 마감 후 그 자리로 돌아온다 — "끝낸 뒤 fg-ask를 다시 치라"는 요구는 폐기됐다(그게 흐름을 끊던 본체였다). 사정거리는 활성 슬롯 1건이며 .forge/executed/의 park은 까먹은 잔여가 아니라 의도된 대기라 개수만 보고하고 손대지 않는다(fg-done all/fg-learn 소관). 검증 게이트(ADR-0009)는 불가침이고 fg-ask는 UAT를 직접 하지 않는다 (ADR 260727-201115).

fg-run — ② 실행

계획(.forge/plan.md, 또는 .forge/backlog/의 대기 plan)을 활성 호스트의 실행 어댑터로 실행한다. Claude Code는 Dynamic Workflow, Codex는 bounded collaboration/subagent를 사용하며 위임 도구가 없으면 직렬로 fallback한다. 선택·상태 전이·UAT·실행 기록 규칙은 양쪽에서 동일하다. 백로그에 미실행 plan이 정확히 하나면 확인 질문 없이 바로 실행하고, 여러 개면 호스트의 구조화 입력 또는 번호 목록으로 고른다.

프로젝트에 도메인 에이전트(.claude/agents/, 예: fg-agents가 생성)가 있으면 워크플로가 slice에 맞는 role을 agentType으로 호출해 실행한다 — role 카드 description의 "언제 쓰이나"로 매핑한다. 없으면 기존과 100% 동일(기본 워크플로 서브에이전트, graceful). 단 .claude/agents/는 세션 시작 시 1회 로드되므로 세션 중 새로 만든 카드는 재시작해야 호출 가능하고, eco가 켜지면 agentType 호출도 sonnet 캡·ECO.md 주입을 받되 role 카드의 model: 명시가 우선한다(ADR-0024).

fg-learn — ③ 회고

실행 뒤 학습을 분류해 CONTEXT.md·ADR·회고 로그(.forge/retro)로 승급하고 다음 질의를 드러낸다. 네 번째 목적지로, 기계 확인 가능한 학습은 eval — 프로젝트 자신의 테스트 스위트에 남는 영속 회귀 체크(스위트가 없는 리포는 상응하는 실행 착지점) — 로 승급한다 (ADR 260906-171420). "forge learn", "회고하자", "이번 작업 정리해줘"에서 트리거된다. 항상 대화형이며 승급 절제를 지킨다.

fg-done — ④ 완료

한 바퀴의 잔여물을 정리한다 — 회고를 확인하고, STATUS.md를 done으로 마킹하고, 작업을 아카이브하고, 활성 .forge 상태를 비워 루프를 닫는다. "작업 완료", "봉인", "이거 마무리"에서 트리거된다(기존 "작업 정리"·"forge complete"도 alias로 인식; 단 "forge cleanup"은 이제 별개의 ADR 은퇴 스킬로 라우팅된다). 활성 상태를 비우는 것이 같은 plan의 재실행을 막는다.

기계적 봉인(사전점검·게이트 강제·STATUS.md 마감·아카이브·슬롯 비우기)은 결정론 스크립트 forge-done.sh/.js 가 한 번에 처리하고, 스킬은 그 exit code로 라우팅만 한다 — fg-status(ADR-0020)에 이어 스크립트 백킹된 스킬이다. 이 스크립트는 대화형 fg-done·fg-done all·fg-next all(위임) 세 봉인 경로가 공유하는 단일 봉인 프리미티브로, read-only인 fg-status와 달리 파일을 이동하므로 게이트-우선-비파괴(검증·회고 게이트를 통과하기 전엔 아무것도 안 건드리고 사유와 함께 refuse)이며 behavior+parity 테스트로 보호된다 (ADR-0030).

명시적 단일 /fg-done으로 봉인하면, 마감 직후 아카이브된 plan·run·STATUS·retro에서 "요구사항 + 처리 내용"을 재구성한 봉인 요약(요구사항 / 처리 내용 / 회고 파일이 있을 때만 회고 챕터 / 검증·문서·아카이브 메타)을 화면에 렌더한다(파일로 저장하지 않고, 봉인 스크립트도 안 건드리는 판단 계층 산문). 반대로 fg-done all·fg-next(원샷 — autochain이든 fg-done 직접 위임이든 · all)·fg-loop 같은 배치/무인 경로는 현행 간결 notice를 유지한다 — 흐름 유지가 목적이고 autochain 뒤엔 회고가 방금 끝나 요약이 중복되기 때문. 이 비대칭의 근거는 ADR-0032이다.

all 인자(fg-done all, "봉인 all"·"모두 봉인")는 봉인 전용 batch 모드다 — 이미 실행된 작업(활성 슬롯 + .forge/executed/ 전부)의 회고를 무조건 일괄 skip하고 각자 개별 done/으로 봉인한다. fg-next all의 봉인 전용 사촌으로, 백로그의 미실행 작업은 promote·run하지 않는다(그게 유일한 구분점). 검증 게이트(ADR-0009)는 불가침이라 verified: 봉인 가능값만 봉인하고 failed는 fg-run 수리로 라우팅하며, pending은 단일 경로와 같은 봉인 시점 UAT를 작업마다 반복한다. 봉인 직전 대상·제외 목록을 한 번 보여주고 go-ahead 하나를 받은 뒤 작업당 질문 없이 일괄 봉인한다. 회고 skip은 retro: skipped (fg-done all — …)로 감사 가능하게 남고 학습은 run.md에 보존된다 (ADR-0023).

루프 밖 유틸리티 (18개)

fg-map

fg-map은 루프 단계가 아니다 — 코드베이스가 크게 바뀌어 지도가 낡았을 때 돌리는 온디맨드 유틸리티로, "코드베이스 분석", "코드베이스 지도" 같은 발화에서 트리거된다. 지도가 이미 있으면 Update(스탬프 last_mapped_commit 기준 diff 증분 — 7문서를 제자리 편집하므로 비용이 코드베이스 크기가 아니라 변경량에 비례)가 상용 경로이고, 스탬프가 빠졌거나 HEAD의 조상이 아니면(리베이스·force-push) 되묻지 않고 전체 Refresh로 폴백한다(ADR 260801-020258).

fg-quick

fg-quick도 루프 밖이다 — 사소한 작업(오타·작은 rename·버전 범프)용 경량 차선으로, 그릴링은 하되 가볍게 하고 형식 산출물(ADR/plan/회고) 없이 바로 실행하며 .forge/quick/LOG.md에 한 줄 기록한다. 그릴링 중 비-trivial로 드러나면 fg-ask(정식 루프)로 bail한다. "forge quick", "quick task", "이거 빨리 해줘" 같은 발화에서 트리거된다.

fg-status

fg-status도 루프 밖 읽기 전용 리포터다 — 아무 때나 돌려 모든 작업의 현황(active slot·backlog·회고 대기·완료 이력·빠른 작업 로그)과 지금 필요한 다음 단계 하나를 본다; 아무것도 쓰지 않고 자동 실행도 하지 않는다. "forge status", "where am I", "어디까지 했지" 같은 발화에서 트리거된다.

fg-next

fg-next는 fg-status의 행동하는 형제로, 역시 루프 밖이다 — 같은 다음 단계 하나를 (fg-status의 상태 머신을 재사용해 — 재구현하지 않고) 도출하되, 한 줄로 알린 뒤 그 스킬을 곧바로 실행한다 — 보고만 하고 멈추지 않으며 별도 승인을 기다리지 않는다. one-shot(한 단계만, 이후는 호출된 스킬 자체 핸드오프가 이어받음)이며 자신은 아무것도 쓰지 않고 모든 행동을 해당 스킬에 위임한다 — 유일한 예외는 회고(fg-learn)가 재그릴링 권고 없이 정상 종료됐을 때로, 이땐 같은 호출에서 봉인(fg-done)까지 잇는다(ADR-0026). "어디까지 했는지 기억 안 날 때 그냥 다음 걸 해줘"라는 차가운 재진입 진입점이다. all 모드(fg-next all)에서는 백로그가 빌 때까지 작업을 하나씩 끝까지 몰며 진행한다 — 선형 기계적 단계는 자동 추천 진행하고 회고는 (divergence 무관) 항상 자동 skip하되, 대화의 벽(실패/검증불가 UAT·진짜 fork·빈 상태)에서는 멈춰 사람에게 넘긴다. fg-run의 "Run all"을 verify→done까지 확장한 모멘텀 상위집합이다 (ADR-0010). 무인 주행의 연속성은 턴 내 계속(위임 스킬의 진술형 정지를 턴 경계로 보지 않고 즉시 다음 단계 진행 — best-effort)과 /goal 폴백(주경로는 forge가 배포하는 Stop 훅 — 주행이 drive.md 마커를 쓰고 훅이 exit 2로 턴 종료를 막으므로 사용자 조작이 필요 없다, 상한 30분·50회; 훅이 살아 있지 않을 때만 /goal 붙여넣기를 제시하고 그마저 없으면 한 사이클 후 멈춤이 정상 — 재트리거로 재개)의 두 축으로 이뤄지며, 이 공유 규율은 skills/fg-next/DRIVE.md 한 벌에 정의돼 fg-loop과 공유된다 (ADR-0028). "forge next", "다음 단계", "이어서 해줘", "fg-next all", "다음 전부 진행" 같은 발화에서 트리거된다.

fg-loop

fg-loop all은 회고까지 남긴다. 기본 fg-loop는 검증을 통과한 작업마다 회고를 건너뛰고 봉인한다. /fg-loop all <목표>로 시작하면 loop.md에 retro: auto가 기록되고, 작업마다 봉인 직전에 그 작업의 plan·run·수리 기록만으로 회고 로그를 써서(<!-- auto-retro: fg-loop all --> 표시) 봉인한다. 재개할 때는 /fg-loop만 쳐도 같은 모드가 유지된다. 자동 회고는 CONTEXT·ADR 승급을 하지도 제안하지도 않으며, STATUS에 "자동, 승급 미검토"로 남아 fg-learn 일괄 승급의 후보가 된다(ADR 261010-230950).

재개는 차단 해제 승인이 아니다. loop.md에 wall:이 남아 있으면 fg-loop는 기존 승인과 관련 변경·증거를 먼저 확인한다. 아무것도 달라지지 않았다면 같은 검사를 다시 돌리거나 /goal을 반복 출력하지 않고, 필요한 결정 또는 증거를 안내한다. 이미 승인된 범위 변경은 계약에 기록하고 같은 턴에서 이어간다. 명시적인 재검사 요청은 진단만 허용할 뿐 수정 범위 확대나 검증 면제를 뜻하지 않으며, 실패 관측 횟수와 실제 수정 시도도 따로 기록한다.

fg-loop는 goal 주도의 세 번째 차선으로, 역시 루프 밖이다 — 기초 질의(대화)로 기계 검증 가능한 정지 조건(에이전트가 실행 가능한 체크 — "AI가 만족되었다고 생각함"은 인정 안 됨), 승인된 fix-forward 재계획 범위, 재계획 상한(기본 3라운드)을 .forge/loop.md에 못 박고 초기 백로그 plan을 적재한 뒤, 체크가 전부 통과할 때까지 작업 루프 전체(run → UAT → 회고 항상 자동 skip → 봉인, fg-next all의 기계를 참조로 재사용)를 주행한다. active slot이 비어 있는 stop-check 실패는 generated-by: fg-loop 정상 PLAN-FORMAT plan으로 만들고, verified: failed는 별도 backlog plan을 만들지 않고 cap·scope·safety를 먼저 확인한 뒤 같은 active task를 repaired-by: fg-loop marker와 함께 제자리 수리해 fg-run의 failed 분기로 재실행한다. 이 구분이 활성 슬롯 1개 계약을 지키면서 verified: failed를 자동 fix-forward 케이스로 유지한다. 벽 — 검증 불가 UAT·진짜 fork(범위 밖 수정 포함)·상한 소진·같은 체크 2연속 무진전·tension(fix-forward가 이미 통과한 체크를 깨뜨리는 regression 핑퐁)·safety(승인 범위 안이라도 비가역 액션 클래스)·stalled-waiting(대기가 ×2 증거 불변으로 정체)·blocked-health(체크 명령이 실행조차 불가 — 도구·인증 부재)·budget-exhausted(선언한 토큰 천장 도달, 또는 사전 예측상 남은 예산이 태스크당 관측 평균 미달) — 에서는 멈춰 사람에게 넘기고, goal 충족 시 요약을 보고하고 loop.md를 삭제한다. 기둥 1의 의도적·경계 있는 완화다 (ADR-0016); 회고 학습은 아카이브된 run.md에 남아 추후 사람이 fg-learn으로 일괄 승급한다. loop.md는 체크별 진행 원장(## Check progress — 결과·×N 연속 무진전·regressed: ×N(pass→fail 회귀 횟수)·last-evidence·시도 slug·reflection)과 wall: 필드를 영속화한다: Reflexion(실패를 언어화해 다음 fix-forward에 주입 — fg-loop은 stateless 재개라 영속 필수)으로 다음 fix-forward가 같은 접근을 반복하지 않고 다르게 시도하게 만들고, no-progress 벽은 in-session 기억이 아닌 원장의 ×N≥2로 판정하며, fg-status는 이 필드들을 읽어 왜 멈췄는지(맨 "재개"가 아니라) 보고한다(ADR-0016 2026-06-18 개정 2건). reflection은 드라이브 내 휘발 작업기억이지 회고가 아니다. 체크는 evidence: external을 선언할 수 있고(기본 off), 선언된 체크가 통과 아니면 무조건 waiting — 실패가 아니고 벽도 아니어서 replan-round를 안 쓰고 fix-forward도 만들지 않으며, 사람에게 아무것도 요구하지 않은 채 턴만 끝낸다(증거 도착 후 재트리거로 재개). 판정을 선언만으로 한정한 대가로 "빨간 CI"와 "미완 CI"를 구분할 수 없어 선언된 외부 체크는 자동 수리에서 제외되고, 그래서 연속 waiting ×2+증거 불변에서 stalled-waiting 벽으로 승격하는 상한이 영구 대기를 막는 유일한 안전장치다. 주행 첫 체크 실행 전에는 각 체크 명령의 실행 파일을 도출해 존재를 확인하고(부재 시 blocked-health 벽), 파이프 뒤 도구·미인증처럼 사전 도출이 못 잡는 경우만 보수적으로 사후 승격한다(애매하면 평범한 실패 — 실패를 환경 문제로 오분류하면 진짜 버그를 숨기므로 비대칭). waiting ×N은 신규 필드가 아니라 기존 원장에, evidence: external은 기존 체크 절에 흡수해 소비자 ripple을 피했다(LoopX 개념 각색 — quota·스케줄링은 forge에 다중 goal 경쟁이 없어 미도입, ADR-0016 개정 2026-08-09). 지출 상한만은 예외적으로 최상위 필드 2개(budget-tokens·budget-spent · since:)다 — 지출은 어느 체크에도 속하지 않는 drive 수준 값이라 원장에 집이 없고, 구조적 쌍둥이가 replan-round/replan-cap이기 때문이다. 결정론 트윈 forge-loop-spend.sh/.js가 세션과 subagents/ 트랜스크립트의 원시 토큰 4필드를 since: 이후 델타로 합산해 경계마다 1회 호출해 초과(exit 3)·사전 예측(exit 4)·측정 불가(exit 5)를 한 번에 판정하고 exit code로 넘긴다(2회 호출은 첫 호출이 since:를 전진시켜 같은 구간을 다시 세는 버그였다). 천장이 선언됐는데 측정이 불가능하면(트랜스크립트 루트 부재·since:가 타임스탬프 아님·상한값 파싱 불가) spent=0으로 조용히 넘어가지 않고 blocked-health 벽으로 멈춘다 — "아직 안 썼다"와 "측정 불가"를 구분하지 못하는 것이 천장을 무증상으로 무효화하던 원인이었다. 캐시읽기를 세는 것이 핵심이다 — 매 iteration 재전송되는 컨텍스트가 바로 그것이고, replan-cap은 라운드만 묶어 그 팽창을 못 본다. 다만 이 숫자의 정체는 **"루프가 살아 있는 동안 이 프로젝트가 태운 토큰 처리량"**이고 이 드라이브의 청구액이 아니다 — 안전 한계이지 회계 장부가 아니며, 과대 계상이 안전한 오차다(ADR-0016 개정 2026-08-20). 상한은 §1의 기존 cap 질문에 흡수해 물으며(none도 정당한 답이고 그때는 전부 우회) 기본값은 발명하지 않는다(실측 축적 후 별건). replan-round 미소비·fix-forward 미생성이고, 해제는 사람이 budget-tokens를 올리는 것뿐이다(budget-spent는 리셋 안 함). fg-next all 비적용은 다른 벽들과 달리 구조적 불가능이 아니라 범위 결정이다 — 그쪽도 무인 주행이지만 천장을 담을 계약 파일이 없다(ADR-0016 개정 2026-08-19, GitHub 이슈 #12). "forge loop", "루프 시작", "조건 충족까지 반복" 같은 발화에서 트리거된다.

무인 주행의 태스크당 커밋(옵트인). fg-next all과 fg-loop은 .forge/config.json의 driveCommit(엄격 불리언·기본 false)이 켜져 있으면 태스크를 봉인할 때마다 그 태스크의 변경을 로컬 커밋해 태스크 단위 롤백 지점을 남긴다 — 여러 태스크가 사람 없이 봉인되면 어디로 되돌릴지가 사라지기 때문이다. 커밋만 하고 push는 하지 않는다(롤백은 로컬 커밋에서 완결되고 push는 되돌림 가능성만 뺀다). 스테이징을 추론하지 않는 것이 핵심이다 — 주행 진입 시 git status --porcelain이 비어 있어야 커밋하고(그때 git add -A가 곧 "이 태스크가 바꾼 것 전부"다), 비어 있지 않으면 그 주행은 커밋 없이 진행하며 한 줄로 알린다. 커밋할 것이 없으면 정상으로 보고 조용히 계속하고, 거부되면(pre-commit 훅·detached HEAD·머지 중) 기존 fork (commit rejected — <사유>) 벽으로 멈춘다 — 열 번째 벽을 만들지 않는다. 메시지 기본값은 {title} (forge task #{task} · {slug})이고 driveCommitMessage 템플릿으로 바꿀 수 있다(치환자는 {title}·{slug}·{task} 셋뿐, 미지 치환자는 기본 형식으로 폴백+경고). 단일 정의는 skills/fg-next/DRIVE.md Part 3, 근거는 ADR 260901-213128.

fg-config

fg-config도 루프 밖이다 — .forge/config.json 여섯 키(simple·eco·tdd·driveCommit·driveCommitMessage·defaultBranch)의 단일 진입점(fg-config 무인자 = 전체 설정 표+변경 메뉴 · fg-config <key> = 한 키 · fg-config <key> <값> = 설정). 옛 키별 토글 스킬을 대체하며 "eco on"·"TDD 켜" 같은 옛 트리거도 흡수한다(ADR 260905-212045).

simple — 자동 봉인 모드(신설, ADR 260905-212045). simple: true면 fg-run이 UAT(검증) 후 회고를 무조건 skip하고 같은 턴에 봉인까지 잇는다(검증 게이트는 불가침). 흐름 비교표·다이어그램·켜고 끄는 기준은 설정 모드 가이드를 보라.

tdd — test-first 기본(ADR-0008, 의미론 불변). fg-ask가 작업마다 이 설정을 기본 답으로 "이 작업 TDD로?"를 묻고, plan의 tdd marker가 켜져 있으면 fg-run이 test-first로 실행한다.

eco — eco 모드(의미론 불변). binary on/off이며, 켜지면 "forge 루프에서 낭비하지 않는다"는 한 원칙의 세 효율 동작이 활성화된다 (ADR-0014 (eco subagent model tiering) 개정, ADR 260730-230321).

1. 모델 캡 (비용 절약). fg-run이 위임 Dynamic Workflow 서브에이전트를 sonnet으로 캡한다 — 내리기만 하고(티어를 올리지 않음, 이미 sonnet 이하면 상속 그대로), 사용자의 명시적 모델 지시가 우선하며, 메인 세션 모델은 건드리지 않는다. 스킬은 세션 모델을 바꿀 수 없으므로(그래서 자동 단계별 모델 전환은 불가능 — ADR-0014의 전제) 설계(fg-ask)·완료(fg-done)는 사용자가 고른 모델 그대로이고, 결과는 강력=메인 세션 · 일반=위임 실행의 2단 티어다. fg-map은 의도적으로 범위 밖이다(지도 품질=그릴링 연료라 절감 폭 대비 리스크가 크다).
2. Eco laziness-first 규율 (코드·계획 복잡도 절약). 임베드된 절제 규율(skills/fg-config/ECO.md — "가장 좋은 코드는 쓰지 않은 코드")이 세 곳에 적용된다: (a) fg-run 각 위임 서브에이전트 프롬프트에 6단 사다리(YAGNI → stdlib → 네이티브 → 기존 의존성 → 한 줄 → 최소 코드)와 핵심 제약이 prepend되고, (b) fg-ask 그릴링에 조용한 YAGNI 렌즈("이게 꼭 필요한가? 최소 버전은? 기존 메커니즘이 커버하나?")로 녹아들며, (c) 현 세션도 eco: true를 관측할 때마다 그 규율을 채택한다 — 토글뿐 아니라 no-arg가 on 유지·fg-run 직접 실행·fg-ask 핸드오프 등 main-session eco-read에서 발동하는 상태 기반(모델은 여전히 불변; 단 어떤 스킬도 안 돈 새 세션 첫 시점은 세션 시작 훅이 없어 자가 채택 불가 — 처음 eco를 읽는 스킬이 집어감). 신뢰 경계 검증·데이터 손실 방지·보안·접근성·명시 요청은 절대 단순화하지 않으며, 비-trivial 로직은 runnable check 하나를 남긴다. 이 규율은 독립 스킬이 아니라 eco의 일부이고(별도 토글 없음), DietrichGebert의 Ponytail에서 차용·각색했다(크레딧은 README). 여기에 더해 ECO.md는 출력 prose 압축(실행·보고 prose 간결화 — 코드/명령/에러는 verbatim, 그릴링 질문·생성 문서·명시 요청 설명은 압축 제외; JuliusBrussee의 caveman 차용)도 담아 소통 토큰을 아낀다(ADR-0014 2차 개정).
3. eco 요약 표 (읽는 부담 절약). 작업이 끝나는 지점 — fg-run 단일작업 핸드오프·fg-done 명시적 단일 봉인·배치/무인 경로(Run all·fg-done all·fg-next 위임 봉인·fg-next all·fg-loop) — 의 산문 핸드오프를 교체한다(추가가 아니라 교체 — 덧붙이면 글이 더 늘어 목적에 반한다): 헤더 한 줄(제목·#task·verified·divergence) + ▸ 요청(plan Goal 한 줄) + ▸ 수행(슬라이스 표: #·슬라이스·결과·계획 대비) + ▸ 다음(다음 단계·트리거 한 줄). 배치 경로는 작업당 1행 표다. 2번의 압축이 스타일 지시라 지킴 여부가 보이지 않아 실제로 부족했다는 실증에서 나온 형태 규율이며, 표의 재료를 보장하기 위해 fg-run이 run.md에 슬라이스별 한 줄 결과를 항상 기록한다(eco 무관 — 나중 세션에서 봉인해도 표가 성립하도록). 검증 상태(verified:)는 봉인 가능 여부를 판단하는 정보라 헤더에서 절대 빠지지 않는다(ADR-0009). 실행 중 narration은 그대로 두어 어디서 막혔는지 보이고, 그릴링·회고·생성 문서(plan/run/retro/CONTEXT/ADR)·fg-quick은 제외이며, eco: false면 종전 산문 그대로다. 형태 정의는 ECO.md 한 곳에만 있고 fg-run·fg-done·DRIVE.md는 참조만 한다 (ADR 260730-230321, GitHub 이슈 #7).

driveCommit/driveCommitMessage·defaultBranch — 무인 주행의 태스크당 로컬 커밋과 그 메시지 템플릿(위 fg-loop 절 참조, ADR 260901-213128), 그리고 forge 루트 해석의 기본 브랜치(ADR-0011).

"forge config", "설정", "simple 모드", "eco on/off", "에코 모드", "tdd 켜/꺼" 같은 발화에서 트리거된다.

fg-merge

fg-merge는 브랜치 격리의 통합 유틸리티로, 역시 루프 밖이다 — 피처 브랜치를 git merge한 뒤, 그 브랜치의 .forge/branch/<branch>/를 기본 브랜치의 .forge/로 합친다. 기계 통합은 **결정론 스크립트(forge-merge.sh/.js, dual dispatch)**가 수행한다: 브랜치의 시간기반 ADR을 그대로 옮기고(정확 ID 충돌 시 다음 빈 글자로 국소 해소 — cascade 재번호 없음, 교차참조 안 깨짐), incoming done/+backlog/ plan의 task: 번호만 target과 안 겹치게 한 map으로 재부여한 뒤 CONTEXT·retro·done·backlog를 합치고 브랜치 폴더를 제거한다. 스크립트라 AI 없이 CI 게이트로도 쓸 수 있고(구조 충돌 시 nonzero exit), 진짜 충돌에서만 멈춰 사람에게 묻는다 — 용어 재정의(용어는 **이름**: 항목이고 ## X는 그룹 소제목이라, 두 글로서리가 ## Language를 공유하는 것은 충돌이 아니다)·incoming NNNN 충돌·미인식 CONTEXT 형식(## 헤딩만 있고 **용어**:가 0개면 용어 단위 병합이 조용히 아무것도 안 하므로, no-op 병합보다 정지가 안전하다) — 의미 ADR 모순은 스크립트 범위 밖으로 PR 리뷰가 담당한다. 코어 스크립트는 git을 직접 돌리지 않아 CI에서 AI 없이 쓸 수 있고, 대화형 편의로 fg-merge <branch>는 git merge를 먼저 대신 돌려준다(스킬 계층 한정·기본 브랜치·충돌 시 그자리 정지 — ADR 260717-10a). 반대 방향의 세 번째 모드 fg-merge to main은 작업을 끝낸 feature 브랜치에서 실행해 작업 커밋 → 기본 브랜치 checkout → git merge → 통합 → 통합 커밋을 한 번에 잇는다. 1단계 전에 스크립트의 --gate-only(진행 중 작업 게이트만 판정하고 아무것도 옮기지 않음)로 미완 forge 작업을 먼저 막고, 확인은 커밋 직전 1회만 받으며, 유일하게 커밋하는 모드지만 push와 브랜치 삭제는 하지 않는다(ADR 261006-102435). "forge merge", "fg-merge <branch>", "fg-merge to main", "브랜치 통합" 같은 발화에서 트리거된다 (ADR-0011). 팀에서의 merge 의식·충돌 권한·CI 게이트 사용법은 team-workflow.md를 참조한다.

fg-cleanup

fg-cleanup은 ADR 은퇴 유틸리티로, 역시 루프 밖이다 — 오래된/대체된 ADR을 활성 결정 집합에서 은퇴시킨다: 은퇴 후보를 근거와 함께 제시하고, 사람이 승인하면 각 ADR을 .forge/adr/retired/<NNNN>-slug.md로 옮기며 Superseded by ADR-NNNN / Retired (사유) 한 줄을 단다. 번호는 절대 바뀌지 않고 재사용도 없으며, 아무것도 삭제하지 않는다(왜는 디스크에 남는다). fg-ask는 retired/를 정답소스로 읽지 않아 은퇴된 결정이 그릴링 연료에서 빠진다. 은퇴는 사람 승인이 원칙이고 자동이 아니며, 작업 봉인은 이 스킬이 아니라 fg-done이다. "forge cleanup", "ADR 정리", "ADR 은퇴", "오래된 ADR 치워" 같은 발화에서 트리거된다 (ADR-0012).

fg-statusline

Claude Code 전용 UI 유틸리티다. Codex에서는 설정을 수정하지 않고 $fg-status를 안내한다.

fg-statusline은 일회성 설정 유틸리티로, 역시 루프 밖이다 — 터미널 statusline에 forge 루프의 현재 위치를 두 설치 모드 중 하나로 띄운다(ADR-0029). 두 모드는 forge 진행 줄을 위해 같은 얇은 fragment를 공유하고, 그 외에 무엇을 더 보여주고 누가 명령을 소유하느냐가 다르다.

• 방법 1 (append/wrap) — 얇은 forge 전용 fragment(scripts/forge-statusline.sh/.js)를 안정 경로에 설치해, .forge/를 읽어 의미 단위 그룹 대괄호 [...]로 최대 2줄을 출력한다 — 1번째 줄은 [🔁 rN/cap] goal 루프 지표(있을 때)에 이어 [⚒ #N slug · 색상 ✔ ask → ● run → ○ learn → ○ done · flag] forge 그룹(현재 단계만 강조·done은 장식용·verified flag는 파이프라인 끝), 2번째 줄은 [📋 N queued · 📝 M awaiting retro · ✗ K failed · ♻️ · 🧪] 큐+모드 그룹(📝는 회고 가능한 park만 세고 verified: failed park은 ✗로 따로 센다 — 회고도 봉인도 막힌 상태라 fg-run 회수가 필요하므로, 세션 시작 훅과 같은 분리다. 🧪=plan <!-- tdd: on -->·♻️=최상위 config eco: true — 실활동에서만 점등, idle 제외)이고, idle이면 아무것도 안 띄운다. 구분자는 기본 ·(FORGE_SL_SEP)·무색이라 방법 1의 append 성격은 그대로다. Claude Code는 statusLine을 하나만 허용하므로 기존 명령을 자동 래핑해 forge를 아래 별도 줄로 덧붙인다(원본 보존). 시스템 정보는 일절 안 그리는 얇은 판독자다(ADR-0017; 그룹 대괄호·이모지 지시자만 ADR-0029 개정으로 반영).
• 방법 2 (merge) — forge 소유 통합 스크립트(scripts/forge-statusline-full.sh/.js 트윈)가 daleseo식 시스템 정보와 forge 진행을 그룹 대괄호로 한 스크립트에 출력한다. full(4줄): [모델|추론강도] [디렉터리|⎇git(↑N ↓N +!?)] [⏱|$비용|±라인] / [동적이모지 Context/크기 그라디언트바 N% | 5h … | 7d …] / forge 그룹 / 큐+모드 그룹. compact(2줄): 시스템+바 한 줄 + forge 단일 그룹(세션 그룹 제외). 밀도는 command 위치 인자(compact/full, 기본 full)로 저장하며 새 config 키가 없다. 구분자는 |(fragment엔 FORGE_SL_SEP=| 위임), 색·그라디언트는 라이브 튜닝. forge 부분은 fragment에 위임해 단계 로직을 재사용하고(3중 복제 금지·parity 테스트), forge idle이면 forge 그룹만 사라지고 시스템 줄은 유지된다.

설치 결정: 기존 statusline 있으면 1/2 선택, 없으면 2 자동, Windows+기존이면 2만(방법 1 wrapper가 bash 전용). 방법 2가 기존을 교체할 땐 원본을 보존하고 복원법을 안내한다. 모드는 wired command 경로로, 밀도는 그 command의 위치 인자로 감지한다(둘 다 새 config 키 없음 — 방법 2 설치 시 밀도를 1회 묻고 인자로 박으며, refresh는 기존 밀도를 보존한다). 어느 모드든 다음 단계의 정답소스는 여전히 fg-status이며, forge 업데이트 후 스크립트 갱신은 다시 실행하면 된다. "forge statusline", "상태바", "statusline 설정" 같은 발화에서 트리거된다 (ADR-0017 · ADR-0029).

fg-adversarial-review

fg-adversarial-review는 선택적 리뷰 유틸리티로, 역시 루프 밖이다 — fg-run과 fg-learn 사이에서 봉인 전 의도적으로 적대적인 두 번째 검토를 돌린다. 검토자는 공격자·반대자 입장을 취해 "이 결과가 틀렸다고 가정하고 증거를 찾자"에서 출발하며, 6개 렌즈 — 실패 지점·숨은 가정·요구사항 오해·보안/성능/데이터 손실·예상 못한 오용·약하거나 미검증된 근거 — 를 Dynamic Workflow의 서브에이전트로 병렬 팬아웃한다(실행 중 사람 입력이 필요 없어 기둥 1에 걸리지 않는다). findings는 .forge/review.md에 기록되고, 핸드오프에서 사람이 각 건을 판단한다 — 코드 결함은 (승인 후) fix-forward backlog plan(generated-by: fg-adversarial-review)이 되지만 원 작업이 active slot을 점유하므로 원 작업을 먼저 fg-learn→fg-done으로 봉인한 뒤 fg-run이 fix plan을 집어간다. 설계·요구사항 결함은 fg-ask 재그릴링으로 돌아가며, 수용된 findings는 회고로 들어간다. 순수 선택이고 봉인 게이트가 아니며(게이트는 verified:와 회고뿐), fg-next all·fg-loop는 findings 판단이 사람 몫이라 항상 skip한다. "adversarial review", "적대적 리뷰", "허점 찾아줘" 같은 발화에서 트리거된다 (ADR-0018).

fg-doctor

fg-doctor는 읽기 전용 무결성 health check로, 역시 루프 밖이다 — harness engineering의 init.sh health check를 forge에 적용한 것이다. fg-status가 어디까지 했나를 보고한다면, fg-doctor는 상태가 건강한가를 보고한다: .forge/ 상태 계약(고아 run.md·STATUS 필드 손상·plan↔STATUS↔retro slug 페어링 불일치·half-sealed done/·backlog 마커와 task 번호 유일성)과 영속 문서/매니페스트(버전 4곳 동기·JSON 유효성·스킬 name frontmatter·스킬 개수 정합·CLAUDE.md 스킬 목록 완전성·README 이중언어 동기·ADR 번호/상호참조)를 검사해 각 위반을 error/warning/info로 분류하고 항목별 actionable 수정 안내를 출력한다. 아무것도 쓰지 않고 자동 수정도 하지 않는다 — 수정은 사람이 fg-quick(사소) 또는 fg-ask(비사소)로 하며, 다른 스킬이 자동 호출하지 않는다. "forge doctor", "무결성 검사", "상태 점검", "forge 진단", "health check", "정합성 확인", "check forge state" 같은 발화에서 트리거된다 (ADR-0019).

fg-help

fg-help는 읽기 전용 사용법 리포터로, 역시 루프 밖이다 — forge의 세 번째 읽기 전용 질문에 답한다: fg-status가 어디까지 했나(진행+다음 단계), fg-doctor가 상태가 건강한가(무결성)를 보고한다면, fg-help는 이 스킬들을 어떻게 쓰나(사용법)를 보고한다. /forge:fg-help(무인자)는 forge fg-* 스킬 전체를 루프 4단계(fg-ask → fg-run → fg-learn → fg-done) + 루프 밖 유틸리티로 그룹핑한 개요를, /forge:fg-help <명령>은 개별 스킬의 4줄 상세(무엇 · 언제 · 트리거 · 다음 단계)를 출력한다. 사용법의 단일 소스는 플러그인 skills/*/SKILL.md의 frontmatter description이다(Glob의 path 인자를 이 스킬의 상위 디렉터리로 고정해 읽는다 — ${...} 패턴이나 ../ 패턴은 Glob이 각각 리터럴 매치·cwd 기준 해석으로 0건을 조용히 돌려준다) — 사본을 두지 않으므로(다섯 번째 동기 표면을 안 만듦) 새 스킬은 fg-help 편집 없이 자동으로 나타난다. glob 대상은 forge 스킬뿐(다른 플러그인 스킬은 제외 — forge가 그 설명 품질을 보장할 수 없다). 결정론 스크립트 트윈이 없다 — 핵심 일이 영문 소스 description을 사용자 언어로 렌더하는 것이고 스크립트는 번역을 못 하기 때문이다(이 점이 스크립트-백킹된 fg-status/fg-doctor와 다르다). fg-status가 길 잃은 사용자에게 여기를 교차 참조한다("사용법은 /forge:fg-help"). 아무것도 쓰지 않고 자동 실행하지 않으며, fg-cleanup·fg-drop처럼 핸드오프 표를 내지 않고 산문을 유지한다. "forge help", "fg-help", "도움말", "사용법", "how do I use forge" 같은 발화에서 트리거된다 (ADR 260814-104534).

fg-drop

fg-drop은 폐기 유틸리티로, 역시 루프 밖이다 — 더 이상 원하지 않는 미완(미봉인) 작업을 지운다: backlog plan·활성 슬롯·executed/의 회고 대기 작업·멈춘 goal loop.md가 대상이다(봉인된 done/은 대상 아님 — 그건 fg-done의 영역). 먼저 미완 항목을 항목별 위험도와 함께 제시한다(1개면 drop/cancel 2지, 2–4개면 체크박스, 5개 이상이면 번호 텍스트 목록). 별도 후속 질문으로 하드 삭제(기본·흔적 없음)와 .forge/dropped/<slug>/ 보관 중 하나를 고르게 한다. 불가역 삭제 전 확인 게이트가 한 번 더 막고, 이미 실행된 작업의 바뀐 코드는 되돌리지 않음을 경고한다 — fg-drop은 forge 상태만 지우고 git·코드는 건드리지 않는다. 멈춘 goal 루프는 통째로만 drop하며 멤버 task를 개별 제외하지 않는다(loop.md 멤버십 재동기화 로직을 만들지 않기 위함). .forge/dropped/는 휘발(gitignore)이라 fg-doctor는 관용하고 fg-status는 무시한다. "forge drop", "fg-drop", "작업 버리기", "이 작업 취소", "계획 지워", "백로그 비워", "drop task", "discard plan" 같은 발화에서 트리거된다 (ADR-0021).

fg-agents

현재 생성 결과는 Claude Code의 .claude/agents/<role>.md다. Codex 네이티브 프로젝트 역할 materialize는 아직 지원하지 않는다.

fg-agents는 생성 유틸리티로, 역시 루프 밖이다 — 프로젝트의 도메인 에이전트를 만든다. 대화형 그릴링(기둥 1, 워크플로 밖)으로 프로젝트에서 반복되는·분리 가능한 작업 종류를 캐내 역할을 도출하고, 표준 Claude Code 서브에이전트 정의 .claude/agents/<role>.md(role 카드)를 자체 생성한다. 카드의 description에는 "언제 쓰이나"를 반드시 담는다 — fg-run의 워크플로 빌더가 이 설명으로 plan의 work slice를 role에 자동 매핑하기 때문이다(ADR-0024는 plan 쪽 매핑 마커 대신 자동 매핑을 택했다). .forge/codebase/ 지도·CONTEXT.md·**활성 .forge/adr/**가 있으면 그릴링 연료로 읽고, 없으면 직접 탐색하거나 사용자 설명만으로 진행한다(graceful·하드 의존 없음). ADR은 프로젝트의 문서화된 결정이므로, 관련 결정을 카드 system prompt에 가볍게 반영해(번호를 기계적으로 인용하지 않고 prose로) 카드가 generic하지 않고 프로젝트에 정합하게 한다 — retired/는 안 읽고(ADR-0012), 비기본 브랜치는 read-overlay(ADR-0011)로 fg-ask의 ADR 읽기 규율과 동일하다. 역할은 사람이 승인한 부분집합만 카드가 되며, 마땅한 seam이 없으면 0개도 정직한 결과다(역할을 억지로 만들지 않음 — fg-cleanup의 절제와 동형). 핵심 제약(ADR-0024): .claude/agents/는 세션 시작 시 1회 로드되므로 세션 중 만든 카드는 동적 픽업되지 않는다 — fg-agents가 생성한 카드는 세션을 재시작해야 fg-run이 로드·agentType 호출한다. 운영 흐름은 생성 → 재시작 → 활용이며, 재시작은 프로젝트 셋업 시 1회뿐이다. 생성한 카드는 forge .forge/ 상태가 아니라 프로젝트 자산이라 git으로 커밋한다(git은 직접 안 돌림). 루프 스킬이 fg-agents를 안내한다: fg-ask(그릴링 중)·fg-run(실행 중)은 특화 역할이 반복적으로 도움될 것으로 판단되고 프로젝트에 맞는 카드가 없을 때 fg-agents를 좁게·offered로 한 번 안내한다(자동 호출 아님, 재시작 게이트 명시) — fg-agents의 "역할은 제 몫을 해야 한다" 절제와 동형. "forge agents", "도메인 에이전트 만들어", "에이전트 팀 구성", "create project agents", "domain agents", "agent roles" 같은 발화에서 트리거된다 (ADR-0024).

fg-showme

fg-showme은 시각 컴패니언 유틸리티로, 역시 루프 밖이다 — obra/superpowers v6.1.1의 Visual Companion을 MIT 귀속과 함께 vendoring했고, v6.3.0까지 다시 대조해 엔진 다섯 파일이 forge 자체 수정분(브랜딩·텔레메트리 제거, 경로)을 빼면 동일함을 확인했다(업스트림 v6.2.0·v6.3.0에 visual companion 변경이 없다). 이름은 매체(visual)가 아니라 사용자 쪽 행위(show me)를 따른다 — 개명 근거와 기각한 대안은 ADR 260831-140943. zero-dependency Node 서버(scripts/server.cjs 등 5파일)가 에이전트가 push하는 HTML(목업·다이어그램·A/B 시각 비교)을 브라우저 탭에 실시간 표시하고, 사용자의 클릭·텍스트 입력을 이벤트(JSONL)로 받아 에이전트가 되읽는다. 브라우저는 표시 전용이 아니라 보조 답변 채널이다 — 선택형 질문에서 클릭이 답으로 성립하고 화면에 텍스트 입력칸을 둘 수 있으며, 두 채널의 답은 병합해 읽고 모순될 때만 한 줄로 되묻는다. 선택형 화면에는 필수 확정 버튼을 두어, 호스트가 event_wake를 지원하면 확정 클릭이 터미널 턴 없이 대화를 재개하고, 미지원 호스트에서는 확정 뒤 터미널 입력 한 번이 필요하다(탐색 클릭은 깨우지 않는다), 기둥 1은 근거를 옮겨 온전하다 — 재개가 터미널 턴이라서가 아니라 브라우저가 Dynamic Workflow의 런타임 입력이 아니라서다(ADR 260730-224259·260805-005436). 세션 파일은 모든 브랜치에서 최상위 .forge/showme/<세션>/(휘발)에 둔다 — .forge/config.json·.forge/codebase/와 같은 전역 예외로, 브랜치 루트로 이동하지 않는다. git 진입 경로는 구조적으로 없다: start-server.sh가 자체-ignore .forge/showme/.gitignore(* 한 줄)를 써 주고(사용자의 루트 .gitignore는 편집하지 않는다), 종료 시 세션 폴더가 삭제되며 마지막 세션이면 .forge/showme/가 통째로 사라지고, 크래시나 유휴 타임아웃이 남긴 죽은 세션은 다음 시작 때 sweep된다(ADR 260719-224442 개정 2026-09-02). 세션 키 URL 인증·서버 재시작/브라우저 재연결 생존·4시간 유휴 자동 종료를 갖추며, 텔레메트리·원격 자원은 없다. fg-ask 통합: fg-ask는 그릴링 시작 전에 이 작업이 시각적 표면을 건드리는지, 또는 설명하게 될 만큼 구조가 있는지 한 번 판단해 두고(판단 시점), 시각적 질문 또는 설명이 처음 실제로 도착할 때 just-in-time으로 1회만 제안한다(제안 시점 — 단독 메시지, 거절 시 재제안 없음). 제안은 질문에만 걸리지 않는다 — 분기 있는 흐름·상태 전이·다축 비교처럼 구조가 있는 것을 설명하게 될 때도 제안하며, 경계는 텍스트 흐름도다: A → B → C로 감당되면 터미널에 쓴다. 판단과 제안을 분리한 이유는 둘을 합쳐 두면 제안이 아예 발동하지 않았기 때문이다. 수락하면 fg-ask가 ../fg-showme/VISUAL.md와 scripts/를 파일 참조로 직접 사용하고(ECO.md·FORGE-ROOT.md와 같은 단일 정의 관례 — 복붙 금지), Output(핸드오프) 시 서버를 종료한다. 프레임 테마는 리포 루트 DESIGN.md(Anthropic/Claude 디자인 시스템 — 크림 캔버스 #faf9f5 + 코랄 #cc785c + editorial serif 디스플레이)에서 왔다. 디자인은 scripts/frame-template.html의 CSS 변수 25개에만 살고 화면 콘텐츠는 그 클래스를 쓰므로, 에이전트가 미는 모든 화면이 테마를 자동으로 상속한다. 라이트 테마는 claude.com 실물 값을 충실히 옮긴 결과라 여섯 쌍이 WCAG AA 아래이며(가장 낮은 것은 흰 글자 on 코랄 3.28:1), 이는 브랜드 충실도를 택한 기록된 결정이라 파일 주석이 그 목록을 담는다 — 다크 테마는 전부 통과한다(최저 5.47:1). 서버가 네트워크를 쓰지 않으므로 웹폰트를 부르지 않고 디스플레이는 시스템 serif 스택으로 근사한다. vendored 파일은 업스트림 형태를 유지하되 바이트 동일은 아니다 — 브랜딩·테마 조정이 각 파일 헤더에 기록돼 있다(ADR 260719-224442 §1). 이 스킬 자체는 단독 진입점이다 — fg-showme로 시작, fg-showme stop으로 종료. "forge visual", "visual companion", "시각적으로 보여줘", "목업 보여줘", "브라우저로 보여줘", "화면으로 비교해줘" 같은 발화에서 트리거된다 (ADR 260719-224442).

fg-agenda

fg-agenda는 결정 대기열로, 역시 루프 밖이다 — forge에 아직 내리지 않은 결정이 사는 자리를 준다. forge의 산출물은 전부 빌드 산출물이고(plan.md의 Work slices) ADR은 이미 내려진 결정을 기록하므로, 안개 속의 큰 작업은 억지로 완결된 계획이 되거나 결정이 대화·회고 산문에 흩어져 사라진다. fg-agenda는 그 구멍을 .forge/agenda.md 한 파일로 메운다 — 목적지·결정된 것·열린 질문·아직 또렷하지 않은 것(fog)·범위 밖의 5개 절이며, 활성 의제는 1개(활성 슬롯 1개 규율과 같은 모양)이고 위치는 해석된 forge 루트(브랜치별 — loop.md와 같은 취급, 전역 예외 아님)다. 열린 질문이 0이 되면 agenda.md를 삭제한다(fg-loop가 goal 충족 시 loop.md를 삭제하는 선례) — 영속 흔적은 의제가 낳은 ADR과 백로그 plan이라 아카이브를 새로 만들지 않는다.

자율성의 경계가 이 스킬의 정체다: 에이전트는 무엇을 결정해야 하는지 찾아내고, 답은 전부 사람이 한다. 에이전트 몫은 breadth-first 그릴링으로 열린 결정을 캐내기·fog와 질문 구분(테스트는 지금 질문을 정확히 진술할 수 있나이지 답할 수 있나가 아니다)·"지금 답 가능한 것을 위로" 순서 세우기·다음 질문 고르기·fog 승격과 범위 밖 판정이고, 사람 몫은 목적지 정하기와 모든 답이다. 에이전트는 자기 질문에 스스로 답하지 않는다 — 그러면 의제의 "결정된 것"은 결정이 아니라 에이전트의 추측이 되고 기둥 1이 깨진다. 두 모드는 agenda.md 존재 여부로 갈린다: open(의제 없음)은 목적지를 사람과 먼저 정하고 breadth-first로 그릴링해 의제를 쓴 뒤 멈춘다 — 아무 질문도 해소하지 않으며, 안개가 전혀 안 나오면 의제를 만들지 않고 fg-ask를 가리킨다. work(의제 있음)은 질문 하나를 골라(사용자 지목이 없으면 열린 질문의 첫 줄 = frontier) fg-ask의 그릴링 방법으로 해소하고, 답을 ## 결정된 것 한 줄로 적고 세 조건을 넘으면 ADR도 쓰며, 새 질문 추가·또렷해진 fog 승격·범위 밖 이동으로 다시 차팅한다.

의제는 결정만 소유한다 — 결정이 빌드 가능해지는 순간 그 줄은 의제를 떠나 fg-ask가 적재하는 평범한 백로그 plan이 된다(이 선이 없으면 의제가 두 번째 백로그가 되어 fg-next·fg-run이 무엇을 봐야 하는지 모호해진다). 의존 엣지·blocking은 만들지 않고(파일 하나를 위→아래로 읽는 것이 곧 frontier), 티켓 유형 분류도 만들지 않으며(research/prototype/grilling/task는 해소기의 이름이고 forge엔 이미 다 있다 — 조건부 deep research·fg-showme·fg-ask·fg-quick), 스크립트도 만들지 않는다. 그릴링 방법은 fg-ask의 단일 정의를 참조할 뿐 복붙하지 않으며 출력만 다르다(백로그 plan이 아니라 의제 한 줄 + 조건부 ADR). fg-next/fg-status의 다음 단계 사슬에는 편입되지 않는다 — 그 사슬은 진행 중인 한 작업의 것이고 의제는 병행하는 계획 표면이라 fg-status는 한 줄 보고만 한다. 형제 유틸리티 fg-loop의 거울상이다: loop.md는 기계 검증 가능한 정지 조건 + 무인 주행, agenda.md는 판단 정지 조건 + HITL — 같은 모양의 계약 파일, 반대 성질의 멈춤. 개념은 mattpocock/skills의 Wayfinder(MIT) 각색이며 코드 vendoring이 아니라 개념 각색이다(파일 복사 없음, 이름은 forge 어휘로 — forge에서 "지도"는 이미 fg-map의 것이다). "forge agenda", "의제", "결정 대기열", "뭘 결정해야 하는지 정리해줘" 같은 발화에서 트리거된다 (ADR 260805-201313).

fg-security

fg-security는 코드베이스 보안 감사로, 루프 밖이다 — 방법론은 forge가 쓰지 않았다. cloudflare/security-audit-skill을 MIT 귀속과 함께 vendoring해 AUDIT.md와 공격 유형별 플레이북 9종(ATTACK-CLASSES·WEB-PROTOCOL-AND-AUTH·CLIENT-SIDE·AI-AND-LLM·MEMORY-SAFETY-AND-BINARY 등)·report-schema.json·validate-findings.cjs를 원형 그대로 두었다(업스트림 diff가 싸게 유지되도록 진입 파일만 AUDIT.md로 개명 — forge는 skills/<name>/SKILL.md로 스킬을 자동 탐색하므로 이름 충돌과 중첩 오탐을 피한 것이다). recon → 공격 유형별 병렬 hunting → 독립 검증 → 리포트의 다단계 다중 에이전트 감사이며, 업스트림 스스로 *"한 번의 실행은 전체 취약점의 절반 정도만 찾는다"*고 적어 복수 실행을 권한다.

forge가 더하는 것은 정확히 세 가지다. ① findings가 리포트에서 끝나지 않고 루프에 들어온다 — 감사 산출물 자체는 업스트림 기본값 ~/security-audit-skill/<repo>/run-<N>/, 즉 리포 밖에 남는다. 초기 설계는 최상위 .forge/security/였으나 봉인 전 적대적 리뷰가 그 보증을 무너뜨렸다 — *".gitignore의 .forge/*가 덮는다"*는 forge 자기 리포에서만 참이고, forge는 대상 리포에 .gitignore를 쓰지 않으며, ADR이 스스로 밝힌 사용처는 "forge가 구동하는 사용자의 다른 프로젝트"(그 규칙을 가질 가능성이 가장 낮은 리포)다. 리포 안은 구조적으로 안전하게 만들 수 없고 리포 밖은 커밋 경로가 존재하지 않는다. 대가는 정직하게 — 산출물이 클론과 함께 이동하지 않고 팀이 못 읽으며 홈 디렉터리라 잊기 쉽다(그래서 핸드오프가 실행 경로를 전체로 명시한다). 곁들여 드러난 함정 둘: ADR-0011의 "전역 예외"는 브랜치 네임스페이싱이고 git 추적과 무관하며(기존 예외 둘은 전역이면서 추적된다), !.forge/branch/는 비-기본 브랜치 루트를 통째로 추적한다. ② 심각도 게이트를 통과한 findings만 사람 승인 후 fix-forward 백로그 plan이 된다 — CRITICAL·HIGH는 각각 제안(같은 코드 경로·같은 수정이면 묶어서), MEDIUM은 제안하되 묶기 권고, LOW·INFO는 리포트에만 남고 plan을 만들지 않는다. forge가 다른 모든 곳에서 쓰는 승급 바(회고 승급·ADR 3조건·CONTEXT.md 용어)와 같은 모양이고, 실제 감사가 findings 5~20건을 내므로 전부 승급하면 백로그가 홍수가 되어 활성 슬롯 1개 규율이 무의미해진다. 생성 plan은 <!-- generated-by: fg-security --> 마커와 단조 task: 번호를 달고, DoD는 **"그 취약점이 더는 재현되지 않음"**이다 — 업스트림이 MEDIUM+ findings의 데이터 흐름을 FINDINGS-DETAIL.md에 남기므로 그 재현 경로가 ADR-0009 검증 게이트를 채운다. ③ 무인 주행(fg-next all·fg-loop)에서는 회고처럼 항상 skip된다 — findings의 진위와 수정 가치 판단은 사람 몫이다.

봉인을 막지 않는다(게이트는 verified:와 회고뿐). "forge security", "보안 감사", "취약점 찾아줘", "security audit" 같은 발화에서 트리거된다 (ADR 260820-215004).

fg-debug

fg-debug는 어려운 버그의 대화형 진단 규율로, 루프 밖이다 — 방법론은 forge가 쓰지 않았다. mattpocock/skills의 diagnosing-bugs를 MIT 귀속과 함께 vendoring해 진입 파일(DIAGNOSE.md로 개명 — forge는 skills/<name>/SKILL.md로 스킬을 자동 탐색하므로 이름 충돌 회피)과 scripts/hitl-loop.template.sh를 바이트 그대로 두었다(fg-security 선례 — 업스트림 diff가 싸게 유지된다). 규율의 뼈대는 Phase 1–4다: red를 낼 수 있는 피드백 루프(가능하면 올바른 seam의 failing test)를 먼저 만들고, 재현하고, 최소화하고, 가설을 순위화한다 — 새 .forge/ 상태는 없으며, 워킹 트리에 남을 수 있는 것은 비밀 제거가 확인된 fixture와 영속 테스트뿐이다.

forge가 더하는 것은 경계다. fg-debug는 진단만 하며 수정 크기보다 호출 상태를 먼저 판정한다 — 활성 verified: failed 작업을 진단했다면 수정이 trivial이어도 기존 fg-run의 fix-and-re-run 경로로 복귀한다. 활성 실패가 없는 독립 진단만 trivial이면 fg-quick, non-trivial이면 사람 승인 후 <!-- generated-by: fg-debug --> 마커를 단 fix-forward plan으로 간다. Phase 1의 red 명령은 그 자체가 영속 회귀 체크일 때만 eval이다. 일회성 curl·trace·HITL이면 plan에 영속 체크 slice를 추가하거나 기계적 영속화가 불가능한 이유를 기록한다. 비밀 제거가 확인된 fixture와 테스트만 워킹 트리에 남길 수 있고, 원본 trace·HAR·로그는 밖의 임시 위치에서만 다루며 성공·불확정·fg-quick 이관을 포함한 모든 종료 경로에서 임시 계측과 함께 정리한다. 대화형이라 무인 주행(fg-next all·fg-loop)에서는 회고처럼 항상 skip된다.

봉인을 막지 않는다(게이트는 verified:와 회고뿐). "debug this", "디버깅해줘", "버그 잡아줘", "왜 안 되지" 같은 발화에서 트리거된다 (ADR 260907-140655).