Skip to content
Back to skills

Seal Milestone

ASecurity

마일스톤 계획을 최종 검사하고 사용자 승인을 받아 task/feature/milestone을 일괄 ready로 봉인한다. 내용 수정·커밋은 하지 않는다 (ADR-060).

  • 2 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 29, 2026
ai-agentsgobashgit

Security analysis

A100/100

Scanned September 29, 2026

npx -y skills add kohj1018/agentic-dev-harness --skill seal-milestone --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Seal Milestone?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Seal Milestone
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/kohj1018-seal-milestone-agentic-dev-harness/badge)](https://www.skillsdirectory.com/skills/kohj1018-seal-milestone-agentic-dev-harness)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: seal-milestone
description: 마일스톤 계획을 최종 검사하고 사용자 승인을 받아 task/feature/milestone을 일괄 ready로 봉인한다. 내용 수정·커밋은 하지 않는다 (ADR-060).
argument-hint: "<milestone-id>"
disable-model-invocation: true
allowed-tools: Read Glob Grep Edit Bash(rm docs/40-validation/plan-reviews/*.md)
---

이 skill은 **검사 + 사용자 승인 + 상태 전이 전용**이다. 문서 내용을 수정하지 않고, 코드를 건드리지 않으며, 커밋하지 않는다.
**실패 시 어떤 상태도 바꾸지 않고** 어느 조건이 막았는지 보고하며 소유 skill로 반환한다.

봉인이 부여하는 것: M/F/task 계획의 **잠금**. 이 시점부터 계획 변경은 다음 마일스톤(M<N+1>)이 기본이다.
봉인의 목적은 *알려졌거나 합리적으로 발견 가능한 미결정을 최대한 닫는 것*이지 사후 발견을 차단하는 게 아니다 — 봉인 후 새로 드러난 결정은 착수를 막지 않는다(ADR-060 D11).

**Codex**: `.agents/skills/seal-milestone/` wrapper 보유 — `$seal-milestone M1`로 호출한다.

입력:
- `$ARGUMENTS`에 마일스톤 ID `M<N>` 하나만 받는다. 형식은 `M[0-9]+`. 그 외 입력은 안내 후 종료.

반드시 먼저 읽을 파일:
- 입력 `M<N>` 마일스톤 문서 (`## 0. Status`·`## 3`·`## 10`)
- 그 `## 3. 포함되는 기능`이 가리키는 각 feature 문서
- 그 feature들이 소유하는 각 task 문서
- `docs/10-charter/DECISION_REGISTER.md` — **이 M을 `영향:`으로 갖는 항목 + `영향: (미할당)` 항목**만 색인 회수(둘 다 조건 6의 검사 대상이다)
- `docs/40-validation/plan-reviews/` 디렉터리 목록 (파일 본문은 잔존 시에만 읽는다)

## 0단계 — 진입 모드 판정 (정상 / 재개)

승격은 파일 순차 쓰기라 중단될 수 있다. **먼저 모드를 판정한다.**

| 관측 상태 | 모드 |
|-----------|------|
| M `contract-ready` + 산하 feature 전부 `contract-ready` + task 전부 `draft` | **정상 진입** — 조건 1~9 전부 검사 |
| M `contract-ready`이고 feature/task에 `ready`가 섞여 있음 | **재개 진입** — 조건 2~8을 **전 문서에 다시 검사**하고 *상태 쓰기만* 이미 승격된 문서에서 생략한다. **승인은 반드시 다시 받는다**(아래) |
| M `ready` + `- 봉인일:` 미채움 + 그 M에 **구현 흔적 task 0건** | **마이그레이션 진입(계획만 된 프로젝트)** — 조건 2~8을 전수 재검사한 뒤 승인을 받고 receipt를 기록한다 |
| M `ready` + `- 봉인일:` 미채움 + 그 M에 **구현 흔적 task 1건 이상** | **grandfather 진입(이미 구현 중)** — 아래 별도 규칙 |
| M `ready` + `- 봉인일:` 채워짐 + 구현 흔적 task **0건** | **재봉인 진입** — 구현 전 계획 수정 후의 재봉인이다. 조건 2~9를 **전수 재검사**하고 사용자 승인을 다시 받아 **receipt를 갱신(덮어쓰기)**한다. 이미 `ready`인 문서는 *상태 쓰기만* 생략한다(재개 진입과 동일) |
| M `ready` + `- 봉인일:` 채워짐 + 구현 흔적 task **1건 이상** | **이미 봉인됨(구현 중)** — 계획이 잠겼다. 아무것도 바꾸지 않고 종료 |
| M `draft` | `/plan-milestone M<N>` 안내 후 종료 |

**재봉인 진입이 필요한 이유**: `/repair-plan` 2-S는 *봉인됐지만 구현이 0건인* M의 task·매핑·의존성 결함을 그 자리에서 고치고 **본 skill 재실행으로 receipt를 갱신하라고 안내**한다(ADR-060 D6 — 잠금의 실질 기준선은 첫 구현 시작). 재실행을 "이미 봉인됨"으로 즉시 종료하면 그 안내가 **막힌 경로**가 되고, 고친 계획이 무검증·무승인 상태로 남는다. 구현이 시작된 뒤에는 계획이 실제로 잠기므로 그때만 no-op으로 종료한다. 바뀐 게 없는 재실행은 그냥 재검사 후 같은 내용의 receipt를 다시 쓰므로 무해하다.

**구현 흔적 task** = `in-progress` · `blocked` · `done` · `deprecated` 중 하나인 task. `blocked`는 `in-progress`에서만, `deprecated`는 `done`에서만 도달하므로(WORKFLOW 상태 전이 표) 이 4종은 모두 *구현이 시작된 뒤*의 상태다. **`in-progress`/`done`만으로 판정하면** `blocked`만 남은 legacy 마일스톤이 마이그레이션 진입으로 분류돼 조건 2에서 차단되고, receipt가 없어 implement도 거부되는 **교착**이 된다(D12가 없애려던 순환과 동형).

**재개 진입에서는 "전부 draft" 요구를 적용하지 않는다** — 이 예외가 없으면 부분 승격 상태가 영구히 갇힌다. **다만 검사 자체는 전 문서에 다시 돌린다** — 이미 `ready`라는 이유로 검사에서 빼면, 중단 이후 오염되거나 바뀐 문서가 무검증으로 봉인된다.

**재개·재봉인·마이그레이션 진입에서도 사용자 승인을 반드시 다시 받는다.** 승인 증거(receipt)는 모든 상태 변경 *뒤에* 기록되므로, 중단된 실행에서는 승인 사실이 어디에도 영속되지 않는다. "앞선 실행이 승인받았을 것"이라고 가정하면 승인 없는 봉인이 성립한다.

**grandfather 진입 — 이미 구현이 시작된 마일스톤 (ADR-060 D12):**
이 보일러플레이트를 쓰던 프로젝트 중 다수는 M이 `ready`이고 task가 이미 구현 흔적 상태(`in-progress`·`blocked`·`done`·`deprecated`)다. 이 상태에 조건 2("구현 흔적이 있으면 중단")를 적용하면 **seal도 못 하고 implement도 못 하는 순환 교착**이 된다(implement 게이트 ④가 receipt를 요구하므로).
따라서 이 진입에서는:
1. **조건 2를 적용하지 않는다.** 이미 구현이 시작됐으므로 계획 잠금의 실익(구현 전 확정)이 이미 지나갔고, 소급 검사는 무의미하며 진행만 막는다.
2. 조건 6(원장 open)·7(가설)은 **보고만** 하고 차단하지 않는다. 조건 3·4·5는 관측해 receipt에 수치로 남긴다.
3. 사용자에게 **이 마일스톤은 봉인 도입 전에 착수됐고 소급 검사를 하지 않는다**는 사실을 알리고 명시 확인 1회를 받는다.
4. receipt의 첫 줄을 `- 봉인일: <YYYY-MM-DD> (마이그레이션 — 구현 중 착수, 소급 검사 없음)`로 기록한다. **진짜 봉인과 라벨로 구분된다** — 이 라벨이 없으면 사후에 "봉인된 계획"으로 오독된다.
4-b. **receipt의 `Register:` 줄은 실측값으로 쓴다** — 이 진입에서는 조건 6이 보고만 하므로 `open`이 0이 아닐 수 있다. 정상 봉인용 `open 0건` 문구를 그대로 쓰지 말고 `- Register: closed <N>건 / deferred <M>건 / open <K>건 (보고만 — 소급 검사 없음)`으로 기록한다. 0을 적으면 receipt가 검증되지 않은 사실을 검증된 것처럼 주장한다.
5. 이후 마일스톤(M<N+1>)부터는 정상 경로를 탄다.

## 봉인 조건 (하나라도 불충족이면 중단)

순서대로 검사하고, 실패한 첫 항목에서 멈춰 **어느 조건이 왜 막았는지 + 어느 skill로 가야 하는지**를 보고한다.

1. **상태** — 0단계 판정 결과가 **정상 / 재개 / 재봉인 / 마이그레이션 / grandfather** 중 하나일 것(`draft` M과 이미 봉인됨(구현 중) M은 0단계에서 이미 종료됐다).
2. **task 존재·상태** — 마일스톤 `## 3`의 모든 feature가 task를 1개 이상 갖고, *아직 승격되지 않은* task가 전부 `draft`. `in-progress`·`blocked`·`done`·`deprecated`가 있으면 중단(구현이 시작된 흔적). **단 0단계가 grandfather 진입으로 판정했으면 본 조건을 적용하지 않는다**(그 분기의 규칙 1).
3. **task 필수 섹션 완결** — 각 task의 `## 3. 구현 항목`(단계별 가이드), `## 6. Acceptance Criteria`(1개 이상)이 채워졌는가. `## 9. 의존성`은 **섹션이 존재하는지만 본다 — 빈 값은 "선행 의존 없음"이라는 정상 선언이다**(TASK_TEMPLATE `## 9` 정의 / plan-workitem "의존성이 없는 task는 비워둔다"). 빈 값을 미완으로 보면 선행이 없는 첫 task 때문에 모든 마일스톤이 봉인 불가가 된다. 참조가 *적혀 있을 때*의 정합성은 조건 5가 본다. angle-bracket placeholder(`<runner>` 등)만 남은 칸은 미완으로 본다.
3-b. **AC 해석 확정 (implement 착수 게이트 ⑦ 선행 집행)** — 각 task `## 6` AC를 읽어 *구현을 실질적으로 다르게 만드는 2+ 해석*이 가능한 AC가 있으면, 그 task `## 8. 메모`에 `해석 확정: AC-N = <선택>` 기록이 있는지 확인한다. 없으면 중단하고 해석안 1~3개와 영향을 사용자에게 제시해 결정을 받는다. **사용자가 그 자리에서 고르면 본 skill이 예외적으로 그 task `## 8`에 `해석 확정:` 한 줄만 기록하고 검사를 이어간다** — plan-workitem은 완결된 계획에 대해 read-only no-op이라 이 한 줄을 넣어 줄 경로가 없다(내용 수정 금지 원칙의 좁은 예외이며, 사용자가 명시 선택한 문장을 받아 적는 것이다). 사용자가 보류하면 중단한다. **이 검사가 없으면 봉인을 통과한 계획이 첫 구현에서 즉시 halt한다.**
3-c. **TDD opt-out 형식 (게이트 ⑧ 선행)** — 각 task `## 6-2`가 *사유·follow-up 둘 다 있거나 둘 다 없는* 형식인지 확인. 하나만 있으면 중단.
4. **커버리지** — 각 feature `## 7-1` FAC↔AC unmapped 0건. **제3 형식 재확인 (ADR-037#amend-4 결정 4)**: 우변이 `승인 스냅샷 <경로> (manifest: <screen id>)` 인 행마다 (i) 그 경로가 실재하고 (ii) **산하 task `## 3. 구현 항목` 이 지목한 경로에 그 화면 `source[]` 가 없는지** 다시 본다(`## 4-1` 은 구현 시점에 채우는 칸이라 봉인 시점엔 비어 있는 것이 정상이고, `- 승인 UI 재사용:` 은 «재사용» 선언이지 «변경» 선언이 아니다) — 봉인 직전에 그 파일을 건드린 task 가 있으면 봉인을 막고 보고한다(배선이 표현을 바꿨을 수 있고 그때는 AC 가 필요하다). UI feature는 `## 7-3` PX↔AC unmapped 0건 — **`## 7-3` 도 제3 형식을 허용하며 같은 두 조건을 재확인한다**(ADR-037#amend-4 결정 1-b). seam 신호가 발화한 feature는 `## 7-2` INV가 채워지고 unmapped 0건. **UI M은 추가로** — **이 M이 등록한 화면이 있으면** `docs/20-system/prototypes/M<N>/manifest.json` 존재 + 각 화면 `approved.date`·`snapshots[]` 파일 실재. **`product_entry` 확정 경로 (2026-09-12)**: 그 매니페스트에서 **`product_entry: null` 인 화면마다 그것을 확정하는 task line item 이 산하 task 에 있는지** 본다(ADR-072 schema — 「미정이면 `null` + 배선 task line item 이 확정」). 없으면 봉인을 막고 어느 화면이 비었는지 보고한다. **실측(Round 12)**: 3화면 중 2화면(`add-habit`·`admin-habits`)이 `null` 인데 그것을 채우는 line item 이 어느 task 에도 없었고 **봉인이 통과했다** — R7 이 `null` 로 두는 것은 허용되지만 그 조건부를 **아무도 확인하지 않았다**. **`프로토타입 면제:` feature는 대상이 아니고**, `프로토타입:`을 가진 UI feature는 그 id가 가리키는 M(`<screen>`=이 M / `M<K>/<screen>`=이전 M 재사용)의 매니페스트·스냅샷으로 검사한다 — 전 화면이 이전 M 재사용이면 이 M 매니페스트 부재가 정상이다(ADR-072 D9). 부재면 봉인 거부 + «`/design-milestone M<N>`».
5. **의존성 그래프** — task `## 9`의 선행 참조가 (a) 실재하는 task를 가리키고 (b) 순환이 없고 (c) 후행 `## 3`가 전제한 산출이 그 선행 task의 참조 AC에 존재하는가.
6. **결정 원장 (ADR-060 D1/D4)** — 원장에서 이 M을 `영향:`으로 갖는 항목 **및 `영향: (미할당)` 항목**을 회수해 아래를 검사한다. **단 0단계가 grandfather 진입으로 판정했으면 중단하지 않고 보고만 한다**(그 분기의 규칙 2):
   - `status: open`이 **0건**인가. **단 `- 발견: 봉인 후 (M<N>)` 줄이 *이번에 봉인하는 그 M*을 가리키는 항목만 제외한다**(D11 — 다른 M을 가리키는 마커는 제외 사유가 아니다). 1건이라도 남으면 중단하고 그 D-NNN과 `authority`를 보고한다.
   - **`영향: (미할당)` open이 남아 있으면 중단**하고 `/plan-milestone M<N>` R1의 triage를 안내한다(상류 bootstrap에서 등재된 미결정이 배정 없이 새는 것을 막는 지점).
   - `status: deferred` 항목이 전부 **현재 M 무영향 근거 + 이관 앵커 + 회수 시점** 3개를 갖췄는가. 결측이면 `open`으로 간주해 중단한다.
   - `disposition: risk-accepted` 항목이 전부 `authority: user-*`이고 **검증 방법·판정일·중단 기준** 3필드를 갖췄는가.
   - `authority: agent-delegated`인데 되돌리기 비싼 결정(제품 범위·사용자 체감·외부 계약·보안 정책·비가역 약속)을 담고 있고 하향 이력 줄도 없으면 오분류로 보고 중단한다.
   - **`status: closed` + `authority: user-*` 항목의 정본 앵커 대조 (ADR-060 D1 — dogfood Round 9 발견)**: 각 항목의 `정본: <문서#앵커>`를 열어 **그 결정이 실제로 그 위치에 적혀 있는지** 1회 대조한다. 앵커가 가리키는 섹션에 그 결정 내용이 없으면 중단하고 어느 D-NNN이 dangling인지 보고한다(원장은 *위치만* 가리키고 본문은 정본이 SSOT이므로, 앵커가 비면 승인된 결정이 **어느 문서에도 없는 상태**로 봉인된다). 조건부 승인("…하는 조건부")이면 그 조건의 이행 위치까지 본다.
   - **원장 파일이 없으면 silent skip하지 않는다** — 원장은 baseline 산출물이므로 부재는 삭제 또는 구 fork를 뜻한다. 사실을 보고하고 *사용자 명시 확인 1회*를 받은 뒤에만 이 조건을 skip한다(확인 사실은 receipt에 `Register: 파일 부재 — 사용자 확인 후 skip`으로 남긴다).
7. **가설 (ADR-035#amend-3 / ADR-060 D5)** — `docs/10-charter/DISCOVERY.md`가 **존재하면** `## 12. Assumption Tracker`의 미검증 가정 중 **실패 시 이 마일스톤 목표가 무효가 되는 핵심 가설**이 있으면 중단한다. 검증 계획 없는 미검증 가정도 중단. 그 외는 원장에 `risk-accepted`로 등재돼 있으면 통과. **DISCOVERY.md가 없으면(discovery 생략 프로젝트 — PROJECT_START_CHECKLIST 1단계는 선택) 본 조건을 skip하고 사유를 echo한다.** **grandfather 진입에서도 중단하지 않고 보고만 한다**(그 분기의 규칙 2).
8. **리뷰 (opt-in — 차단 조건 아님, 기록 대상)**:
   - **잔존 review 파일 확인**: `docs/40-validation/plan-reviews/`에서 이 M(`M<N>.*.md`) **및 산하 feature/task**(`F-NNN.*.md`·`T-NNN.*.md`) 파일을 회수한다. 잔존 파일이 있으면 각 파일의 `- 판정:` 줄과 finding 목록을 읽어:
     - `NEEDS_CHANGES`이거나 **P0 finding 1건 이상**이거나 **`[seal-blocking]` 태그가 붙은 finding**이 남아 있으면 → 중단하고 `/repair-plan M<N>` 안내.
     - `ALL_GOOD` + P0 0건 + 차단 태그 0건이면 → **통과 판정 후 그 파일을 삭제**한다(리뷰를 돌렸고 문제가 없었던 정상 경우 — `validate-plan`은 ALL_GOOD에도 파일을 만들고 `repair-plan`은 고칠 게 없으면 실행되지 않으므로 파일이 남는 게 정상이다). 삭제 경로를 출력에 echo하고 receipt에 `executed: yes`로 기록한다. **`independence`는 파일에서 알 수 없다**(review 파일 스키마에 `리뷰어 태그`는 있어도 세션 분리 정보는 없다) — 추론하지 말고 이 분기에서도 사용자에게 1회만 묻는다: "그 리뷰는 별도 세션이었습니까? (별도 세션 / 같은 세션)". 답을 그대로 receipt에 적는다.
       > **삭제하는 이유**: `/implement-workitem` 착수 게이트 ⑤가 "미해결 review 파일 없음"을 요구한다. 남겨 두면 봉인 직후 구현이 ⑤에서 막힌다. review 파일은 gitignored ephemeral이므로 삭제는 "내용 수정 금지" 계약에 걸리지 않는다(판정 결과는 receipt에 남는다).
   - **잔존 파일이 없으면 사용자에게 1회 묻는다**: "이 마일스톤 계획을 `/validate-plan`으로 리뷰하셨습니까? (별도 세션 / 같은 세션 / 안 함)". 답을 그대로 receipt에 기록한다. **추론하지 않는다** — repair 결정 이력은 P0/P1만 남고 finding 0건 리뷰는 흔적이 없어 판정 소스가 될 수 없다.
   - **어느 답이든 봉인을 막지 않는다.** "안 함"이면 그 사실을 receipt에 남기고 "봉인 전 리뷰를 권장한다" 1줄을 출력한다.
9. **사용자 최종 승인** — 아래 봉인 요약표를 제시하고 명시 승인을 받는다. 승인 없이 어떤 상태도 쓰지 않는다.

## 봉인 요약표 (사용자 승인 요청 시 출력)

```
봉인 대상: M<N> — <목표 한 줄>

계획       feature <F수>개 / task <T수>개 / AC <AC수>개
완결성     필수 섹션 미완 0 / AC 해석 미확정 0 / TDD 형식 위반 0
커버리지   FAC↔AC unmapped 0 / PX↔AC unmapped 0 / INV unmapped 0
의존성     순환 0 / 미존재 참조 0 / AC-보장 미충족 0
결정 원장  closed <N> / deferred <M> (전원 앵커 보유) / open 0
가설       핵심 가설 미검증 0 / risk-accepted <K>건 (검증계획 보유)
리뷰       executed <yes|no|안 함> / independence <...> / 차단 finding 0

봉인하면 M/F/task 계획이 잠깁니다. 이후 기획 변경은 다음 마일스톤(M<N+1>)이 기본입니다.
승인하시겠습니까? (승인 / 보류 / <항목> 다시 보여줘)
```

## 승격 (승인 후에만)

**순서를 반드시 지킨다 — `task → feature → milestone`.**
M을 마지막에 써야 "M=`ready` ⇒ 하위 전부 `ready`" 불변식이 성립한다. 중간에 끊기면 0단계가 재개 진입으로 인식해 나머지만 승격한다.

1. 산하 모든 task `## 0. Status`: `draft` → `ready`
2. 산하 모든 feature `## 0. Status`: `contract-ready` → `ready`
3. 마일스톤 `## 0. Status`: `contract-ready` → `ready`
4. 마일스톤 `## 10. 봉인 기록`에 seal receipt 기록 (**`- 봉인일:` 줄의 채움이 봉인 완료 표식**이다 — 섹션은 템플릿에 빈 채로 존재하므로 존재 여부로 판정하면 게이트가 상수 통과가 된다):
   ```
   - 봉인일: <YYYY-MM-DD>
   - 승인: 사용자 명시 승인
   - 계획 규모: feature <F수> / task <T수> / AC <AC수>
   - 리뷰: executed <yes|no> | independence <separate-session|same-session(under-verified)|none> | 처리 <P0 N건 / 차단 P1 M건>
   - Register: closed <N>건 / deferred <M>건 / open 0건
   ```

## 하지 않는 것

- 문서 *내용* 수정 (상태값 + `## 10` receipt + 조건 3-b의 `해석 확정:` 한 줄만 쓴다). 그 밖의 내용 결함은 소유 skill(`/plan-milestone`·`/plan-workitem`·`/repair-plan`)로 반환한다.
- git commit·tag (커밋은 사용자가 별도 발화).
- 코드 수정·테스트 실행.
- 조건 미충족 시의 자동 수정·자동 재계획.
- 조건 미충족인데 receipt 기록 (빈·미완 마일스톤에 봉인 도장 금지).

**"실패 시 어떤 상태도 바꾸지 않는다"의 명시 예외 2가지**:
1. **조건 3-b의 `해석 확정:` 기록** — 사용자가 그 자리에서 실제로 내린 결정이므로, 이후 조건에서 BLOCKED되더라도 **유지한다**(되돌리면 사용자 결정이 유실되고 다음 실행이 같은 질문을 반복한다).
2. **조건 8의 ALL_GOOD review 파일 삭제** — 판정 결과가 receipt 대신 출력 echo로 남고, 파일은 ephemeral이다. 뒤 조건에서 BLOCKED되면 receipt가 없으므로 다음 실행이 조건 8을 "잔존 파일 없음"으로 보고 사용자에게 리뷰 수행 여부를 다시 묻는다(정보 손실은 "리뷰를 돌렸다"는 사실 1건이며 재질문으로 복구된다).

그 외에는 실패 시 어떤 상태·문서도 바꾸지 않는다.

## 마지막 출력

- 판정: `SEALED` / `BLOCKED: <조건 번호> <사유>`
- (SEALED) 승격한 문서 수 — task <N> / feature <M> / milestone 1 + receipt 요약 1줄
- (BLOCKED) 막은 조건 + 가야 할 skill 1개
- **변경한 tracked 파일 목록**: 승격한 task·feature·milestone 문서 전부(status 값 + `## 10` 봉인 기록) **+ 조건 3-b의 `해석 확정:`을 기록한 task 문서**(BLOCKED이어도 유지되므로 승격이 0건인 라운드에서도 이 항목은 남는다 — 아래 책임 경계)
- **커밋 안내**: 본 skill은 커밋하지 않는다 — 위 파일을 **사용자가 직접 커밋한 뒤** 다음 단계로 진행한다(commit owner는 사용자/`/finalize-workitem`). 미커밋으로 두면 후속 task의 `/finalize-workitem`이 그 파일을 task `## 4-1` 밖 변경으로 보고 `Needs Review`로 멈춘다.
- 다음 단계:
  ```
  다음 단계:
  - 기본 권장 (SEALED): `/implement-workitem <첫 task-id>` — 의존성 순서상 선행이 없는 task부터.
  - 기본 권장 (BLOCKED): `<막은 조건이 지정한 skill>`
  - 프롬프트 동봉 권장: 원장의 이 M 관련 `deferred` 항목 ID (구현 중 이 범위를 넓히지 않도록)
  ```

## Context 정책 (ADR-019)
`반드시 먼저 읽을 파일`은 *최소 충분*. plan-review 파일 본문은 *잔존 시에만* 읽고, 원장은 `영향:` 색인으로 **이 M 항목 + `(미할당)` 항목**만 회수한다(통독 금지).
정책 근거: [ADR-060](../../../docs/90-decisions/boilerplate/ADR-060-decision-closure-and-milestone-seal.md).

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.