Gate C Procedure (follow order strictly)

0. Gate B pending check — if the Gate B block in ${CURRENT_SESSION_FILE} has a question whose 평가 is still the placeholder (e.g. 「(답변 후 기록)」), do not implement. Return to that question per gate-b/SKILL.md §Step 0 (a pending question moves only on an answer or an explicit 「스킵」). The comprehension-pending-guard hook enforces this when installed — it blocks /gate-c·/gate-d·/gate-e (typed or called through the Skill tool) while such a question exists.
1. Based on the Gate A detailed plan, implement the code
   • Follow the file list·change direction·execution order approved at Gate A verbatim
   • No additional changes·refactoring·comment cleanup beyond the plan
   • Ladder check (R-4-6): if an abstraction·helper not in the Gate A plan emerges mid-implementation, it is a ladder rung-1 violation — stop and apply the rung at the actual call site, or escalate per the Advisor rule below. (Restates the Exceeding change scope prohibition as a ladder check — no new rule.)
2. After implementation, summarize the result as text output — include the items below:
   • The actual changed-file list (state the reason if it differs from the Gate A plan)
   • Per-file key implementation summary (design decisions·core before→after difference)
   • Differences from the Gate A plan and their reasons (if none, "계획 그대로 구현")

Layer 2 documents

If TEST_PLAN.md or API_SPEC.md exists at the target repo root → SKILL_DETAIL.md §Layer 2 Documents.

3. Update the plan document(s) (status: C (확인 대기), write the Gate C block) — run the file-editing tool
   • Plan document(s) — tier-aware, see SKILL_DETAIL.md §Plan-Doc Update Pattern
   • ${SESSION_INDEX_FILE} YAML
   • ${CURRENT_SESSION_FILE} dashboard + Gate C block
4. STOP — await user document review·confirmation (unless a batch run was authorized — see §Batch runs)

Tests and builds run only in Gate D (npm test / pytest / ./gradlew test, etc.) — never inside Gate C's own steps. Without a batch authorization, Gate D starts in a separate turn after the user confirms Gate C.

Scope of 「구현해라」-like Instructions

「구현해」「계획대로 구현」「다음 계획을 구현해라」 reach Gate C at most — they never authorize Gate D·E. At the Gate A stage, 「계획대로 구현」 is the Gate A approval and starts gate-b first (see Step 0 for a pending Gate B question). To run C→D→E without stopping, the user must say so in a sentence that names the range — see §Batch runs.

Batch runs (CE·DE 일괄)

The single definition of the batch phrases (gate-d and gate-e only point here). Defined 2026-10-22: the phrases had been used (24 sessions in one month, 10 of them security-related) with no procedure behind them.

• Meaning: 「CE 일괄」 = run Gate C → Gate D → Gate E without the human STOP between them. 「DE 일괄」 = Gate D → Gate E. Gate D is never skipped — a batch removes the waiting, not the verification.
• Authorization: only a sentence that names the range counts — 「CE 일괄」「Gate C부터 E까지 한 번에」「DE 일괄」. 「진행」「구현」 「계획대로 구현」 alone never authorize a batch (they reach Gate C at most, as above).
• Approval that arrives before Gate B: a batch phrase sent while the session is still in Gate A — together with a scope answer, the plan approval, or a general 「다 진행해」 — does not skip Gate B. Run Gate B first (its pass-through verdict counts); the batch starts at Gate C. 「가드 우회 진행」 lifts only the Gate A size limit.
• Not for hard-trigger sessions: if the session touches security·auth, DB schema·migrations, a public API contract, destructive or irreversible operations, more than one repository, or a change that tests cannot verify — keep every STOP and tell the user why the batch was declined. When unsure, decline.
• Stop inside a batch: if Gate D ends with any FIX-B/DEP item, a non-converging verification loop, or a build failure, STOP after Gate D and report — do not run Gate E on a failing verification.
• Record: add > 일괄 실행: C~E (승인 문구: 「…」) (or D~E) at the top of each Gate block written during the batch.
• The guards still apply during a batch: the comprehension-question guard, the test-write guard in Gate D, the test-tampering guard, and the Gate E guard, which sends the session back when ✅E is written (in CURRENT_SESSION.md or SESSION_INDEX.md) without the Gate D markers (self-debug N회·FIX-B N건).

Autonomous lane (자율 레인)

Entered only by 「자율 레인 승인」 on a plan whose ### 레인 판정 reads 자율 (gate-a/SKILL.md §0-Lane). lane-scope-guard.py holds the scope; this section holds the procedure. It runs like a C~E batch (above) with these differences:

• No Gate B. Gate C → Gate D → Gate E with no human STOP until the review card in Gate E (gate-e/SKILL.md step 0). Gate D is never skipped.
• One prohibition: do not edit a test file, an acceptance command, CI config or anything under .claude/ to make a check pass — a check you cannot pass is a 막힘, not something to fix.
• One retry. In Gate D's loop (2-B) the upper bound is one retry, not ~3. Still failing after one fix → stop.
• 막힘 exit: stop and write 막힘: {reason} when a decision outside the plan is needed, a protected path or a file outside the plan would have to change, the spec and a test disagree, or the lane guard asked or denied. Do not work around it (for example via Bash). The user then chooses: revert, or a new /gate-a in the review lane.
• Markers stay: the Gate D block still writes self-debug N회 and FIX-B N건 · DEP N건 — error-topics-guard.py reads them.
• Record: add > 자율 레인 (승인 문구: 「자율 레인 승인」, 기준 커밋 {sha}) at the top of each Gate block written in the lane.

Advisor Escalation (optional)

During Gate C execution, if the situation below applies, you may make a single call to an Opus subagent for advice and then return.

Gate C trigger conditions (call only in these situations):

• A design branch not in the Gate A plan is discovered
• Conflict with an existing architecture pattern — cannot judge which direction is correct
• Cannot choose among 2+ implementation options

Call prohibited (resolve directly): syntax·API reference lookup (Grep/WebFetch suffices)

Session-cumulative max_uses: 3 times. On exceeding → escalate: ① git stash push -u -m "gate-c rollback" -- <this plan's changed files> to set this plan's work aside — never discard it ② report to the user — the stash name, which files were set aside, what was attempted, and why it failed → request a new Gate A re-plan.

Detailed call template·recording method·guardrails → CLAUDE_DETAIL.md §Advisor Escalation (a project file — skip if your project has none)

This Gate response's mandatory final output

After completing the entire Gate C procedure (code implementation + plan document(s) update), output the block below at the very end of the response. Omitting it or replacing it with other content is a PROC violation.

---
**다음 단계**: Gate C 확인 후 「Gate D 시작」또는 「검증」으로 응답하면 `/gate-d` (Gate D 검증)가 시작됩니다.
**권장 모델 전환**: ${CURRENT_SESSION_FILE} "Gate별 권장 모델" 표를 참조하여 필요 시 `/model {모델}` 실행 후 진행하세요.
💡 **compact 권장 시점**: Gate C 구현이 끝난 지금이 `/compact` 최적 타이밍입니다. Gate D는 테스트 결과라는 새로운 맥락으로 시작하므로, C의 시행착오 컨텍스트를 정리하면 토큰을 절약할 수 있습니다.