iop/agent-ops/skills/common/plan/SKILL.md

name

description

plan

Analyze the current repository and write a detailed PLAN-{build_lane}-GNN.md plus CODE_REVIEW-{review_lane}-GNN.md stub for implementation work. Use for every feature, refactor, bug fix, and code-review WARN/FAIL follow-up that enters the plan-code-review loop. Every initial or follow-up pair must run finalize-task-routing after analysis and before routed filenames are chosen. Milestone-linked work uses a reserved m-prefixed task group so runtime can route PASS completion events to update-roadmap.

Plan

Purpose

Create the planning artifacts for the implementation loop:

plan skill -> analysis -> finalize-task-routing -> PLAN-{build_lane}-GNN.md + CODE_REVIEW-{review_lane}-GNN.md stub
implementation -> code changes + filled implementation evidence in CODE_REVIEW-{review_lane}-GNN.md
code-review skill -> verdict + archive, complete.log and task-directory archive move, USER_REVIEW.md, or mandatory plan-skill follow-up
runtime -> for m-prefixed PASS completion events, state check and optional update-roadmap call

code-review may stop the automatic loop with USER_REVIEW.md only when a selected Milestone 구현 잠금 > 결정 필요 item blocks implementation. Repeated non-PASS reviews, test environment blockers, external environment/secret/service setup, generic scope changes, and verification evidence gaps are not user-review reasons by themselves; they should become normal follow-up plans or unresolved verification evidence. Plan creation after USER_REVIEW.md requires the linked Milestone decision to be resolved. If the decision closes the task as complete/PASS, code-review resolves USER_REVIEW.md, writes complete.log, and archives the task instead of creating a new plan.

The plan file and review stub must be self-sufficient for implementation agents that do not read this skill. Implementing agents fill the active review's implementation evidence. They never decide whether user review is needed, write a user-review request, ask the user for a decision, create USER_REVIEW.md, or maintain dispatcher execution logs; those control-plane responsibilities belong to the official code-review skill and runtime.

Workflow Contract

This skill intentionally uses routed active files under an active task directory as the state protocol. Do not change this directory or filename contract unless the paired code-review skill is updated together.

Invocation modes:

• write is the default for initial plans and explicit replans. After routing, this skill archives any prior active pair and writes the new pair.
• prepare-follow-up is used only when code-review has appended WARN/FAIL but has not archived the active pair. This skill completes analysis, final routing, and exact PLAN/review-stub rendering in memory without mutating repository files. It returns prepared_plan, prepared_review, their routed basenames, the current pair's predicted archive names/numbers, and the post-archive log counts used by the new pair.
• Both modes execute the same mandatory Step 3. prepare-follow-up is not a route-only shortcut.

Task path terms:

• {task_group} is the top-level work category under agent-task/. Normal task groups use a short snake_case name such as refactoring.
• Milestone-linked work uses the reserved task group form m-<milestone-slug>, where <milestone-slug> is the active Milestone filename without .md.
• {subtask_dir} is used only for split work and follows the existing indexed directory naming rules below, such as 01_core or 02+01_db.
• {subtask_name} is the short snake_case name after the index or dependency prefix inside {subtask_dir}.
• {task_name} in headers and templates means the active task path relative to agent-task/: either {task_group} for a single-plan task or {task_group}/{subtask_dir} for a split subtask.
• A single-plan task stores active files directly under agent-task/{task_group}/.
• Split work stores active files under agent-task/{task_group}/{subtask_dir}/; the parent agent-task/{task_group}/ contains no active plan/review files and may contain only dispatcher-owned group artifacts such as WORK_LOG.md.

Filename rules:

• Plan file: PLAN-{build_lane}-GNN.md
• Review stub: CODE_REVIEW-{review_lane}-GNN.md
• {lane} is only local or cloud; never put model names in filenames.
• GNN is a two-digit capability grade from G01 to G10; the runtime maps lane+grade to current models externally.
• Lane, grade, and both canonical basenames come only from agent-ops/skills/common/finalize-task-routing/SKILL.md.

Role boundary rules:

• Implementing agents fill implementation-owned CODE_REVIEW-*-G??.md sections, keep active files in place, and report ready for review.
• Implementing agents do not create or edit WORK_LOG.md. The dispatcher owns the single task-group timeline at agent-task/{task_group}/WORK_LOG.md.
• If implementation cannot continue, implementing agents record the exact blocker, attempted commands/output, and resume condition only in 검증 결과 or 계획 대비 변경 사항, then leave the active files in place for official review.
• During implementation, do not ask the user directly, present choices, call user-input tools, or create control-plane stop files. The official reviewer owns all next-state classification.
• Required UI evidence capture that needs a user-owned device, emulator, permission, secret, or interactive access unavailable to the agent is a verification blocker, not a user-review reason by itself. Record attempted commands and blocker evidence in 검증 결과 or 계획 대비 변경 사항 so code-review can write a normal follow-up or unresolved verification report.
• Finalization (코드리뷰 결과, plan/review log rename, complete.log, task artifact archive moves, review-only checklist) is code-review-skill only. Task-group WORK_LOG.md는 code-review가 이동하지 않으며 dispatcher가 마지막 FINISH 기록과 group 완료 확인 뒤 work_log_N.log로 archive한다.

Split decision policy:

• Default to multiple subtask directories under one task group. Before writing any plan, decide whether the work has smaller independently reviewable implementation units.
• If there is any natural dependency boundary, ownership boundary, subsystem boundary, API-vs-call-site phase, test strategy split, or independently reviewable risk, write multiple subtask directories under one task group.
• Split by independently verifiable behavior or contract slices, not by production/test/fixture artifact type.
• Keep each production change with the tests required by the Test policy for its PASS. A test-only child is allowed only for additional integration or closure evidence across completed production children.
• A shared package, helper, or validation pattern is not a merge reason when two public contract families can be implemented and tested independently.
• A single plan is an exception. Use one only when all of these are true: the work is one coherent implementation unit, it has one primary ownership boundary, it has no prerequisite subtask, splitting would create artificial coordination overhead, and the whole change remains easy to review at once.
• When uncertain, split. Do not choose a single plan merely because it is shorter to write.
• Record the split decision in the plan. For a single plan, explicitly state why each applicable split boundary does not require a separate task. For multi-plan output, list the shared {task_group}, each sibling {subtask_dir}, and its dependency relationship.

Split gates:

• Split when the work combines shared API/foundation changes with broad call-site rollout. Put the API/foundation in an earlier task and the rollout in dependent task(s).
• Split when the work touches multiple domains or ownership boundaries, unless the change is purely mechanical and trivially reviewable.
• Split when different parts can be verified with different focused tests or have different risk profiles.
• Split when a likely failure in one part would force rewriting unrelated parts of the plan.
• Split when one part can produce a useful complete.log before another part starts.
• Split when mobile/UI verification can hang on emulator/device state, modal, permission dialog, animation, or external runner; isolate evidence recovery from feature implementation.

Task directory naming rules:

• A normal single-plan task uses agent-task/{task_group}/ with a short snake_case category name, e.g. agent-task/refactoring/.
• If the plan is based on a selected active Milestone, use agent-task/m-<milestone-slug>/ as the task group. Do not include the Phase slug, Epic id, Task id, or a separate task slug in the task group.
• m-<milestone-slug> is a reserved top-level task group namespace for Milestone-linked work. Non-roadmap tasks must not use m-.
• Runtime completion-event routing for m-* reads only the top-level {task_group} name. It resolves <milestone-slug> by matching exactly one active file at agent-roadmap/phase/*/milestones/<milestone-slug>.md; archive paths are not target candidates.
• When split gates require decomposition, create one shared category folder and multiple subtask directories under it. Each subtask directory owns exactly one normal active plan file and one normal active review stub.
• Multi-plan output is a set of independent PLAN-{build_lane}-GNN.md + CODE_REVIEW-{review_lane}-GNN.md pairs across agent-task/{task_group}/{subtask_dir}/ folders, not multiple plan files inside one folder.
• Multi-plan subtask directory names must start with a stable two-digit task index. The index must increase across sibling subtask directories for sorting, but it is not a serial execution dependency.
• Assign new sibling indices in topological dependency order so every producer precedes its consumers. For ties, keep the planned sibling order; assign each task the lowest collision-free two-digit index greater than all of its predecessors.
• Before writing the pairs, verify that the sibling dependency graph has no cycle and every predecessor index is lower than its consumer index. Skip an index only when it is not greater than an unchanged existing predecessor or is already occupied by an active/archived sibling.
• Use NN_{subtask_name} for a task with no runtime dependencies, e.g. 01_core, 04_docs, 05_ui.
• Use NN+PP[,QQ...]_{subtask_name} for a task that depends on earlier task indices, e.g. 02+01_db, 03+01,02_api, 06+05_integration.
• Valid independent pattern: ^[0-9]{2}_[a-z0-9_]+$.
• Valid dependent pattern: ^[0-9]{2}\+[0-9]{2}(,[0-9]{2})*_[a-z0-9_]+$.
• NN, PP, and QQ are two-digit indices. Every predecessor index after + must be lower than NN and must refer to a sibling multi-plan subtask directory under the same {task_group}.
• The first _ after the index or dependency list starts {subtask_name}. {subtask_name} stays short snake_case and may contain additional underscores.
• Runtime scheduling reads only the {subtask_dir} name: _ means depends_on=[]; + means depends_on is the comma-separated index list between + and the first _.
• Subtask directory names are the source of truth for runtime dependencies. Do not hide extra dependencies only in the plan body, and do not create a bare NN+{subtask_name} without predecessor indices.
• A predecessor index is satisfied by a complete.log for the matching predecessor subtask under the same {task_group}. Check active siblings first, then matching archived subtasks across all archive month folders. This is a narrow exception to the normal archive skip rule: read only candidate predecessor complete.log files needed to prove split dependency completion.
• For predecessor index PP, the only valid active lookup candidates are agent-task/{task_group}/PP_*/complete.log and agent-task/{task_group}/PP+*/complete.log.
• For predecessor index PP, the only valid archive lookup candidates are agent-task/archive/*/*/{task_group}/PP_*/complete.log and agent-task/archive/*/*/{task_group}/PP+*/complete.log.
• Archive lookup matches the predecessor index at the start of the archived subtask directory name, such as 01_... or 01+..., under the same {task_group}. If multiple candidates match one predecessor index, do not choose by guess; record the ambiguity and require a concrete task path or runtime selection.
• Do not treat an archived predecessor as the active task to edit. Archive lookup is only for dependency satisfaction before writing or implementing a dependent split plan.
• Example: split a refactoring common core plus two app integrations under agent-task/refactoring/ as 01_core, 02+01_edge_integration, 03+01_node_integration. Both integrations depend only on 01_core and may run in parallel after 01_core has complete.log.
• Example: split three sequential tasks under one task group as 01_schema, 02+01_migration, 03+02_api.
• Example: split independent docs/UI plus an integration under one task group as 01_core, 02+01_db, 03+02_api, 04_docs, 05_ui, 06+05_integration; 01_core, 04_docs, and 05_ui can start together, and 06+05_integration waits only for 05_ui.
• After a pair is written, preserve its task group and subtask directory name verbatim. Only an explicit refine-local-plans run may rename eligible unstarted local siblings by its dependency-order rules.

Final routing boundary:

• Do not estimate, inherit, or write lane/G while analyzing. Keep the task unrouted until all plan scope, split, verification, evidence, ownership, and decision facts are complete.
• Execute agent-ops/skills/common/finalize-task-routing/SKILL.md for both build and review after analysis. Its routed outputs are the only source for active PLAN/CODE_REVIEW filenames.
• Apply this boundary to first-pass plans, review WARN/FAIL follow-ups, USER_REVIEW replans, and each split subtask independently.
• Exception: an explicit refine-local-plans run may split an unstarted PLAN-local-G??.md into strict-subset local children once. Those children retain the original build/review lane, G, and canonical basenames without rerouting; normal plan creation and review follow-up never use this exception.
• A previous loop's lane, grade, score, rationale, and filename are quarantined. Prior code paths, actual command output, and review findings may be carried only as revalidated raw evidence.
• needs_evidence requires evidence collection and a fresh full routing run. blocked stops plan-file creation. Neither state may produce active routed filenames.
• Outside that explicit refinement exception, if plan facts change after routing, invalidate both target results and run final routing again before writing files.
• Treat non-behavioral review artifact drift and obvious non-behavioral source nits as current-scope evidence; they do not bypass final routing.

Directory states:

State	Meaning
PLAN-*-G??.md only	Invalid; plan skill always writes both active files
PLAN-*-G??.md + CODE_REVIEW-*-G??.md stub	Implementation is pending/in progress
PLAN-*-G??.md + filled CODE_REVIEW-*-G??.md without verdict	Ready for code-review skill
PLAN-*-G??.md + CODE_REVIEW-*-G??.md with appended verdict	Review finalization is pending. Continue only when code-review invokes prepare-follow-up; write mode must not overwrite this state.
complete.log + *.log files	Task complete (PASS or user-review-resolved PASS), before final task-directory archive move
USER_REVIEW.md + *.log files	Automatic loop stopped; linked Milestone lock decision must be resolved before creating another plan
agent-task/archive/YYYY/MM/{task_name}/complete.log + *.log files	Archived completed task path (PASS or user-review-resolved PASS); not active
Only *.log files (no complete.log)	Inspect the newest review log. A verdict with no required next state is post-archive finalization pending; otherwise the task is terminated mid-loop or abandoned.

Step 1 - Determine Task

If the user names the task explicitly, use that task group or task path.

Otherwise, find active plan files with both globs, excluding agent-task/archive/**:

• agent-task/*/PLAN-*-G??.md
• agent-task/*/*/PLAN-*-G??.md

Also note active user-review stops, excluding agent-task/archive/**:

• agent-task/*/USER_REVIEW.md
• agent-task/*/*/USER_REVIEW.md

Result	Action
Exactly one	Continue that task
None	Create a new task only for a feature/refactor/fix/follow-up that belongs in this workflow
Multiple	If the user/runtime named a task group, task path, or subtask directory that identifies exactly one active plan, use it. Otherwise list paths and stop with an ambiguity report; do not choose by agent judgment and do not create a user-review request for routing ambiguity.

The routed plan file is the loop entry point. A missing active plan normally means only that no plan has been started for a new task; do not create task files for casual analysis, status, or review requests unless the user explicitly asks for a plan.

If no active plan exists but one or more USER_REVIEW.md files exist, report that the linked Milestone decision is required and list the paths unless one path is explicitly selected for resolution or replanning. If a selected active task directory contains USER_REVIEW.md, read it before planning. Do not write a new follow-up plan unless the linked Milestone decision has been resolved or the new plan explicitly replans around that recorded decision. When planning resumes from USER_REVIEW.md, archive it to user_review_N.log in the same task directory before writing the new active plan/review pair, and record the resolved decision in the new plan 배경 or 분석 결과.

If a selected task directory contains both USER_REVIEW.md and active PLAN-*-G??.md or CODE_REVIEW-*-G??.md, report an inconsistent loop state and do not overwrite either state until a later explicit command selects either user-review resolution or the active plan/review path.

If the selected review already has an appended verdict, accept it only in prepare-follow-up mode invoked by code-review. In every other mode, leave the pair unchanged and report that code-review finalization must resume.

로드맵 확인:

• agent-roadmap/current.md는 브랜치별 로컬 포인터다. 있으면 구현 계획 파일을 만들기 전에 읽고, 사용자 요청, 브랜치, 변경 경로를 기준으로 관련 Phase와 Milestone을 선택한다.
• agent-roadmap/priority-queue.md가 있으면 명시 target이 없는 구현 계획에서 Phase를 가로지르는 후보 순서를 확인하기 위해 읽는다. 큐 순서는 우선순위 참고이며, 상태/잠금/기능 원본은 각 Milestone 문서다.
• 사용자가 target Milestone을 명시하지 않았고 요청이 "다음 작업" 또는 일반 구현 계획이면 priority-queue.md의 위에서 아래 순서 중 요청과 맞고 활성 경로에 존재하는 첫 Milestone을 우선 후보로 둔다.
• priority-queue.md 링크가 깨졌으면 Milestone을 추측해 계획하지 말고 update-roadmap으로 큐 재정렬/재생성이 필요하다고 보고한다.
• agent-roadmap/이 있는데 current.md가 없으면 agent-ops/skills/common/_templates/roadmap-current-template.md 형식으로 로컬 파일을 만들거나, ROADMAP.md의 Phase 흐름과 관련 PHASE.md에서 후보를 고른 뒤 로컬 current를 채운다. current 없음만으로 일반 task routing으로 빠지지 않는다.
• current.md가 agent-roadmap/archive/**를 가리키면 해당 문서는 읽지 말고 활성 Phase/Milestone이 아니라고 보고한다.
• 선택한 Phase를 한 번 읽어 Phase 목표, Milestone 흐름, Phase 경계를 확인한다.
• 선택한 Milestone을 한 번 읽어 목표, 상태, 승격 조건, 범위, 기능 Task, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다. 승격 조건은 [스케치]에서만 필수이며, [계획] 이상에서 섹션이 없으면 없음으로 본다. 구현 잠금 섹션이 없거나, 상태가 잠금이거나, 미완료 결정 필요 항목이 하나라도 있으면 실구현 계획을 만들지 않는다.
• 구현 잠금에 걸린 Milestone에서는 PLAN-*-G??.md, CODE_REVIEW-*-G??.md, task directory, file/API/package 수준 구현 단계를 확정하지 말고 구현 잠금 차단으로 보고한다. 보고에는 Milestone 경로, 잠금 상태, 남은 결정 필요 항목, 다음에 필요한 update-roadmap 조치를 적는다.
• 남은 결정 필요 항목이 현재 실구현 범위가 아니라고 판단되더라도 같은 plan 요청 안에서 구현 계획을 계속 쓰지 않는다. 먼저 roadmap-only 갱신으로 해당 항목을 범위 제외, 후속 Milestone, 또는 작업 컨텍스트로 옮기고 구현 잠금을 해제한 뒤 새 plan 요청에서 진행한다.
• 선택한 Milestone에 SDD: 필요가 있으면 승인된 SDD를 구현 계획 작성의 입력으로 읽는다. SDD 문서가 없거나, 상태가 [승인됨]이 아니거나, SDD 잠금이 잠금이거나, 같은 디렉터리에 USER_REVIEW.md가 있으면 plan 파일을 만들지 말고 roadmap-sdd 또는 update-roadmap 조치가 필요하다고 보고한다.
• SDD: 필요 Milestone의 구현 계획은 Milestone 기능 Task만 보고 작성하지 않는다. 요청 대상 Task id에 연결된 SDD Acceptance Scenario와 Evidence Map을 먼저 매핑하고, 그 결과에서 구현 범위, checklist, 검증 명령, 완료 evidence를 역산한다. 매핑이 없거나 SDD와 Milestone Task가 어긋나면 plan 생성을 멈추고 SDD와 Milestone의 정합성 갱신이 필요하다고 보고한다.
• 선택한 Milestone에 legacy 필수 기능/완료 기준이 분리되어 있으면 plan 파일을 만들지 말고 update-roadmap 정규화가 필요하다고 보고한다.
• 선택한 Phase 또는 Milestone 상태가 [스케치]이면 구현 계획 파일을 만들지 않는다. [스케치]는 컨셉 상태이므로 update-roadmap의 concretize 흐름으로 승격 조건, 결정 필요, 범위, 기능 Task를 정리해 [계획]으로 전환해야 한다고 보고한다.
• Phase 또는 Milestone 후보가 여럿이면 요청 문장, 변경 경로 직접성, Milestone 상태, 구현 잠금, 선후 의존성, Phase/Milestone 흐름상 위치를 기준으로 1순위와 2순위를 추천하고 필요한 후보 문서만 읽어 범위를 좁힌다.
• 로드맵 current가 있고 활성 Phase/Milestone 밖 작업이면 ROADMAP.md의 Phase 흐름을 확인하고 전환, 신규 Phase/Milestone, 또는 기존 활성 범위 내 배치 필요성을 보고한다.
• 사용자가 선택한 Milestone의 작업, 구현, 계획 작성을 명시했더라도 구현 잠금이 완전히 해제되어 있지 않으면 계획 작성을 이어가지 않는다. Milestone 전체에서 에이전트가 확정할 수 없는 결정 항목이 더 이상 없을 때만 roadmap update 흐름으로 구현 잠금 상태를 해제로 갱신할 수 있다.
• 제품 선택, 우선순위 결정처럼 에이전트가 확정할 수 없는 항목은 구현 계획의 실행 checklist로 쓰지 않는다. 그런 항목이 남아 있으면 plan 생성을 멈추고 구현 잠금 > 결정 필요로 분리한다.
• 기능 Task에 검증:이 있으면 구현 계획의 같은 plan item 안에 해당 검증을 포함한다. 검증이 명시되지 않은 기능 Task에는 억지 검증 항목을 만들지 말고, 필요한 일반 빌드/회귀 확인만 최종 검증에 둔다.
• 선택한 활성 Milestone 범위에 속하는 구현 계획이면 {task_group}을 m-<milestone-slug>로 정한다. <milestone-slug>는 선택한 Milestone 경로의 파일명에서 .md를 제거한 값이다.
• 같은 Milestone에서 split work가 필요하면 기존 split 규칙 그대로 agent-task/m-<milestone-slug>/<subtask_dir>/ 아래에 계획 파일을 만든다.
• Milestone 기능 Task 완료를 목표로 하는 계획이면 Roadmap Targets 섹션에 활성 Milestone 경로와 완료 대상 Task id를 고정한다. 이 섹션은 complete.log의 Roadmap Completion 근거로 복사되어 update-roadmap이 해당 Task만 체크하는 anchor가 된다. 이 섹션은 {task_group}이 해당 Milestone slug의 m-<milestone-slug>일 때만 쓴다.
• Milestone 작업이 아니거나, Milestone 안의 조사/하위 구현처럼 특정 기능 Task 완료를 주장하지 않는 계획이면 Roadmap Targets 섹션을 쓰지 않는다. 섹션이 없으면 PASS 후에도 roadmap Task 체크를 하지 않는다.
• agent-roadmap/ 디렉터리가 없으면 기존 task routing 규칙대로 진행한다.

Use short snake_case task group names for non-roadmap work, e.g. api_refactor.

Before choosing plan files or task directory names, apply the split decision policy above. When the policy allows a single plan, write active files directly under agent-task/{task_group}/ and record the exception rationale. When the policy requires multiple plans, choose one shared {task_group} and {subtask_dir} names using the task directory naming rules above. Do not put multiple active plan files in one active task directory, and do not mix split subtask directories with active plan/review files directly in the parent task group.

Step 2 - Analyze Before Writing

Complete all items below before creating active plan/review files. Work through them in order; do not proceed to the next step until every checkbox is done. The only allowed file edits before writing plan/review files are local agent-roadmap/current.md creation or .gitignore block repair needed for roadmap routing, plus create-test or update-test edits when the repository already uses agent-test for the relevant scope or the user explicitly asked to maintain test rules.

• Load test environment rules — because implementation plans include verification, determine test_env before choosing verification commands. Use the user-specified environment when provided; otherwise use local. Agent-test is optional: some repositories or tasks intentionally do not have or use agent-test/. Check agent-test/<test_env>/rules.md; read it in full when present, even if it appears blank or skeleton. If it is absent, record that no agent-test rule was applied and choose fallback verification sources from repository manifests, scripts, workflows, domain rules, or direct read-only environment probes. Do not create agent-test files merely because a plan has verification. Invoke create-test only when the user asked for test-rule creation/maintenance, the current task is itself test-rule work, or the repository already uses agent-test for this scope and the missing/blank rule is a real maintenance gap. If creation is not appropriate or possible in the current task context, record the gap and fallback source; absence is not a user-review blocker by itself.
• Read all source files in full — read every source file the change will touch, whole file. No partial reads.
• Resolve test profiles — if env rules exist and contain ## 라우팅, read every matching agent-test/<test_env>/<test-profile>.md in full. If agent-test is absent or intentionally unused for the task, skip profile resolution and record the fallback verification source. Use create-test for missing or structurally blank routes/profiles only when the repository already uses agent-test for this scope or the task is test-rule maintenance. Use update-test only when verified command or criteria facts are available or the user asked to maintain test rules. If a profile exists but leaves command/criteria values as <확인 필요>, record the incomplete values and choose fallback verification commands from repository manifests or workflows with lower confidence. Do not claim agent-test requires a command that is not written in the env rules or matched profiles.
• Preflight non-local test environments — when any required verification leaves the current checkout, including remote runner, field/bootstrap, external provider, Docker/code-server, emulator/device, or shared long-running runtime, derive a read-only preflight before writing final verification commands. Use matched agent-test rules when they exist and apply; otherwise derive the preflight from repository manifests, scripts, workflows, domain rules, current task evidence, user-provided environment facts, and direct read-only probes. Record runner, repo root/workdir, branch/HEAD/dirty state, source sync status, binary/artifact paths, command help/version output needed by the verification, config path, runtime identity such as Edge id, ports/process state, external hosts, and OS/arch assumptions. If the preflight shows stale artifacts, dirty/divergent checkout, wrong identity, missing command, closed ports, host OS mismatch, or unsynced source, the plan must add an explicit setup/sync/rebuild step or report the blocker; do not write verification commands that silently assume profile or fallback values are already true.
• Read all test files in full — read every test file that exercises the changed behavior, including files implied by matched agent-test profiles when any are used and by the repository test layout.
• Assess test coverage — for each behavior change, explicitly record whether existing tests cover it.
• Assess split boundaries first — identify dependency boundaries, ownership boundaries, API-vs-call-site phases, risk profile splits, and independently verifiable behavior or contract slices before selecting plan files. Keep each production slice with its minimum required tests; use a test-only sibling only for additional integration or closure evidence. If any split gate applies or the decision is uncertain, write multiple subtask directories under one task group instead of one plan.
• Resolve split predecessor completion — if the selected or proposed subtask directory has NN+PP[,QQ...]_..., resolve each predecessor index under the same task group. Check only the active and archive candidate patterns defined in the task directory naming rules. Record found active/archive paths, missing predecessors, or ambiguous matches in 분석 결과 > 분할 판단 and, when order matters, 의존 관계 및 구현 순서.
• Grep all symbol references — for any renamed or removed symbol, find every call site and import chain.
• Check dependency manifests — before adding any new package, verify its presence in go.mod / package manifest.
• Pre-check compile issues — identify missing interface implementations, type mismatches, and broken imports.
• Verify verification commands — confirm that the final verification commands actually run in this repository layout.
• Stabilize fragile verification — for search or generated-output checks, choose deterministic commands up front, such as rg --sort path, and decide whether cached test output is acceptable or -count=1 is required.

Step 3 - Finalize Task Routing

This step is mandatory and must be the last semantic decision before routed filenames are fixed. Complete Step 2 and prepare the full plan structure in memory before starting it.

• Build neutral input — prepare current scope, affected paths, invariants, context size, split result, verification plan, actual evidence, ownership, unresolved decisions, and failure evidence for build and review. Exclude every previous lane, grade, routing score, rationale, filename, and archive basename that exposes them.
• Select evaluation mode — use first-pass only when no prior routing exists. Review follow-ups, invalidated routes, and USER_REVIEW replans use isolated-reassessment: build a route-free neutral snapshot, seal it as the only evaluation input, and evaluate it in a scratch block inside the current invocation. This logical isolation does not require or permit a sub-agent, delegated session, collaboration tool, or wait loop.
• Run the routing skill — read and fully execute agent-ops/skills/common/finalize-task-routing/SKILL.md with both targets in the selected mode. Do not reproduce or replace its decision logic inside this skill. If isolated evaluation is unavailable, treat the routing result as blocked; do not silently evaluate in the current anchored context.
• Resolve non-final states — for needs_evidence, collect the named evidence and rerun from unrouted; for blocked, stop without mutating task files and report the exact release condition. In prepare-follow-up, leave the verdict-appended active pair in place so code-review recovery can resume without losing the loop state.
• Accept only routed output — require independent build and review closure records, lane, grade scores, GNN, and canonical filename.
• Freeze the result — use those exact basenames in Steps 4-6. If any routing input changes before the files are written, discard both outputs and repeat this step from the beginning.

Step 4 - Archive Existing Active Files

In write mode, complete this step before writing new active files. In prepare-follow-up mode, calculate the same counts and archive names but do not modify any repository file; code-review owns the later archive.

• Validate that the task directory contains at most one active PLAN-(local|cloud)-G(0[1-9]|10).md, at most one active CODE_REVIEW-(local|cloud)-G(0[1-9]|10).md, and at most one USER_REVIEW.md. Reject ambiguous or malformed active names.
• In write mode, ensure .gitignore has the Agent-Ops managed gitignore block before renaming any active file to *.log or creating local agent-roadmap/current.md. Prefer source agent-ops/bin/ai-ignore.sh && agent_ops_ensure_gitignore_task_artifact_block .gitignore; if the helper is unavailable, add or update a block containing !agent-task/, !agent-task/**/, !agent-task/**/*.md, !agent-task/**/*.log, and agent-roadmap/current.md. In prepare-follow-up mode, only inspect the block and return gitignore_repair_needed: true|false; code-review performs any repair after preparation.
• Count existing plan_*.log as current_plan_archive_number. If an active plan exists, parse current_build_lane and current_build_grade from that active filename and set current_plan_archive_name=plan_{current_build_lane}_{current_build_grade}_{current_plan_archive_number}.log. Require that destination not to exist. In write mode rename that exact active file to the calculated name; in prepare-follow-up only return the name and number. Never use the newly routed build lane/grade to archive the old active plan.
• Count existing code_review_*.log as current_review_archive_number. If an active review exists, parse current_review_lane and current_review_grade from that active filename and set current_review_archive_name=code_review_{current_review_lane}_{current_review_grade}_{current_review_archive_number}.log. Require that destination not to exist. In write mode rename that exact active file to the calculated name; in prepare-follow-up only return the name and number. Never use the newly routed review lane/grade to archive the old active review.
• Count existing user_review_*.log as current_user_review_archive_number. If USER_REVIEW.md exists and the linked Milestone decision is resolved for replanning, set current_user_review_archive_name=user_review_{current_user_review_archive_number}.log; require that destination not to exist and rename it only in write mode.
• Compute post_archive_plan_log_count, post_archive_review_log_count, and post_archive_user_review_log_count from the filesystem after actual archive in write mode, or from the predicted addition of each current active file in prepare-follow-up mode.

Set plan_number=post_archive_plan_log_count. The new pair's future archive suffixes are plan_log_number=post_archive_plan_log_count and review_log_number=post_archive_review_log_count. These are intentionally different concepts from current_plan_archive_number and current_review_archive_number.

Step 5 - Write Plan File

Render the complete plan in memory first. In write mode, write it to the routed plan basename. In prepare-follow-up mode, return the exact rendered body as prepared_plan and do not write it.

Header line must be exactly:

<!-- task={task_name} plan={plan_number} tag={TAG} -->

Required sections:

• Title.
• 이 파일을 읽는 구현 에이전트에게: warn that filling implementation-owned CODE_REVIEW-*-G??.md sections is mandatory. Tell the implementer to run verification, fill actual notes/output, keep active files in place, and report ready for review; finalization is code-review-skill only. If blocked, the implementer records only exact blocker evidence, attempted commands/output, and resume conditions in implementation-owned evidence fields. It must not ask the user, call user-input tools, create control-plane stop files, classify the next state, archive logs, or write complete.log.
• 배경: 2-4 sentences explaining why the work is needed.
• Archive Evidence Snapshot: include this section only when the plan resumes from USER_REVIEW.md, a prior archived review, or any archive evidence. Omit it for first-pass plans with no archive evidence. The section must contain only the archive facts needed to implement without rereading archive by default: prior task/archive paths, verdict, Required/Suggested/Nit summary, affected files, verification evidence, and any roadmap carryover. If exact prior context is still required, cite the specific archive file paths allowed to read; do not ask the implementer to search agent-task/archive/** broadly.
• Roadmap Targets: include this section only when the plan is intended to complete one or more existing Milestone 기능 Task ids. Omit the section entirely for non-roadmap work or Milestone-adjacent work that should not check a Task on PASS. Format exactly:

## Roadmap Targets

- Milestone: `agent-roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md`
- Milestone link: [Milestone 문서](agent-roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md)
- Task ids:
  - `<task-id>`: <Task text or concise label>
- Completion mode: check-on-pass

• Agent UI Completion: include this section only when the plan implements agent-ui definition/frame/component changes in code and code-review PASS should move specific agent-ui documents to status: 구현됨. Omit it for non-agent-ui work, direct-sync work handled entirely by sync-agent-ui, and milestone-required work whose status update is intentionally deferred to Milestone 종료 검토. Format exactly:

## Agent UI Completion

- Mode: review-pass-status-update
- Agent UI docs:
  - `agent-ui/definition/views/<view-id>/index.md`
- Required code evidence:
  - `<code path>`: <what proves the UI definition is implemented>
- Required implementation verification:
  - `<test or analysis command>`: PASS expected before review
- Review finalization validation:
  - `validate-agent-ui scope=<scope>`: PASS expected after status/evidence update
- Status updates on PASS:
  - `agent-ui/definition/views/<view-id>/index.md`: `계획` -> `구현됨`

• 분석 결과: record the findings from Step 2 and the final routed output from Step 3. This section is the written output of the analysis — not a summary, but the actual findings that justify the plan's scope and decisions. Must include all of the following subsections:
  • 읽은 파일: list every source and test file read during analysis, with path. List agent-test rule/profile files only when they were actually present and read.
  • SDD 기준: for SDD: 필요 Milestones, list the SDD path, status, targeted Acceptance Scenario ids, their Milestone Task ids, and the Evidence Map rows that drive the plan. State explicitly how those rows shaped the implementation checklist and final verification. If the selected Milestone has SDD: 불필요, state the recorded reason. If the work is not Milestone-linked, state "not applicable".
  • 테스트 환경 규칙: state the chosen test_env, whether agent-test/<test_env>/rules.md was present/read/missing/intentionally unused, every matched profile path read when any, the concrete rules/commands applied, any structural blank/skeleton or missing rules, any <확인 필요> values, and any fallback verification source. If any required verification leaves the current checkout, include a 테스트 환경 프리플라이트 record with runner, repo root/workdir, branch/HEAD/dirty state, source sync status, binary/artifact paths, required command help/version output, config path, runtime identity such as Edge id, ports/process state, external hosts, OS/arch assumptions, and the exact setup/sync/rebuild step or blocker derived from mismatches. If agent-test is absent or unusable, explicitly say no agent-test rule was applied, what fallback is used, and whether test-rule maintenance is actually needed or not needed for this task.
  • 테스트 커버리지 공백: list each behavior change and whether existing tests cover it; explicitly note gaps.
  • 심볼 참조: list renamed/removed symbols and every call site found, or state "none" if no symbols were changed.
  • 분할 판단: state that the split decision policy was evaluated before choosing plan files. For a single plan, explain why each relevant split gate does not apply and why single-plan coordination is safer than splitting. For multi-plan output, list the shared task group plus each sibling subtask directory and dependency relationship. For dependent subtask plans, include each predecessor index and whether it is satisfied by an active or archived complete.log, missing, or ambiguous.
  • 범위 결정 근거: state which files or areas were explicitly excluded from this change and why. This is the boundary justification — the implementing agent must not silently expand scope beyond what is recorded here.
  • 최종 라우팅: record the evaluation_mode plus build and review closure results, grade scores, lane, GNN, and canonical filename returned by finalize-task-routing. Do not include or compare a previous loop's lane/G.
• 구현 체크리스트: a top-level checklist the implementing agent must follow while coding. Include one item per implementation/verification unit; if the roadmap feature Task has 검증:, keep that verification in the same checklist item instead of making a separate completion-criteria item. Include one item for whole-plan intermediate/final verification only when it is not already covered by the feature items. Make the last item exactly - [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. Copy this checklist into the review stub's 구현 체크리스트 section with the same item text and order.
• One item per change: ### [TAG-1] Title, TAG-2, etc.
• 수정 파일 요약: table mapping files to item ids.
• 최종 검증: runnable commands and expected outcome. Prefer commands from the matched agent-test env/profile rules. If agent-test is missing, blank, skeleton, or lacks a matching command, use repository manifests/workflows as fallback and record that fallback in 분석 결과 > 테스트 환경 규칙. Commands must be exact and deterministic enough for the reviewer to rerun; use stable ordering for searches and state whether cached test output is acceptable. End this section with "모든 코드 변경 완료 후 반드시 CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 채운다."

Each plan item must include:

• 문제: concrete problem with file:line references.
• 해결 방법: exact approach and before/after code block for non-trivial changes.
• 수정 파일 및 체크리스트: exhaustive file-level checklist.
• 테스트 작성: explicit write/skip decision. If writing tests, include path, test name, assertion goal, and fixtures. If skipping, justify.
• 중간 검증: runnable commands and expected result.

Include 의존 관계 및 구현 순서 only when order matters.

For split multi-plan work, the {subtask_dir} directory name is the runtime source of truth. If a plan has a NN+PP[,QQ...]_... subtask directory name, 의존 관계 및 구현 순서 must echo the decoded predecessor subtask directories under the same task group that must produce complete.log before implementation starts, and it must not add dependencies that are absent from the directory name. If a predecessor already completed, cite the active or archived complete.log path that satisfies it.

Quality rules:

• Exact line numbers in every Before snippet.
• Use the language's required override annotation/keyword wherever an abstract method is implemented.
• Include full import statements for new packages.
• List all call sites for renamed/removed symbols.
• Never write "add tests as needed"; decide up front.
• Do not cite files you did not read.
• Be concise. Write the minimum words needed to convey the decision or fact. No preamble, no restatement of context already in the plan, no closing summaries.

Test policy:

Change	Test requirement
Bug fix	Regression test required
New public API	Normal + boundary tests required
API rename	Existing test call-site updates usually enough
Internal refactor	Existing tests may be enough
Concurrency logic	Race/ordering test recommended

Verification fidelity rules:

• Plan verification commands are a contract. The implementing agent must run them exactly as written.
• If a command must be changed, the implementing agent must record the replacement command and reason in 계획 대비 변경 사항, then paste the replacement command's actual stdout/stderr.
• Before claiming a tool is unavailable, run and record command -v <tool> or the project-equivalent check.
• Before a remote/field/external verification command assumes a checkout, binary, config, runtime identity, or listening port, the plan must include a preflight command that proves those assumptions or a setup command that makes them true.
• Do not download, generate, or leave verification tools inside the repository. Temporary tools belong outside the repo, such as under /tmp, and must not become task artifacts.
• For search commands whose output order may vary, specify deterministic options in the plan, for example rg --sort path.
• 검증 결과 must contain actual stdout/stderr, not summarized or reconstructed output. If output is too long, record the saved output file path and the exact command used to create it.
• If mobile/UI verification has no progress for 2 minutes or times out, stop blind retries; collect focused stdout plus screenshot/window/UI-tree evidence when available, or record why capture is impossible.
• If the plan's pass condition says all leftovers must be intentional exceptions, any 변경 필요 item forces FAIL until resolved or explicitly reclassified with evidence.
• Decide in the plan whether Go test cache output is acceptable. If fresh execution matters, use go test -count=1 ....

Step 6 - Write Review Stub

Read agent-ops/skills/common/plan/templates/review-stub-template.md in full only after Step 3 returns status: routed. Replace every occurrence of each token below:

• Scalar tokens: {date}, {task_group}, {task_name}, {plan_number}, {TAG}, {build_lane}, {build_grade}, {review_lane}, {review_grade}, {plan_log_number}, {review_log_number}.
• Plan-copy tokens: {roadmap_targets_or_omit}, {archive_evidence_snapshot_or_omit}, {agent_ui_completion_or_omit}, {implementation_checklist}, {review_checkpoints}.
• Generated row/section tokens: {implementation_completion_rows} contains one row for every plan item, and {verification_result_sections} contains the fixed verification instructions plus every intermediate/final command from the plan.

Use the routed build/review grades independently. Remove optional plan-copy content by replacing its token with an empty string, not by leaving template instructions. In write mode, write the rendered stub to the routed review basename. In prepare-follow-up mode, return it as prepared_review without writing. Do not write or return a prepared pair when either routing target is not routed. After rendering, scan for the exact template-token inventory above and reject the output if any known token remains; do not reject unrelated braces in copied commands or code.

Naming

Tag	Use for
API	Public API changes
REFACTOR	Internal refactoring
TEST	Test additions/fixes
REVIEW_<TAG>	Follow-up fixes after review

Final Checklist

• In write mode, the routed PLAN-{build_lane}-GNN.md and CODE_REVIEW-{review_lane}-GNN.md both exist under agent-task/{task_name}/. In prepare-follow-up mode, neither routed file was written; both exact bodies and basenames were returned while the verdict-appended current pair remained active.
• In write mode, .gitignore has the Agent-Ops managed block that unignores agent-task/**/*.md and agent-task/**/*.log and ignores local agent-roadmap/current.md. In prepare-follow-up mode, the block was only inspected and any needed repair was returned as gitignore_repair_needed.
• Single-plan work stores active files directly under agent-task/{task_group}/.
• Split work, if any, uses one shared agent-task/{task_group}/ parent and one subtask directory per plan/review pair with names like 01_core, 02+01_edge_integration, 03+01_node_integration; dependency details live in the subtask directory name as NN+PP[,QQ...]_subtask_name.
• Split parent의 dispatcher-owned WORK_LOG.md는 plan/code-review agent가 수정하거나 archive하지 않는다.
• Split sibling indices follow topological dependency order: every predecessor is lower than its consumer, and every gap is explained by an unchanged existing predecessor or an occupied active/archive index.
• Milestone-linked work uses agent-task/m-<milestone-slug>/ as the task group; non-roadmap task groups do not start with m-.
• Both first lines match <!-- task={task_name} plan={plan_number} tag={TAG} -->.
• The review stub was rendered from agent-ops/skills/common/plan/templates/review-stub-template.md after routing and has no unresolved known template token.
• In write mode, previous active files, if any, were archived with lane/grade parsed from their own basenames and the correct current archive suffixes. In prepare-follow-up mode, those archive names were only predicted.
• In write mode when resuming from USER_REVIEW.md, it was archived to the calculated current_user_review_archive_name and the resolved linked Milestone decision was recorded in the new plan.
• Roadmap Targets exists only when PASS should check explicit Milestone Task ids, the task group is m-<milestone-slug> for the listed Milestone path, and every listed Task id exists in the selected active Milestone.
• If Roadmap Targets exists in the plan, the review stub contains the identical section. If it does not exist in the plan, the review stub omits it too.
• If Agent UI Completion exists in the plan, the review stub contains the matching section with implementation-owned evidence fields. If it does not exist in the plan, the review stub omits it too.
• If the selected Milestone has SDD: 필요, the plan's 분석 결과 > SDD 기준 proves that the implementation checklist and final verification were derived from the approved SDD Acceptance Scenarios and Evidence Map. Missing SDD mapping blocks plan creation.
• If the plan is a follow-up or resumes from prior archive evidence, it has Archive Evidence Snapshot and the review stub contains the identical section.
• 분석 결과 > 테스트 환경 규칙 records the selected test env, env rules read/missing/structural-blank/intentionally-unused state, matched profiles read when any, and any fallback verification source.
• Dependent split plans record predecessor completion using active sibling complete.log or matching archived complete.log; ambiguous archive matches are not guessed.
• Every plan item has problem, solution, checklist, test decision, and intermediate verification.
• The plan and review stub have matching 구현 체크리스트 item text/order; their final checkbox is the mandatory CODE_REVIEW-*-G??.md evidence item.
• finalize-task-routing ran after all analysis for both build and review in the required evaluation mode; its output status is routed, and the active filenames plus 분석 결과 > 최종 라우팅 exactly match its two results.
• Review WARN/FAIL follow-ups entered through this plan skill and did not inherit or compare the archived lane/G.
• The plan's implementer instructions and review stub limit local implementation agents to implementation/test/evidence work and keep user-review classification plus control-plane stop files out of their input and ownership.
• The review stub has a clearly marked 코드리뷰 전용 체크리스트 owned only by the review agent.
• Routed review file completion table lists every plan item.
• In prepare-follow-up, no repository file was mutated and the returned prepared basenames/bodies, plan_number, current archive names/numbers, post-archive log counts, and gitignore_repair_needed are complete; in write, prior active state was archived with its own parsed route and both new active files were written.