refactor(agent-ops): tighten skill authoring and review ownership

agent-ops/rules/common/philosophy.md

@@ -21,7 +21,7 @@
 - 긴 배경 설명은 README나 별도 참조 문서로 보내고, 실행 문서에는 실행 규칙만 남긴다.
 - 룰 문서는 협업자가 직접 읽는 계약 문서이므로 한국어 `한다`체로 작성한다.
 - README, GUIDE, roadmap 문서는 사람이 함께 검토하는 협업 문서이므로 한국어 설명체 또는 존댓말을 사용할 수 있다.
-- 스킬 문서는 실행 안정성을 우선한다. 한국어 또는 영어를 사용할 수 있고, 이미 잘 동작하는 절차 계약은 언어 통일만을 위해 수정하지 않는다.
+- 스킬 문서의 frontmatter `description`과 Markdown 본문은 영어로 작성한다. 기존 스킬은 언어 통일만을 위해 수정하지 않되, 새로 만들거나 실질적으로 갱신하는 스킬은 영어를 사용한다. 프로젝트가 요구하는 사용자-facing 출력 literal은 해당 언어를 유지할 수 있다.
 - path, filename, 상태값, id, regex, command, frontmatter key, runtime protocol token은 원문 ASCII 식별자를 유지한다.
 
 ## 라우팅

agent-ops/skills/common/_templates/skill-template.md

@@ -1,56 +1,51 @@
 ---
 name: <skill-name>
 version: 1.0.0
-description: <이 skill이 하는 일을 한 줄로 설명. 트리거 키워드 포함 권장>
+description: <Describe in one sentence what this skill does and when to use it. Include trigger keywords when useful.>
 ---
 
 # <skill-name>
 
-## 목적
+## Purpose
 
-<이 skill이 해결하는 문제를 1~2문장으로 설명>
+<Explain the problem this skill solves in one or two sentences.>
 
-## 언제 호출할지
+## When to use
 
-- <이 skill을 호출해야 하는 상황 1>
-- <이 skill을 호출해야 하는 상황 2>
-- <이 skill을 호출해야 하는 상황 3>
+- <Invocation case 1>
+- <Invocation case 2>
 
-## 입력
+<!-- Optional: remove this comment and the entire Inputs section when the skill has no explicit parameters. -->
+## Inputs
 
-- `<param-name>`: <설명> (필수)
-- `<param-name>`: <설명> (선택)
+- `<param-name>`: <Description.> (required)
 
-## 먼저 확인할 것
+<!-- Optional: remove this comment and the entire Preflight section when no check must precede execution. -->
+## Preflight
 
-- [ ] <실행 전 반드시 확인해야 할 조건 1>
-- [ ] <실행 전 반드시 확인해야 할 조건 2>
+- [ ] <Condition that must be checked before execution.>
 
-## 실행 절차
+## Procedure
 
-1. **<단계명>**
-   - <세부 행동>
-   - <세부 행동>
+1. **<Step name>**
+   - <Required action.>
 
-2. **<단계명>**
-   - <세부 행동>
+2. **Report the result**
+   - <Result to report.>
 
-3. **결과 보고**
-   - <출력할 내용>
+## Validation
 
-## 실행 결과 검증
+- [ ] <Verifiable success condition.>
+- If validation fails, <define the retry, rollback, or reporting action.>
 
-- [ ] <실행 후 확인해야 할 성공 조건 1>
-- [ ] <실행 후 확인해야 할 성공 조건 2>
-- 검증 실패 시: <실패 시 취할 행동 — 롤백, 사용자 알림, 재시도 등>
-
-## 출력 형식
+<!-- Optional: remove this comment and the entire Output format section unless an exact shape is required. -->
+## Output format
 
 ```
-<출력 예시>
+<Output example.>
 ```
 
-## 금지 사항
+<!-- Optional: remove this comment and the entire Prohibitions section unless a specific likely or unsafe action must be forbidden. -->
+## Prohibitions
 
-- <절대 하면 안 되는 것>
-- <절대 하면 안 되는 것>
+- <Forbidden action.>

agent-ops/skills/common/code-review/SKILL.md

@@ -20,12 +20,12 @@ Implementation agents never decide or request user review. They record implement
 ## Core Loop Rules
 
 - Trigger: Korean or English active-task review requests, including `리뷰 진행해` and `리뷰해줘`, must use this skill when an active `CODE_REVIEW-*-G??.md` or `USER_REVIEW.md` exists under `agent-task/*/` or `agent-task/*/*/`, excluding `agent-task/archive/**`.
-- Finalize every selected active state: for `CODE_REVIEW-*-G??.md`, append one verdict, prepare the required next state, archive the active review and plan files, then materialize exactly one next state; for `USER_REVIEW.md` completion, update the stop state, write `complete.log`, and archive the task.
+- Finalize every selected state unless Step 5 returns blocked. Normally append one verdict, prepare one next state, archive the pair, and materialize that state. For `dependency-wait`, keep the pair and persist `next-task`/resume condition without another verdict. A resolved `USER_REVIEW.md` writes `complete.log` and archives the task.
 - Next state: `PASS` writes `complete.log` and moves the task under `agent-task/archive/YYYY/MM/`; if the task group is `m-<milestone-slug>`, report completion metadata for the runtime event. `WARN` or `FAIL` normally invokes `agent-ops/skills/common/plan/SKILL.md`, which must run `finalize-task-routing` before writing the next active pair; if the user-review gate triggers, write `USER_REVIEW.md` instead. A completed `USER_REVIEW.md` uses the same terminal `complete.log` and archive path as `PASS`.
 - The user-review gate is review-agent-owned and triggers only when current evidence proves either that a concrete selected Milestone `구현 잠금 > 결정 필요` item blocks the next safe implementation step or that required external verification cannot proceed without a user-controlled capability or authorization. Generic status fields or blocker text written by implementation are never a user-review request.
 - Do not replace `USER_REVIEW.md` with an inline user question. When the user-review gate triggers, write the file-based stop state and report its path.
 - Do not ask for confirmation before WARN/FAIL follow-up files. If the user-review gate triggers, write `USER_REVIEW.md`; otherwise invoke the plan skill with the current raw findings and let it write the smallest concrete follow-up after fresh routing.
-- Recovery: if a prior turn appended a verdict without archive or next-state files, do not append another verdict; resume Step 5 preparation/archive from that verdict. If exactly one member of the pair was archived after both archive destinations had been preflighted, verify the archived member and remaining source/destination, finish that archive, then use the post-archive recovery below. If both logs exist with a verdict but the required next state is absent, reconstruct it from those exact logs: PASS resumes `complete.log`; WARN/FAIL reruns the plan skill in `write` mode with raw archived findings and `isolated-reassessment`; a valid user-review gate rerenders `USER_REVIEW.md`. If a prior turn resolved `USER_REVIEW.md` without `complete.log`, resume at the matching finalization step.
+- Recovery: if a prior turn appended a verdict without archive or next-state files, do not append another verdict; resume Step 5 preparation/archive from that verdict. If a pre-existing verdict predates stable finding ids, assign `R1..` and `S1..` once in displayed order in the recovery handoff and record that mapping without appending a second verdict. If exactly one member of the pair was archived after both archive destinations had been preflighted, verify the archived member and remaining source/destination, finish that archive, then use the post-archive recovery below. If both logs exist with a verdict but the required next state is absent, reconstruct it from those exact logs: PASS resumes `complete.log`; WARN/FAIL reruns the plan skill in `write` mode with raw archived findings and `isolated-reassessment`; a valid user-review gate rerenders `USER_REVIEW.md`. If a prior turn resolved `USER_REVIEW.md` without `complete.log`, resume at the matching finalization step.
 
 ## User Review Gate
 
@@ -98,6 +98,8 @@ Milestone task group contract:
 Follow-up routing boundary:
 
 - This skill records current source, actual verification output, and findings, but it must not estimate or recommend the next lane/G.
+- Decide each Required/Suggested disposition here and validate it directly; dispatcher use is optional. Default repository-fixable work to `direct-fix`, expanding stale exclusions when required by original acceptance. Allow `verified-dependency` only with the exact PLAN/task ordering proof, or `complete.log` plus fresh proof that the precondition is satisfied; vague owners and `complete.log` alone are invalid. Set `ownership_closed=true` only after every id has that proof.
+- Never send an unchanged-precondition verification packet. For an unordered dependency, keep the verdict pair and return `status=blocked`, `blocked_reason=dependency-wait`, `next-task`, and resume condition; do not redispatch it or request user review.
 - On WARN/FAIL, invoke the plan skill in `prepare-follow-up` mode with the selected task path and raw current evidence before archiving the current pair.
 - Do not pass the archived lane, grade, routing score, rationale, or filename as plan-routing input. Archive paths remain evidence pointers, and actual logs/findings remain raw evidence.
 - The plan skill must complete its full analysis and mandatory `finalize-task-routing` step before it writes the next pair. Code-review must not create a routed follow-up pair directly.
@@ -109,7 +111,7 @@ Directory states:
 |-------|---------|
 | `PLAN-*-G??.md` + unfilled `CODE_REVIEW-*-G??.md` stub/placeholders | Implementation is not judgeable; review should fail completeness if invoked |
 | `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 pending; do not append another verdict, resume Step 5 preparation/archive |
+| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with appended verdict | Review finalization pending or `dependency-wait`; do not append another verdict. Resume Step 5 immediately for unfinished finalization, or only after the recorded dependency changes for a wait. |
 | Exactly one active pair member + its newly archived counterpart | Partial archive after a preflighted finalization; verify both identities, finish the remaining archive, then resume post-archive recovery |
 | `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; its recorded Milestone decision or external-execution user action must be resolved before creating another plan |
@@ -190,7 +192,7 @@ Required fields for canonical English active pairs:
 
 - `Overall Verdict`: exactly `PASS`, `WARN`, or `FAIL`.
 - `Dimension Assessment`: Pass/Warn/Fail for correctness, completeness, test coverage, API contract, code quality, implementation deviation, verification trust. If SDD Evidence Map applies through `milestone-task`, also include spec conformance.
-- `Findings`: `None`, or bullets using `Required`, `Suggested`, or `Nit` with `file:line` and a concrete fix.
+- `Findings`: `None`, or bullets using stable `Required R1`, `Required R2`, `Suggested S1`, or `Suggested S2` ids with `file:line` and a concrete fix; Nit findings do not need ids. Keep every Required/Suggested id unchanged in the follow-up handoff and plan.
 - `Routing Signals`: calculate once and append `review_rework_count=<N>` and `evidence_integrity_failure=true|false`. Set rework count to archived same-task `WARN|FAIL` verdicts plus one only when the current verdict is non-PASS. Set integrity failure to true only when a claimed test, command, exit code, or production path is absent, unexecuted, or contradicted by fresh reviewer evidence.
 - `Next Step`: keep only the matching PASS, WARN/FAIL follow-up, or USER_REVIEW line.
 
@@ -229,13 +231,14 @@ Do not archive WARN/FAIL files until the next-state content is fully prepared in
 
 Reuse the routing signals appended in Step 4; do not recount verdict history for routing. Separately count the existing logs once for archive identity: set `current_review_archive_number=count(code_review_*.log)` and `current_plan_archive_number=count(plan_*.log)`, then derive both archive names from the current active files' own lane/grade. These archive values describe the pair being closed, not the next route.
 
-The follow-up handoff contains the selected `{task_name}`, the current plan's requested outcome/acceptance/exclusions revalidated against current evidence, current verdict, Required/Suggested/Nit findings, affected files, actual verification output, current ownership/dependency facts, roadmap carryover, `review_rework_count`, `evidence_integrity_failure`, `REVIEW_<PARENT_TAG>`, and those predicted current-pair archive names. Keep current active paths only as evidence pointers. Do not add the prior lane, grade, routing score, rationale, or a preferred next route to the neutral routing snapshot, and require plan to omit route-bearing basenames from the isolated routing input. The plan may use current archive names only after routing to render `Archive Evidence Snapshot`.
+The follow-up handoff contains the selected `{task_name}`, revalidated outcome/acceptance/exclusions, current verdict and stable Required/Suggested ids, affected files, actual verification output, each id's `direct-fix` or `verified-dependency` disposition and exact evidence, roadmap carryover, routing signals, `REVIEW_<PARENT_TAG>`, and predicted current-pair archive names. Keep current active paths only as evidence pointers. Omit prior lane, grade, routing score, rationale, filename, and preferred next route from routing input. The plan may use current archive names only after routing to render `Archive Evidence Snapshot`.
 
 - `prepare-follow-up` must return `status: routed`, the exact routed basenames, `prepared_plan`, `prepared_review`, `plan_number`, `current_plan_archive_name`, `current_plan_archive_number`, `current_review_archive_name`, `current_review_archive_number`, `plan_log_number`, `review_log_number`, and `gitignore_repair_needed`. It must have executed `finalize-task-routing` in `isolated-reassessment` mode.
 - Verify that the returned current archive names/numbers equal the values derived before preparation, and that `plan_log_number` / `review_log_number` are the post-archive counts embedded in the new review stub for its future archive.
-- Materialize `prepared_plan` only as a temporary candidate outside the repository and run `python3 agent-ops/skills/common/orchestrate-agent-task-loop/scripts/dispatch.py --workspace <workspace> --validate-plan <candidate-plan>`. Require exit code `0` before archiving either active file. The candidate must contain exactly one non-empty `Modified Files Summary` with only exact workspace files. Globs, directories, workspace root, URLs, outside-workspace paths, malformed paths, and placeholders are invalid. Remove the temporary candidate after validation.
+- Before archiving either active file, inspect `prepared_plan` directly. Require one non-empty `Finding Resolution Map` that maps every Required/Suggested id exactly once; every `direct-fix` target appears in `Modified Files Summary`; every `verified-dependency` has the exact task-protocol/current-state proof above; and a planned change or satisfied dependency makes repeated verification meaningful. Reuse the existing review/plan analysis; do not add a separate model pass.
 - If preparation returns `needs_evidence`, collect all named new evidence and rerun after the input changes; never rerun with unchanged evidence. If the evidence cannot be obtained in the current scope, leave the verdict-appended pair in place and report the exact finalization blocker.
-- If preparation returns `blocked` or prepared PLAN validation fails, leave the verdict-appended active PLAN/CODE_REVIEW pair in place, do not check archive/next-state items, and report a resumable finalization blocker. A later code-review invocation resumes this step without appending another verdict.
+- If preparation returns `blocked` or the direct prepared-PLAN check fails, correct the handoff/plan from already collected evidence in the same review pass. If exact new evidence is genuinely required, leave the verdict-appended active PLAN/CODE_REVIEW pair in place, do not check archive/next-state items, and report a resumable internal finalization blocker. A later code-review invocation resumes this step without appending another verdict; this condition is not user review by itself.
+- For `dependency-wait`, keep one `### Finalization State` under the verdict with status, next task, resume condition, and checked state. Do no work while unchanged; when satisfied, mark it resolved with evidence and resume without another verdict.
 
 After the required next state is prepared, archive is mandatory for `PASS`, `WARN`, and `FAIL`. Ensure `.gitignore` has the Agent-Ops managed gitignore block for task artifacts before writing `*.log` outputs. 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`. Apply the repair here when `prepare-follow-up` returned `gitignore_repair_needed: true`.
 
@@ -268,7 +271,7 @@ For `WARN` or `FAIL`, materialize the next state prepared in Step 5 immediately
 - If the user-review gate triggered, write the prepared body to `agent-task/{task_name}/USER_REVIEW.md`. It must use exactly one supported type, `milestone-lock` or `external-execution`, contain every archived loop entry plus the exact required user action or decision, and contain no placeholder. Do not write active PLAN/CODE_REVIEW files or `complete.log`.
 - Otherwise write `prepared_plan` and `prepared_review` byte-for-byte to their routed basenames. Do not rerun, adjust, compare, or upgrade their lane/G after archive.
 - Verify the written follow-up pair contains the predicted archived plan/review paths in identical `Archive Evidence Snapshot` sections and contains no unresolved token from the review-stub template inventory. Unrelated braces in commands or code are allowed.
-- Re-run `python3 agent-ops/skills/common/orchestrate-agent-task-loop/scripts/dispatch.py --workspace <workspace> --validate-plan <written-plan>` and require exit code `0` to confirm that the byte-for-byte materialized PLAN retained the validated write claim.
+- Read the written PLAN once and confirm byte-for-byte materialization retained the checked `Finding Resolution Map` and `Modified Files Summary` invariants.
 - Do not adjust the prepared route after finalization. For a `local-fit` base, `review_rework_count >= 2` or `evidence_integrity_failure=true` must produce `recovery-boundary`; `capability-gap` and `grade-boundary` keep their own basis.
 
 If the task group is `m-<milestone-slug>` and the user-review gate triggered, report that the milestone task is blocked on user review; do not emit PASS completion metadata and do not call `update-roadmap`.
@@ -319,6 +322,8 @@ Report Required/Suggested counts, archive names, the final task archive path for
 
 ## Final Checklist
 
+For `status=blocked`, keep the verdict pair and persist/report blocker, next task, and resume condition. Archive/next-state items below wait until it changes; unchanged dependency state triggers no review work.
+
 - `{current_review_archive_name}` exists with the verdict appended and was derived from the archived active review's own route.
 - `{current_plan_archive_name}` exists and was derived from the archived active plan's own route.
 - `.gitignore` unignores `agent-task/**/*.md` and `agent-task/**/*.log` and ignores local `agent-roadmap/current.md`; generated task artifacts are not ignored by `git check-ignore`.
@@ -328,8 +333,8 @@ Report Required/Suggested counts, archive names, the final task archive path for
 - PASS `complete.log` first line is byte-for-byte identical to the archived PLAN header. An `m-*` log contains non-empty `milestone-task` ids and reports them in completion metadata; a non-milestone log omits the field.
 - PASS does not create `Roadmap Completion` or directly check a Milestone Task. Aggregated evaluation is deferred to `sync-milestone-workstate`.
 - WARN/FAIL without user-review gate: the plan skill was invoked for the exact task path with verified `review_rework_count` and `evidence_integrity_failure`, completed `finalize-task-routing`, and created new active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` files matching the fresh routed output; no `complete.log`.
-- WARN/FAIL prepared PLAN passed `python3 agent-ops/skills/common/orchestrate-agent-task-loop/scripts/dispatch.py --workspace <workspace> --validate-plan <candidate-plan>` before active-pair archive and again after byte-for-byte materialization. Invalid write claims leave the verdict-appended prior pair active.
-- WARN/FAIL follow-up: the plan input omitted prior route fields, revalidated outcome/acceptance/exclusions from current evidence, used the completed in-memory PLAN as the packet, and copied identical `Archive Evidence Snapshot` sections into the new plan/review pair.
+- WARN/FAIL prepared PLAN passed the intrinsic finding-resolution and write-boundary checks before active-pair archive and retained them after byte-for-byte materialization. Invalid resolution or write claims leave the verdict-appended prior pair active.
+- WARN/FAIL follow-up: the plan input omitted prior route fields, revalidated outcome/acceptance/exclusions from current evidence, mapped every stable Required/Suggested id to a direct fix or exact verified dependency, used the completed in-memory PLAN as the packet, and copied identical `Archive Evidence Snapshot` sections into the new plan/review pair.
 - Follow-up plans and review stubs keep implementation agents limited to implementation/test/evidence and contain no implementation-owned user-review request section.
 - USER_REVIEW: `USER_REVIEW.md` exists from template, no active `PLAN-*.md` or `CODE_REVIEW-*.md` remains, and no `complete.log` was written.
 - Review-agent-owned USER_REVIEW: the generated `USER_REVIEW.md` records one supported gate type, the exact Milestone decision or external-execution user action, and evidence that made automatic continuation unsafe.

agent-ops/skills/common/create-skill/SKILL.md

@@ -1,109 +1,116 @@
 ---
 name: create-skill
-version: 1.0.1
-description: 새로운 SKILL.md 파일을 생성하기 위한 범용 스킬
+version: 1.1.0
+description: Create an agent-ops skill with one responsibility, a minimal execution contract, unambiguous English instructions, and correct routing. Use when adding a new common, project, or private SKILL.md.
 ---
 
 # Create Skill
 
-## 목적
+## Purpose
 
-`agent-ops/skills/` 하위에 올바른 형식의 SKILL.md 파일을 생성한다.
-기존 skill-template.md 를 기반으로, 요청 목적에 맞는 내용을 채워 넣는다.
-생성 후 라우팅 항목을 추가한다.
+Create a correctly structured `SKILL.md` under `agent-ops/skills/` from the current skill template, then register its routing entry.
 
-이 스킬은 프로젝트 내부 `agent-ops` 라우터가 읽는 스킬을 만든다.
-`$CODEX_HOME/skills`에 설치되어 Codex가 직접 discover하는 스킬을 만들 때는 시스템 `skill-creator` 규칙을 우선하고, frontmatter는 `name`과 `description`만 사용한다.
+This skill creates skills read by the project-local `agent-ops` router. When creating a Codex-discoverable skill under `$CODEX_HOME/skills`, follow the system `skill-creator` rules instead and use only `name` and `description` in the frontmatter.
 
-### 생성 위치 결정
-- `.agent-ops-source` 파일이 **있으면** (공통 관리 레포): `agent-ops/skills/common/<skill-name>/SKILL.md`
-- `.agent-ops-source` 파일이 **없고** 사용자가 private 또는 operator-local을 명시하면 (타겟 프로젝트): `agent-ops/skills/private/<skill-name>/SKILL.md`
-- `.agent-ops-source` 파일이 **없고** private 요청이 없으면 (타겟 프로젝트): `agent-ops/skills/project/<skill-name>/SKILL.md`
+### Select the creation location
 
-## 언제 호출할지
+- If `.agent-ops-source` exists, create `agent-ops/skills/common/<skill-name>/SKILL.md`.
+- If `.agent-ops-source` does not exist and the user explicitly requests private or operator-local visibility, create `agent-ops/skills/private/<skill-name>/SKILL.md`.
+- If `.agent-ops-source` does not exist and the user does not request private visibility, create `agent-ops/skills/project/<skill-name>/SKILL.md`.
 
-- 새로운 반복 작업 패턴이 생겨 skill로 정의해야 할 때
-- 기존 skill이 없는 작업 유형을 처음 수행하기 전에
-- 사용자가 특정 작업을 skill로 만들어 달라고 요청할 때
+## When to use
 
-## 입력
+- A repeatable task pattern is not covered by an existing skill.
+- The user asks to create a specific skill.
 
-- `skill-name`: 생성할 skill 이름, kebab-case (필수)
-- `purpose`: 이 skill이 해결하는 문제 한 줄 요약 (필수)
-- `visibility`: `common`, `project`, `private` 중 하나. 사용자가 private 또는 operator-local을 명시했을 때만 `private`을 선택한다. (선택)
-- `trigger-cases`: 이 skill을 호출해야 하는 상황 목록 (선택)
+## Inputs
 
-## 먼저 확인할 것
+- `skill-name`: Kebab-case skill name. (required)
+- `purpose`: One-sentence summary of the problem the skill solves. (required)
+- `visibility`: `common`, `project`, or `private`. Select `private` only when the user explicitly requests private or operator-local visibility. (optional)
+- `trigger-cases`: Situations that should invoke the skill. (optional)
 
-- [ ] `agent-ops/skills/common/`, `agent-ops/skills/project/`, `agent-ops/skills/private/` 하위에 동일 이름의 디렉터리가 이미 존재하는지 확인
-- [ ] `agent-ops/skills/common/router.md` 및 `agent-ops/rules/project/rules.md` 에 이미 유사한 라우팅 항목이 있는지 확인
-- [ ] `agent-ops/skills/common/_templates/skill-template.md` 를 읽어 최신 템플릿 형식 파악
+## Preflight
 
-## 실행 절차
+- [ ] Check `agent-ops/skills/common/`, `agent-ops/skills/project/`, and `agent-ops/skills/private/` for an existing directory with the same name.
+- [ ] Check `agent-ops/skills/common/router.md` and `agent-ops/rules/project/rules.md` for equivalent routing or functionality.
+- [ ] Read `agent-ops/skills/common/_templates/skill-template.md` for the current structure.
 
-1. **중복 확인**
-   - 같은 visibility 경로에 이미 있는 skill은 덮어쓰지 않고 중단한다.
-   - private 요청에서 같은 이름의 project skill은 의도된 override 후보이므로 중복으로 중단하지 않는다. common skill과의 같은 이름 또는 다른 기능의 중복은 사용자에게 알리고 중단한다.
-   - private override가 아닌 기능 중복은 사용자에게 알리고 중단한다.
-   - project skill과 같은 이름의 private override는 해당 project skill의 책임을 완전히 대체하는지 확인한다.
+## Procedure
 
-2. **목적 분석**
-   - `purpose` 와 `trigger-cases` 를 바탕으로 아래 항목을 도출한다
-     - 언제 호출할지 (2~4개)
-     - 필요한 입력 파라미터
-     - 사전 확인 항목
-     - 실행 절차 (3~7단계)
-     - 출력 형식
-     - 금지 사항
+1. **Reject unintended duplication**
+   - Stop instead of overwriting a skill in the same visibility path.
+   - For a private request, treat a same-name project skill as a possible intentional override rather than an automatic duplicate. Stop and report a same-name common skill or a functional duplicate.
+   - Confirm that a private override fully replaces the responsibility of its same-name project skill.
 
-3. **SKILL.md 생성**
-   - 경로: 생성 위치 결정 규칙에 따라 `common/`, `project/`, 또는 `private/` 하위에 생성
-   - `skill-template.md` 형식을 따른다
-   - agent-ops 내부 스킬은 기존 로컬 관례에 맞춰 `version`을 둘 수 있다. Codex 설치형 스킬로 배포할 목적이면 `version`이나 `depends` 같은 비표준 frontmatter를 넣지 않는다.
-   - 프로젝트 특화 내용보다 범용 절차를 우선한다
-   - 절차는 구체적이되 지나치게 세부 구현을 기술하지 않는다
+2. **Define one responsibility and its minimum contract**
+   - Select only the representative trigger cases needed to distinguish this skill from existing routes. Do not pad the list to reach a target count.
+   - Define the required procedure and success or failure criteria. Add inputs, preflight checks, an exact output format, or prohibitions only when they change correct execution or verdict determination.
+   - Use the fewest procedure steps that preserve the workflow. Three to seven steps are a guideline for a genuinely multi-stage workflow, not a required count.
+   - Include only contracts required to execute the repeated task and determine success or failure.
+   - Do not add speculative inputs, states, branches, output fields, validation rules, or extension points for unsupported future cases.
+   - Omit a rule that does not change an action, selection, validation result, or failure response. Link to an existing owning rule instead of restating its contract.
+   - Keep exactly one independent responsibility in the skill.
 
-4. **라우팅 업데이트**
-   - `.agent-ops-source` 마커가 **있으면** (공통 관리 레포): `agent-ops/skills/common/router.md`에 라우팅 항목 추가
-   - private skill이 같은 이름의 project skill을 override하면 별도 라우팅 항목을 추가하지 않는다. 공통 규칙의 private 우선순위를 사용한다.
-   - project skill과 짝이 없는 private skill은 `agent-ops/rules/private/rules.md`에만 라우팅 항목을 추가한다. 파일이 없으면 private route만 담은 ignored local rule을 생성한다.
-   - private rule의 trigger는 project router와 중복 등록하지 않는다.
-   - `.agent-ops-source` 마커가 **없고** private skill이 아니면 (타겟 프로젝트): `agent-ops/rules/project/rules.md`의 프로젝트 스킬 라우터 섹션에 라우팅 항목 추가
-   - 기존 공통 스킬을 수정해 trigger가 달라졌다면 새 skill을 만들지 말고 `agent-ops/skills/common/router.md`의 기존 행을 갱신한다
-   - 이 skill이 속할 라우팅 축(구조 분석/코드 변경/흐름 추적 등)을 판단한다
-   - 기존 라우팅 구조를 깨지 않는다
+3. **Write `SKILL.md`**
+   - Create the file under the selected `common/`, `project/`, or `private/` path and follow `skill-template.md`.
+   - Write the frontmatter `description` and Markdown instructions in English.
+   - Use short imperative sentences with one meaning each. State the condition, required action, and verifiable success or failure criterion when they affect execution.
+   - Do not use discretionary terms such as `appropriately`, `if needed`, or `when possible` without a decision criterion.
+   - Keep the procedure specific without encoding unnecessary implementation detail.
+   - Preserve paths, filenames, IDs, commands, regexes, status values, protocol tokens, and other exact literals. User-facing output literals may use the language required by the project.
+   - Agent-ops internal skills may retain the local `version` convention. For Codex-installed skills, do not add nonstandard frontmatter such as `version` or `depends`.
+   - Prefer reusable procedures over project-specific implementation details.
+   - Remove unused optional template sections, authoring comments, and placeholders from the completed skill.
 
-5. **결과 보고**
-   - 생성한 파일 경로
-   - 라우팅 항목을 추가한 파일과 내용
-   - 이 skill이 다루지 않는 범위(필요 시)
+4. **Update routing**
+   - If `.agent-ops-source` exists, add the routing entry to `agent-ops/skills/common/router.md`.
+   - Do not add a separate route when a private skill overrides a same-name project skill; use the common private-precedence rule.
+   - Route a private skill with no project counterpart only from `agent-ops/rules/private/rules.md`. If the file does not exist, create an ignored local rule containing only the private route.
+   - Do not duplicate a private trigger in the project router.
+   - If `.agent-ops-source` does not exist and the skill is not private, add the route to the project skill router section in `agent-ops/rules/project/rules.md`.
+   - If an existing common skill only needs different triggers, update its existing row in `agent-ops/skills/common/router.md` instead of creating another skill.
+   - Select the existing routing axis that matches the skill and preserve the current routing structure.
 
-## 출력 형식
+5. **Report the result**
+   - Report the created file path.
+   - Report the routing file and added entry.
+   - Report excluded scope only when it prevents a likely misunderstanding.
 
-```
+## Validation
+
+- [ ] `agent-ops/skills/{common|project|private}/<skill-name>/SKILL.md` exists.
+- [ ] The skill contains the required purpose, invocation cases, procedure, and validation sections.
+- [ ] Inputs, preflight, output format, and prohibitions are present only when they define a necessary contract.
+- [ ] Every instruction is necessary for execution or verdict determination; no speculative contract remains.
+- [ ] Instructions are concise, single-meaning, and free of discretionary wording without decision criteria.
+- [ ] The frontmatter description and Markdown instructions are in English, except exact literals that must retain another language.
+- [ ] No template authoring comment or unfilled placeholder remains.
+- [ ] The frontmatter has a valid `name` and `description`.
+- [ ] An agent-ops skill follows local frontmatter conventions, while a Codex-installed skill follows the system `skill-creator` frontmatter rules.
+- [ ] A private override takes precedence over its same-name project skill, and only an unmatched private skill is routed from the private rule.
+- If validation fails, report the missing or conflicting item and change only that item.
+
+## Output format
+
+```markdown
 ## 생성 완료
 
 - SKILL 경로: agent-ops/skills/{common|project|private}/<skill-name>/SKILL.md
 - 라우팅 추가: <대상 파일> → <라우팅 축> → <skill-name>
 
 ## 주의사항 (해당 시)
+
 - <이 skill이 다루지 않는 범위 또는 주의할 점>
 ```
 
-## 실행 결과 검증
+## Prohibitions
 
-- [ ] `agent-ops/skills/{common|project|private}/<skill-name>/SKILL.md` 파일이 생성되었는가
-- [ ] 생성된 파일이 `skill-template.md`의 필수 섹션(목적, 언제 호출할지, 실행 절차, 실행 결과 검증, 출력 형식, 금지 사항)을 포함하는가
-- [ ] frontmatter에 name, description이 올바르게 기재되었는가
-- [ ] agent-ops 내부 스킬이면 version 등 로컬 관례를 따르고, Codex 설치형 스킬이면 시스템 `skill-creator` frontmatter 규칙을 따르는가
-- [ ] private override는 동일 이름의 project skill보다 우선되고, 짝이 없는 private skill만 private rule에 라우팅되었는가
-- 검증 실패 시: 누락된 섹션 또는 라우팅 항목을 사용자에게 알리고 해당 부분만 보완한다
-
-## 금지 사항
-
-- private skill 또는 private rule의 내용을 tracked common·project 경로에 복사하지 않는다
-- 이미 존재하는 skill 을 덮어쓰지 않는다
-- 프로젝트 특화 경로(예: `app/screens/`)를 skill 본문에 하드코딩하지 않는다
-- skill 생성과 무관한 코드 파일을 수정하지 않는다
-- 라우팅 대상 파일의 기존 항목을 삭제하거나 재정렬하지 않는다
-- 하나의 skill 에 여러 독립적인 책임을 묶지 않는다
+- Do not copy private skill or private rule content into tracked common or project paths.
+- Do not overwrite an existing skill.
+- Do not hardcode project-specific paths such as `app/screens/` in a reusable skill.
+- Do not modify code unrelated to skill creation.
+- Do not delete or reorder existing routing entries.
+- Do not combine multiple independent responsibilities in one skill.
+- Do not add contracts for hypothetical future requirements.
+- Do not use ambiguous instructions without executable decision criteria.

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

@@ -54,6 +54,7 @@ Filename rules:
 
 Role boundary rules:
 
+- Keep root cause, scope, ownership, and next-state decisions under plan/review, and validate their artifacts directly; dispatcher use is optional. Let implementing agents execute the packet without reinterpreting findings or changing its owner/write boundary.
 - Implementing agents fill implementation-owned `CODE_REVIEW-*-G??.md` sections, keep active files in place, and report ready for review.
 - If implementation cannot continue, implementing agents record the exact blocker, attempted commands/output, and resume condition only in `Verification Results` or `Deviations from Plan` (legacy: `검증 결과` 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.
@@ -200,6 +201,7 @@ Complete all items below before creating active plan/review files. Work through
 - [ ] **Assess test coverage** — for each behavior change, explicitly record whether existing tests cover it.
 - [ ] **Assess split boundaries once** — reconcile request acceptance with source/tests, then split only where every child has a stable contract and independent PASS verification. Otherwise keep the invariant together; do not gather extra evidence solely to lower routing risk.
 - [ ] **Capture recovery signals once** — first-pass uses `review_rework_count=0` and `evidence_integrity_failure=false`. In `prepare-follow-up`, reuse the values already validated and appended by code-review; do not recount verdict history. For another isolated replan, derive them once from the same-task state already loaded for planning, without a routing-only log pass.
+- [ ] **Resolve follow-up findings once** — in `prepare-follow-up`, map every inherited Required/Suggested id. Default repository-fixable work to `direct-fix` with exact root-cause files, overriding stale verification-only exclusions. Allow `verified-dependency` only when an exact active PLAN claims those files and task-protocol ordering applies, or when `complete.log` plus fresh evidence proves the failed precondition is satisfied; vague owners or `complete.log` alone are invalid. Set `ownership_closed=true` only after all mappings are proven. Reject unchanged-precondition verification loops. Reuse the existing analysis; add no model, sub-agent, or routing-only pass.
 - [ ] **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 `Analysis > Split Judgment` (legacy: `분석 결과 > 분할 판단`) and, when order matters, `Dependencies and Execution Order` (legacy: `의존 관계 및 구현 순서`).
 - [ ] **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.
@@ -255,6 +257,7 @@ Required sections:
 - `For the Implementing Agent`: 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`.
 - `Background`: 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.
+- `Finding Resolution Map`: for WARN/FAIL follow-ups only, use one row per Required/Suggested id: mode, exact fix/dependency evidence, and changed/satisfied precondition. Put every `direct-fix` file in `Modified Files Summary`. For an unordered dependency, emit no worker packet; return `status=blocked`, `blocked_reason=dependency-wait`, `next-task`, and resume condition.
 - `Analysis`: 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:
   - `Files Read`: list every source and test file read during analysis, with path. List verification-context source files only when they were actually present and read.
   - `SDD Criteria`: for `SDD: 필요` Milestones, list the SDD path, status, first-line `milestone-task` ids, targeted Acceptance Scenario 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".
@@ -266,13 +269,13 @@ Required sections:
   - `Final Routing`: record `evaluation_mode`, finalizer, both targets' closure/grade/route, `large_indivisible_context`, positive loop-risk names/count, recovery signals, capability-gap evidence, and canonical filenames. Do not include or compare a previous loop's lane/G.
 - `Implementation Checklist`: 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 `- [ ] Fill implementation-owned sections in CODE_REVIEW-*-G??.md with actual implementation notes and verification output.` Copy this checklist into the review stub's `Implementation Checklist` section with the same item text and order.
 - One item per change: `### [TAG-1] Title`, `TAG-2`, etc.
-- `Modified Files Summary`: table mapping files to item ids. This section is the dispatcher's workspace write-claim source of truth.
+- `Modified Files Summary`: table mapping files to item ids. This is the skill-owned implementation write boundary.
   - Include exactly one `## Modified Files Summary` section and at least one exact workspace file path.
   - Wrap every claimed file path in backticks. A bare path cell is invalid.
   - Use repository-relative or canonical absolute file paths. Never use a glob (`*`, `?`, `[]`), directory path, workspace root, URL, path outside the workspace, malformed path, or prose placeholder as a claim.
   - Enumerate only implementer- or reviewer-owned workspace files, including the active review evidence file and deterministic workspace evidence artifacts.
   - For generated verification artifacts, choose deterministic exact workspace filenames or write them under a task-specific temporary directory outside the repository. Never substitute a directory or glob claim for dynamic filenames.
-  - Before writing or returning a prepared pair, validate the rendered PLAN with `python3 agent-ops/skills/common/orchestrate-agent-task-loop/scripts/dispatch.py --workspace <workspace> --validate-plan <candidate-plan>`. A prepared in-memory PLAN may be materialized only as a temporary candidate outside the repository for this validation. Require exit code `0`. On failure, do not write or return the pair.
+  - Before writing or returning a prepared pair, inspect the rendered PLAN itself and confirm this section occurs exactly once, is non-empty, and satisfies every path rule above. For a follow-up, also confirm every `direct-fix` target in `Finding Resolution Map` is present here.
 - `Final Verification`: runnable commands and expected outcome. Prefer commands from verified handoff facts when supplied; fill missing coverage from repository manifests, scripts, workflows, domain rules, and related tests, and record the source in `Analysis > Verification Context`. 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 **"After completing all code changes, fill implementation-owned sections in `CODE_REVIEW-*-G??.md`."**
 
 Each plan item must include:
@@ -345,7 +348,7 @@ Do not write or return a prepared pair when either routing target is not `routed
 ## 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.
-- The rendered PLAN passed `python3 agent-ops/skills/common/orchestrate-agent-task-loop/scripts/dispatch.py --workspace <workspace> --validate-plan <candidate-plan>` before the pair was written or returned. Its single non-empty `Modified Files Summary` contains only exact workspace file claims and no glob or directory claim.
+- The plan skill directly checked the rendered PLAN before the pair was written or returned. Its single non-empty `Modified Files Summary` contains only exact workspace file claims and no glob or directory claim.
 - 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`.
@@ -365,6 +368,7 @@ Do not write or return a prepared pair when either routing target is not `routed
 - The plan and review stub have matching `Implementation Checklist` (legacy: `구현 체크리스트`) item text/order; their final checkbox is the mandatory `CODE_REVIEW-*-G??.md` evidence item.
 - `finalize-task-routing` ran once after the PLAN body was complete, used no routing-only evidence pass, counted only positive packet-local risk, kept capability/grade basis from being relabeled by escalation signals, and produced matching filenames.
 - Review WARN/FAIL follow-ups entered through this plan skill and did not inherit or compare the archived lane/G.
+- Every WARN/FAIL finding has one proven direct fix or ordered/satisfied dependency; only then is ownership closed, and verification does not repeat against an unchanged precondition.
 - 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 `Review-Only Checklist` (legacy: `코드리뷰 전용 체크리스트`) owned only by the review agent.
 - Routed review file completion table lists every plan item.

agent-ops/skills/common/plan/templates/review-stub-template.md

@@ -6,6 +6,7 @@
 > The task is NOT complete until every implementation-owned section below is filled in.
 > Complete the `Implementation Checklist`; the final checklist item is mandatory before saving.
 > Fill implementation-owned sections, then stop with active files in place and report ready for review.
+> Execute the plan's selected root cause, scope, files, and dependency decisions as written. Do not choose another owner, narrow/expand the write boundary, or replace a fix with another verification attempt.
 > If implementation is blocked, record the exact blocker, attempted commands/output, and resume condition only in implementation-owned evidence fields.
 > Do not ask the user directly, present choices, call user-input tools, create control-plane stop files, or classify the next state.
 > Finalization (`Code Review Result`, log rename, `complete.log`, archive moves, `Review-Only Checklist`) is review-agent-only, even after compaction/resume.