@henry1981/nondev-harness-plugin 0.1.0

package/skills/deliverable-review/SKILL.md

@@ -0,0 +1,365 @@
+---
+name: deliverable-review
+description: Use when finishing a document deliverable (law memo, SOP, tech spec, proposal, wiki page, compliance report) before declaring it done, before wrap, or when user says "/deliverable-review", "산출물 검증", "리뷰 돌려", "검증 게이트". Dispatches to a domain-specific reviewer agent for content/spec verification AND humanize-korean voice gate (fast monolith default, strict 5-agent pipeline for medical-device subtypes or explicit --strict).
+---
+
+# Deliverable Review
+
+Domain verification gate for document deliverables. The goal is to catch the failure modes that keep showing up in feedback memory — missed exception clauses, scope creep, unverified assumptions, misattributed specs — **before** HB sees the draft, not after.
+
+This skill is a **dispatcher**. The actual review happens in a reviewer agent. Your job here is: detect document type, pick the right reviewer, hand it the file + context, and format the result.
+
+## Why This Exists
+
+HB's 6-axis harness diagnosis put 검증 (verification) at 5/10 — the thinnest axis. The pattern: doctrine is strong ("Verify Before Done", "Problem Diagnosis First"), but there's no automation for document deliverables, so the same verification failures keep accumulating as `feedback_*.md` entries. This skill closes that loop by turning those feedbacks into an active pre-flight check.
+
+Every run should reduce the probability of a new `feedback_*` entry being written for the same class of mistake.
+
+## When To Trigger
+
+Invoke this skill when any of the following is true:
+- HB explicitly says `/deliverable-review`, "산출물 검증", "리뷰 돌려", "검증 게이트", "검토 돌려"
+- A deliverable file under `drafts/`, `deliverables/`, `compliance/`, `wiki/pages/` was just created or substantially edited, and HB is about to conclude the session
+- The `wrap` skill is running and detects one or more deliverable candidates in the session diff
+- HB is about to send a document to a client, regulator, or stakeholder
+
+Do **not** trigger on:
+- Code files (`.py`, `.ts`, `.js`, …) — those belong to `superpowers:requesting-code-review`
+- Scratch notes, TODO lists, session logs, secall-vault files
+- Commits of reference material into `refs/` or `wiki/sources/`
+
+## Inputs
+
+The skill accepts one of:
+1. **File path** — absolute or relative to repo root. Primary mode.
+2. **Multiple paths** — batch mode, one reviewer call per file.
+3. **No argument** — auto-detect deliverable candidates from `git status` + recent Write/Edit history, then ask HB which to review.
+
+## Dispatch Logic
+
+### Step 1 — Read the file
+
+Use the Read tool on the target path. Grab:
+- Full content (or head 400 lines + tail 100 for very long files)
+- Frontmatter if present
+- File path and parent directory
+
+### Step 2 — Detect type (dispatcher) and subtype
+
+Type detection has **two axes**:
+
+**Axis 1 — Dispatcher type** (which reviewer agent gets called). Apply heuristics in order. First match wins.
+
+**meddev-compliance** if any of:
+- Path contains `compliance/`, `refs/regulations/`, `refs/info-security/`
+- Content mentions 3+ of: 의료기기법, 약사법, 시행령, 시행규칙, 고시, 식약처, MFDS, IEC 62304, ISO 13485, ISO 14971, GMP, QMS, GCP, 약관, 계약서, SOP, TPQQ, audit, HIRA 수가
+- Frontmatter `type: regulation | compliance | sop | legal-memo`
+- File name contains `sop-`, `법규-`, `compliance-`, `audit-`, `contract-`, `계약-`
+
+**spec** if any of:
+- Path contains `drafts/harness-engineering/`, `docs/superpowers/specs/`, `docs/superpowers/plans/`
+- Content mentions 3+ of: API, endpoint, architecture, requirement, user story, acceptance criteria, 아키텍처, 요구사항, 사양, 제안서, RFP, deliverable, milestone, 성과물
+- Frontmatter `type: spec | plan | proposal`
+- File name contains `spec-`, `plan-`, `proposal-`, `제안-`, `사양-`
+
+**general** (fallback) for everything else — wiki entity/concept/synthesis pages, LinkedIn drafts, notes, reports that don't fit the two above.
+
+**Axis 2 — Document subtype** (which checklist rows apply inside the reviewer). Subtype is passed to the reviewer regardless of dispatcher; the reviewer uses it to gate type-specific checklist items.
+
+Detect subtype in this order. First match wins.
+
+| Subtype | Signals |
+|---|---|
+| `entity` | Frontmatter `type: entity`; path `wiki/pages/` + wiki entity shape (헤딩: 인물/회사/발언/사건); filename starts with a proper noun |
+| `concept` | Frontmatter `type: concept`; `wiki/pages/` with concept shape (definition · examples · cross-refs) |
+| `synthesis` | Frontmatter `type: synthesis`; content explicitly crosses 2+ sources and derives a new claim |
+| `comparison` | Frontmatter `type: comparison`; two-column or side-by-side structure comparing frameworks/products/approaches |
+| `SOP` | Filename `sop-`, path `compliance/*/SOP*`, content "표준작업절차" / "Standard Operating Procedure"; frontmatter `type: sop` |
+| `legal-memo` | Filename `legal-`, `법규-`, `법률검토-`; path `compliance/`; content "법률 검토", "Legal Opinion", "법적 쟁점" |
+| `regulation-analysis` | Frontmatter `type: regulation-analysis`; 규정·고시 해석 중심, 조문별 적용 분석 구조. legal-memo와 구분: legal-memo는 사안에 대한 법적 의견, regulation-analysis는 규정 자체의 해석·체계 정리 |
+| `audit-response` | Filename `audit-`, `감사-`, `tpqq-`; content가 질의-응답 쌍 구조, audit 지적 사항 대응 |
+| `contract` | Filename `contract-`, `계약-`, `약관-`; content "제1조", "갑은 을에게", 서명란 |
+| `proposal` | Filename `proposal-`, `제안-`; path `deliverables/*/proposal*`; frontmatter `type: proposal` |
+| `plan` | Frontmatter `type: plan`; `docs/superpowers/plans/`; 단계적 실행 순서·마일스톤·체크포인트 구조. spec과 구분: spec은 "무엇을 만드는가", plan은 "어떤 순서로 만드는가" |
+| `spec` | Frontmatter `type: spec`; content에 acceptance criteria·요구사항·user story 구조 |
+| `architecture` | Filename `arch-`, `architecture-`; 구성도·다이어그램이 핵심이고 본문이 그 해설인 구조. spec과 구분: 요구사항보다 구조 자체가 주제 |
+| `report` | Filename `report-`, `보고서-`, `현황-`; 기간 요약·상태 보고 성격 |
+| `article` | `drafts/linkedin/`, LinkedIn 후보, op-ed·에세이 형식 |
+| `general` | None of the above match — fallback |
+
+When uncertain between two, pick the more specific one and mark confidence `low`.
+
+**Subtype × Source modifier:** if subtype is `entity` or `concept` AND the primary source is a **강연 / 인터뷰 / 팟캐스트 / 영상 STT**, also tag `source:transcript`. This unlocks entity-specific rules around timestamps, STT editing markers, and speaker-time anchoring. Signals for `source:transcript`: frontmatter `sources` entry has `articles/` + audio-derived filename (e.g. `YYYYMMDD-*-강연.md`, `*-interview.md`, `*-transcript.md`), or content contains `(소스 L{line}~{line})` / `(hh:mm)` markers, or source file itself is a transcript.
+
+### Step 3 — Dispatch to reviewer agent
+
+Based on dispatcher type, call the matching agent via the Agent tool:
+
+| Dispatcher type | Agent | `subagent_type` |
+|---|---|---|
+| meddev-compliance | `deliverable-meddev-compliance-reviewer` | (fall back to general-purpose only if the named agent isn't registered yet) |
+| spec | `deliverable-spec-reviewer` | same |
+| general | `deliverable-general-reviewer` | same |
+
+Hand the agent a structured dispatch context:
+
+```
+DELIVERABLE REVIEW DISPATCH
+- path: {{absolute path}}
+- dispatcher_type: meddev-compliance | spec | general
+- subtype: entity | concept | synthesis | comparison | SOP | legal-memo | regulation-analysis | audit-response | contract | proposal | plan | spec | architecture | report | article | general
+- source_modifiers: [source:transcript] (if any)
+- confidence: high | medium | low
+- trigger: manual | wrap | explicit
+- related_docs: [optional paths to RFP, contract, prior spec, source transcript, ...]
+```
+
+The reviewer will gate its static checklist on `subtype` — only rows whose `Type` column matches the detected subtype (or `all`) are active. `source:transcript` unlocks additional transcript-specific rows for entity/concept.
+
+Do **not** pre-filter feedback memory here — the reviewer does that dynamically. The dispatcher only passes the structured context.
+
+### Step 3.5 — Voice gate (humanize-korean)
+
+After the domain reviewer dispatch, run the voice gate against the same file. This catches `rules/content-writing.md` 원칙 위반과 `ai-tell-taxonomy.md` SSOT의 10대 + KHC 고유 K·L 카테고리 패턴.
+
+Mode selection:
+
+| Trigger | Mode | Agent |
+|---|---|---|
+| Default | **fast** | `humanize-monolith` (1 call, 도구 호출 3회 cap, wall-clock 2~3분) |
+| Subtype = `SOP`·`legal-memo`·`regulation-analysis`·`audit-response`·`contract` (의료기기 도메인 산출물) | **strict (auto-promote)** | `ai-tell-detector` → `korean-style-rewriter` → 병렬(`content-fidelity-auditor` + `naturalness-reviewer`) |
+| HB explicit `--strict` or `정밀 모드` | **strict** | same as above |
+| File length > 8,000자 | **strict (auto-promote)** | same |
+
+**Minor revision 예외**: 검토 대상이 *기존 파일의 minor revision*(변경분이 파일 전체 대비 작음)이면 mode 판정 기준을 *파일 전체 길이*가 아니라 *변경분(diff) 크기*로 둔다. 변경분이 8,000자 미만이고 의료기기 도메인 subtype·`--strict`에 해당하지 않으면 fast. 이미 ship된 영역은 voice gate 대상에서 제외하고 변경분만 검토한다 — 파일 전체가 길어도 minor revision의 변경분만 voice gate에 넣는다.
+
+Voice gate dispatch context:
+
+```
+HUMANIZE GATE DISPATCH
+- input_path: {{absolute path of deliverable}}
+- mode: fast | strict
+- genre_hint: 칼럼 | 리포트 | 블로그 | 공적 | null  (auto-detect from subtype)
+- min_severity: S1  (default — voice gate raises only S1; S2+ as info)
+- run_id: cwd 기준 _workspace/{YYYY-MM-DD-NNN}/  (humanize-korean SKILL.md Phase 0 규약 그대로)
+```
+
+The voice gate produces:
+- fast: `final.md` + `<!-- HUMANIZE-SUMMARY -->` 메타블록 (등급 A~D · 카테고리별 탐지 before/after · 자체검증 6항)
+- strict: `02_detection.json` · `03_rewrite.md` · `04_fidelity_audit.json` · `05_naturalness_review.json` · `final.md` · `summary.md`
+
+Voice gate findings는 도메인 reviewer 결과와 별도 섹션으로 Step 4 report에 합산된다. 변경률 30%/50% 가드 위반은 즉시 voice 게이트가 자체 중단·롤백한다.
+
+Do **not** auto-apply voice rewriting to the original deliverable file. Voice gate output(`final.md`)은 *제안*이며 HB가 적용 여부 결정.
+
+### Step 4 — Format the result
+
+The reviewer returns a structured report. Present it to HB as:
+
+```
+## Deliverable Review — {{filename}}
+Reviewer: {{agent_name}}
+Dispatcher type: {{meddev-compliance | spec | general}}
+Subtype: {{entity/SOP/proposal/...}} ({{high/medium/low}})
+Source modifiers: {{none | source:transcript}}
+Trigger: {{manual/wrap/explicit}}
+Feedback memory loaded: {{N}} entries
+Checklist activated / skipped: {{k}} / {{m}} (type-gated)
+Verification types: source_fidelity {{n}} / rule_conformance {{n}} / domain_editorial {{n}} / state_update {{n}} (PRD Verification Layer 라벨링)
+
+### PASS ({{n}})
+- ✅ {{item}}
+
+### WARN ({{n}})
+- ⚠️  {{item}} — {{reason}} [{{evidence_path}}:{{line}}]
+  Related feedback: {{feedback_file}}
+
+### FAIL ({{n}})
+- ❌ {{item}} — {{reason}} [{{evidence_path}}:{{line}}]
+  Related feedback: {{feedback_file}}
+  Suggested fix: {{fix}}
+
+### Voice Gate ({{fast | strict}})
+- 등급: {{A | B | C | D}}
+- 변경률: {{X}}% ({{30%/50% 가드 위반 시 강조}})
+- 카테고리 탐지 (before → after): A {{n→m}} · D {{n→m}} · K {{n→m}} · L {{n→m}} ...
+- 잔존 S1: {{n}}건 / S2: {{n}}건
+- final.md 경로: `_workspace/{{run_id}}/final.md` (제안)
+
+### Recommendation
+{{overall: ship / revise-minor / revise-major / block}}
+
+Domain reviewer 판정과 voice gate 등급을 AND 종합:
+- domain ship + voice A/B → ship
+- domain ship + voice C → revise-minor (voice 2차 윤문 권장)
+- domain ship + voice D → revise-major (voice 잔존 S1 3건+ 또는 과윤문)
+- domain revise/block → 그대로 따름
+
+**동일 영역 판정 충돌 해소** (위 AND 종합 표 전체에 적용 — 특정 행의 부연이 아니다): AND 종합 표는 *등급*의 종합이다. domain reviewer와 voice gate가 *동일 텍스트 영역*에 상반된 판정을 내면(예: 한쪽은 voice 위반, 다른쪽은 정상) domain reviewer 판정을 우선한다. voice gate는 ai-tell 패턴·문체 탐지에 특화돼 있으나, 산출물 voice 규율의 *문맥 예외*(룰 정의 문서 본문 인용 등) 판정은 domain reviewer의 `rules/*` 정합 검증이 더 정확하기 때문이다.
+
+### Candidate feedback to file
+(optional, present only if the reviewer found a new failure pattern)
+
+### Specialization signal
+(optional, present only if the reviewer flags a domain that should graduate into its own specialized reviewer)
+```
+
+Surface WARN items prominently even when FAIL is zero — they're the ones that graduate into `feedback_*.md` next session if ignored. The reviewer may also surface a "subtype auto-detected" note at the top if the dispatcher didn't supply one; pass it through unchanged.
+
+If the reviewer returned no FAIL items, still surface WARN items prominently — they're the ones that graduate into `feedback_*.md` next session if ignored.
+
+### 신호등 분기 (PRD v2.4 §단계 4 정합)
+
+| 신호 | 의미 | 처리 |
+|---|---|---|
+| 녹 | 검증 7 영역 모두 PASS | HB 최종 점검으로 |
+| 황 | Plan 수정 수준의 WARN 1+ | Agent 자체 처리 — **yellow state machine 6 step** (아래) |
+| 적 | PRD 수정 필요 FAIL 1+ 또는 산출물 본질 결함 | HB 확인 루프로 회귀 (Plan 수정 X) |
+
+**yellow state machine 6 step** (codex r5 P2.4 + r8 P1.1 + r10 P2.3 정합 — 조용한 계획 변경 차단 + review_gate 갱신 cap + freshness 전파):
+
+1. 실행 중지
+2. Plan artifact §변경 이력 영역에 revision history row 추가 (yellow trigger·변경 영역 명시)
+3. workflow / 분기 / 앵커 라인 영역 본문 patch
+4. `/deliverable-review target={plan} subtype=plan` 게이트 재호출
+5. **review_gate metadata 갱신** — Plan frontmatter `review_gate` 영역 8 필드 모두 갱신 (status·reviewed_at·reviewer·review_target·review_evidence·closure_note·**reviewed_revision·plan_fingerprint**, codex r10 P2.3 + r11 P1.2 단일 규칙). reviewed_revision 부재 시 *fail-closed* (review_gate 미기록 + review 재호출). status: `block`은 *명시 block recommendation* 영역만 사용 (codex r11 P1.1 — schema enum 정합).
+6. 갱신된 `review_gate`(+ freshness)를 execute-nondev 입력 조건으로 재확인 후 resume (revise-major·block → red 격상, PRD/HB 회귀)
+
+verification_type별 추가 분기:
+- state_update FAIL → 자동 revise-minor 이상
+- source_fidelity FAIL → 자동 revise-major 이상 (GT Drift catch 강화)
+
+### Recommendation ↔ Signal Mapping (codex r6 P2.2 정합)
+
+| Recommendation | Signal | 처리 |
+|---|---|---|
+| ship | green | HB final inspection |
+| revise-minor | yellow | Plan/workflow/deliverable patch 후 재검증 (yellow state machine 6 step) |
+| revise-major | red (default) | PRD/GT/source/regulatory boundary 영향 여부 확인. Plan 수정만으로 닫히는 예외는 reviewer가 근거를 본문에 명시 후 yellow로 낮출 수 있음 |
+| block | red | HB/PRD 회귀 |
+
+**무조건 red 영역** (recommendation과 무관):
+- source_fidelity FAIL — 인용 정확성·원문 대조 실패
+- regulatory correctness FAIL — 법규·SOP·고시 정합 실패
+- explicit HB judgment boundary 침범 — HB 결정 영역 자율 처리
+
+### Signal ↔ Recommendation ↔ review_gate.status 정규화 (codex r8 P2.3)
+
+| Signal | Recommendation | review_gate.status |
+|---|---|---|
+| green | ship | pass |
+| yellow | revise-minor | revise-minor |
+| red | revise-major | revise-major |
+| red | block | block |
+
+**`pass` 영역 조건**: `Signal=green` AND `Recommendation=ship` 시만 `review_gate.status: pass` 기록 (codex r8 P1.2 + P2.3 정합). 다른 조합은 본 status 영역 X.
+
+**예외 영역**: `revise-major`를 Plan-only yellow로 강하 시 reviewer가 본문에 명시 근거 명시 → 재게이트 후 `revise-minor` 또는 `pass`로 기록.
+
+### deliverable-review Output Format (codex r8 P1.2 + r9 P1.2·P2.3 정합 — 확장 schema)
+
+**본 schema는 기존 deliverable-review 기본 report format을 *대체 X, 확장*** (codex r9 P1.2). 기존 필수 섹션은 유지:
+- **PASS** — 항목별 evidence path/line
+- **WARN** — 항목별 evidence + Related feedback
+- **FAIL** — 항목별 evidence + Suggested fix + Related feedback
+- **Recommendation** — ship/revise-minor/revise-major/block
+- **Candidate feedback to file** (신규 패턴 발견 시)
+
+**추가 필수 섹션** (codex r8 P1.2 — 외부 fence four-backtick, codex r9 P2.3 정합):
+
+````markdown
+### Signal
+green | yellow | red
+
+### Signal Mapping Rationale
+- verification_type별 PASS/WARN/FAIL count (source_fidelity·rule_conformance·domain_editorial·state_update)
+- red/yellow 판정 근거 — **WARN/FAIL evidence line 영역 참조 의무** (codex r9 P1.2 — count만 아닌 line-level 근거)
+- 무조건 red 영역(source_fidelity FAIL·regulatory FAIL·HB boundary 침범) trigger 여부
+
+### Review Gate Metadata (subtype=plan only)
+```yaml
+review_gate:
+  status: pass | revise-minor | revise-major | block
+  reviewed_at: {execution_date}
+  reviewer: deliverable-review
+  review_target: {plan path}
+  review_evidence: "inline: §Review Gate" 또는 {review report path}
+  closure_note: ""  # revise-minor 시 본문 필수
+  reviewed_revision: "§변경 이력 row id 또는 version"  # codex r9 P1.1 freshness anchor — required primary
+  plan_fingerprint: "sha256:<canonical-plan-hash>"  # canonical body rule: plan-nondev §3 (r10 P1.2 정의). codex r11 P1.2 — optional diagnostic, 값 존재 시만 비교
+```
+````
+
+**review_gate frontmatter schema 부재 plan**: 검토 대상 plan이 superpowers writing-plans 산출물 등이라 frontmatter에 `review_gate` 필드 자체가 없으면, 위 metadata를 frontmatter에 기록하지 않고 *inline report 본문에만* 반환한다. frontmatter 기록 대상은 plan-nondev 산출 Plan(`review_gate` schema 보유)에 한정한다. 이 경우 report에 "review_gate metadata: inline-only (plan에 review_gate frontmatter schema 부재)"를 명시한다.
+
+## Reviewer Agent Contract
+
+Each `deliverable-*-reviewer` agent must:
+
+1. **Load feedback memory dynamically.** Glob feedback memory — OS 경로 하드코딩 금지, 다음 패턴을 순서대로 시도해 매칭되는 경로 사용: macOS `/Users/*/.claude/projects/*/memory/feedback_*.md` · Linux `/home/*/.claude/projects/*/memory/feedback_*.md` · Windows `C:/Users/*/.claude/projects/*/memory/feedback_*.md`. 세 패턴 모두 0건이면 "feedback memory unavailable"을 보고서 상단에 명시하고 static checklist만으로 진행한다. Filter to verification-relevant entries (those describing a past verification failure, scope error, missed exception, misattribution, or premature conclusion). Read the top 5–15 by relevance.
+
+2. **Merge static + dynamic checklist.** Each agent has a domain-specific static checklist baked into its prompt. Merge it with the dynamic feedback-derived items. Deduplicate.
+
+3. **Walk the file against the checklist.** For each item: PASS / WARN / FAIL with evidence (file line or feedback file path).
+
+4. **Name the feedback source.** Every WARN or FAIL must cite which `feedback_*.md` or which static rule it came from. This is how HB audits the reviewer itself.
+
+5. **Suggest a concrete fix for each FAIL.** Not "revisit this section" — an actual edit direction.
+
+6. **Flag new failure patterns.** If the reviewer notices a failure mode that isn't yet in feedback memory, end the report with `### Candidate feedback to file` — a short entry HB can save as a new `feedback_*.md`.
+
+7. **Verification type 라벨링.** PRD `docs/superpowers/specs/2026-04-29-nondev-harness-prd.md` Verification Layer 계약에 따라, 매 PASS/WARN/FAIL 항목은 다음 4분류 중 하나의 `verification_type`을 갖는다.
+
+   - **`source_fidelity`** — 인용 정확성·원문 대조·출처 명시·법조문/SOP 코드/링크 일치. 예: M1·M2·M3·G1·S2.
+   - **`rule_conformance`** — `rules/*` 문체·voice·금지어·구조·번역체·한영 병기 같은 규율. 예: G15·M12·S9·content-writing.md.
+   - **`domain_editorial`** — 도메인 전문 판정·사실 검증·결론 정합성·acceptance criteria. 예: M5·M6·M7·S6·S10·P6·P7.
+   - **`state_update`** — 상태 환류·`handoff/spec/wiki/lessons` 갱신 누락·status vocabulary 충돌. 예: 산출물이 PRD `next_gate`에 명시된 갱신을 빠뜨렸는지, dogfood Verify가 후속 review로 위임됐는지.
+
+   각 항목은 단일 `verification_type` 1개로 라벨링한다. 모호하면 가장 강한 신호 1개 선택. 정적 체크리스트(G1~G15·M1~M16·P1~P20·S1~S17)는 reviewer 본문에서 verification_type을 노출 가능한 시점에 1회 라벨링하면 충분하다 — 이번 PRD adapter 단계에서는 SKILL.md contract에만 기록한다.
+
+   `state_update` FAIL은 자동 `revise-minor` 이상으로 권고한다. 이는 wrap·다음 세션 진입에서 stale handoff·status vocabulary 충돌로 직결되는 항목이라 단독 선언이 필요하다.
+
+8. **적대적 검토자 페르소나** — agent body는 "이 정도면 괜찮다" default 평가 회로 차단을 위해 *적대적 검토자 페르소나* 적용. 페르소나 본문은 각 reviewer agent body §0 영역에 명시 (Task 5 Step 3).
+
+9. **GT Drift catch 의무** — source_fidelity verification_type 영역의 PASS 표지는 *GT 인용 line·section 단위까지 grep 검증 완료* 후에만 허용. LLM 내장 지식 우선 패턴 차단 (rules/workflow.md §검증 주체 분리 정합).
+
+## Growth Path
+
+The general reviewer is the incubator. When the same failure class recurs 3+ times in general reviewer output, that class should graduate into its own specialized reviewer. HB decides when to split.
+
+Current roster:
+- `deliverable-general-reviewer` — fallback + incubator
+- `deliverable-meddev-compliance-reviewer` — 의료기기·법규·SOP·계약
+- `deliverable-spec-reviewer` — 기술 spec·제안서·아키텍처 문서
+
+Future candidates (do not build until pattern justifies):
+- `deliverable-linkedin-reviewer` — voice/tone check for HB's LinkedIn posts
+- `deliverable-wiki-reviewer` — cross-reference integrity, orphan detection
+
+## Red Flags — STOP and run the full gate
+
+These thoughts mean you're rationalizing your way around the check:
+
+| Thought | Reality |
+|---|---|
+| "This file is small, skip the gate" | Small files are where scope errors hide. The gate takes 60 seconds. |
+| "I already read the source carefully" | Past-HB said that exact sentence before `feedback_law_full_reading` got filed. |
+| "The wrap skill will catch it" | wrap delegates to this skill. There is no other net. |
+| "General reviewer is generic, it won't find anything" | That's a signal to strengthen the general reviewer, not to skip it. |
+| "HB said it's ready, they know best" | HB is the one who built this skill precisely because "ready" has been wrong before. |
+| "The deliverable is in a language the reviewer doesn't handle well" | Then warn about low confidence in the report — don't silently skip. |
+
+**No exceptions. If a file matches the trigger conditions, the gate runs. HB can read a 10-line PASS report in 3 seconds; the cost of skipping is measured in new feedback entries.**
+
+## Failure Handling
+
+If the named reviewer agent is not yet registered in `~/.claude/agents/`:
+1. Warn HB once: "deliverable-{{type}}-reviewer not found, falling back to general-purpose agent with inline instructions"
+2. Pass the same contract (load feedback memory, static + dynamic checklist, evidence-cited output) as an inline prompt to the general-purpose subagent
+3. Note in the final report which reviewer was actually used
+
+If the file path doesn't exist or is empty:
+- Report and stop. Do not fabricate a review.
+
+If feedback memory directory is missing:
+- Proceed with static checklist only and note this degradation at the top of the report.

package/skills/execute-nondev/skill.md

@@ -0,0 +1,226 @@
+---
+name: execute-nondev
+description: Use when proceeding from plan-nondev Plan 6-element output to execution for non-developer deliverables — SOP/QMS/compliance, audit/legal, rule·skill·harness revision, wiki filing/reference curation. Acts as Plan 진행자 (LLM 자율주행 차단) with PRD recap injection per turn, workflow·분기 강 통제, async review mode, and yellow state machine 6-step interrupt handling. Triggers on "execute-nondev", "비개발자 execute", "plan 진행", "execute 단계 진입", "plan 따라 진행". Skip for programming tasks (use superpowers:executing-plans), single-unit tasks (한 줄 수정·파일 1개 cp·메모리 항목 추가 등), or unreviewed Plan (review_gate.status pending → plan-nondev §Step 5 회귀).
+---
+
+# Execute-nondev — 비개발자 작업 Plan 진행자
+
+plan-nondev Plan 6 항목 markdown 본문을 입력으로 받아 Plan 본문 step-by-step 진행한다. 본 스킬은 PRD v2.4 §5 §단계 3 Execute = `execute-nondev` (신규) 매핑 영역의 Plan 진행자 역할이며, LLM 자율주행 차단 + PRD 매 턴 주입 + 외부 검증 회귀 영역의 강제 흐름 보장이다.
+
+## 언제 사용하는가
+
+plan-nondev 통과 + Plan artifact review_gate `status: pass` (또는 `revise-minor` + closure_note 채움) 영역 후:
+
+- Plan 6 항목 schema 완비 (지식 식별·부수 변화·도구·workflow·분기·앵커 라인)
+- Plan frontmatter `review_gate.reviewed_revision` 영역 명시 (freshness primary key)
+- HB 명시 신호 ("이제 execute 가자" 또는 자동 진입 default)
+
+## 언제 사용 금지
+
+- 프로그래밍 작업 (코드 구현·bug fix·리팩토링) → `superpowers:executing-plans`
+- 단건 작업 (검증 단위 1개) → 직접 진행, execute 불필요
+- Plan frontmatter `review_gate.status: pending` 또는 metadata 부재 → plan-nondev §Step 5 회귀 (unreviewed Plan execute 진입 X)
+- Plan frontmatter `review_gate.status: revise-major` 또는 `block` → HB/PRD 회귀 (Plan 수정만으로 진입 X)
+- 의료기기 인허가 도메인 진입 → `medical-device-ra-qa-frame`이 Execute 영역도 흡수
+
+## 전제·의존성
+
+본 스킬 성립 전제 4종. 위반 시 §Step 1 입력 조건 catch 단계에서 fail-closed 실행 중지.
+
+1. **plan-nondev Plan artifact 선행**: 입력 계약은 plan-nondev §Output Format Plan 6 항목 markdown 본문 + frontmatter `review_gate` metadata 8 필드 (reviewed_revision은 required primary key)
+2. **PRD v2 본문 실존**: `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §7 §단계 3 Execute 통제 강도 line 135~145 영역 + §주 영속 결정 line 264 본문 보존 (v2.4 ship 시점 실측 기준)
+3. **deliverable-review 스킬 실존**: yellow state machine Step 4에서 `/deliverable-review target={plan} subtype=plan` 게이트 재호출 의무
+4. **skill-creator 경유 개정**: 본 스킬 수정 시 반드시 `skill-creator` 경유 (rules/workflow.md §스킬 수정)
+
+---
+
+## Workflow — 6 Step
+
+### Step 1 — 입력 조건 catch + freshness 검증
+
+Plan artifact frontmatter `review_gate` metadata 영역 read. mismatch 5 case 점검:
+
+| case | trigger | 처리 |
+|---|---|---|
+| 1 | `status: pending` 또는 metadata 부재 | *fail-closed* 실행 중지. plan-nondev §Step 5 회귀 안내 |
+| 2 | `status: pass` + `reviewed_revision` 명시 | freshness 검증 (아래) PASS 시 Step 2 진입 |
+| 3 | `status: revise-minor` + `closure_note` 채움 | freshness 검증 PASS 시 Step 2 진입 |
+| 4 | `status: revise-minor` + `closure_note` 빈 영역 | *fail-closed* 실행 중지. plan-nondev §Step 5 closure_note 명시 회귀 |
+| 5 | `status: revise-major` 또는 `block` | red 처리. HB/PRD 회귀 (Plan 수정만으로 진입 X — Recommendation Mapping 정합) |
+
+**freshness 검증 단일 규칙** (codex r9 P1.1 + r10 P1.1·P1.2 + r11 P1.2 정합):
+
+- **`reviewed_revision`은 required primary key**:
+  - 부재 → *fail-closed* 실행 중지 + plan-nondev review gate 재호출
+  - Plan §변경 이력 *최신 row id* 또는 version과 mismatch → *fail-closed* 실행 중지 + plan-nondev review gate 재호출
+- **`plan_fingerprint`는 optional diagnostic**:
+  - 값 *부재*만으로는 fail-closed X
+  - 값 *존재* + canonical body hash와 mismatch → fail-closed 실행 중지 + plan-nondev review gate 재호출
+  - canonical body 정의는 plan-nondev §3 schema 영역 참조
+
+### Step 2 — PRD 매 턴 주입 메커니즘 (Context Collapse 대응)
+
+본 스킬 매 응답 시작 시 PRD 요약본 자동 인용. token cost cap ≤ 500 token.
+
+**PRD 요약본 형식**:
+
+```markdown
+**PRD recap** ({PRD path})
+
+- 작업 유형: {PRD §1 도메인 라벨}
+- 작업 목표: {PRD §2 한 줄}
+- GT 자산: {PRD §4 기준 영역 1~2건 path}
+- 산출물 형태/대상: {PRD §5 형태 + 대상}
+- 제약 핵심: {PRD §8 표준 6 범주 중 본 step 영역 trigger 영역}
+
+**검증 신호등** (실행 단계 운영 영역): 녹(ship — 산출물 완료 후보) / 황(yellow state machine 발동 — Step 5) / 적(HB/PRD 회귀 — red 분기) (PRD §7 §단계 4 정합. PRD §9 신호등은 PRD 완성 판단용으로 clarify-nondev 단계 영역, 본 execute 단계 매 응답 recap 영역 X)
+
+**§주 영속 결정**: LLM 자율주행 차단 + 외부 검증 회귀 + 압축 default 폐기 + 박다 어휘 회피 (PRD §주 영역)
+```
+
+본 요약본은 PRD 본문 grep으로 자동 채움. 본문 *전체 인용 X* — 요약본만 (필요 시 본문 grep 영역). token cost 폭증 차단.
+
+### Step 3 — workflow·분기 강 통제 진행
+
+Plan §workflow 본문 step-by-step 진행 의무. *도구 영역만* LLM 자율 허용 — Plan §도구에 영역만 명시, 구체 함수·라이브러리는 LLM 환경 맞춰 선택.
+
+**통제 강도 매트릭스** (PRD §7 §단계 3 정합):
+
+| Plan 항목 | 통제 강도 | 처리 |
+|---|---|---|
+| workflow Step 시퀀스 | **강 통제** | Plan 본문 따르기 강제. 자율 선택 X. 이탈 시 Step 5 yellow state machine 발동 |
+| workflow 실행 boundary 7건 (cwd·write scope·read-only refs·branch·commit·no-touch·external visibility) | **강 통제** | 7건 모두 cap 의무. 보호 경계 침범 시 Step 5 yellow state machine 발동 |
+| 분기 시나리오 | **강 통제** | Plan 본문에 명시된 분기만 처리. 명시 X 변형 발생 시 Step 5 yellow state machine 발동 |
+| 도구 영역 | **자율 허용** | Plan §도구에 영역만 명시 — 예: "docx 생성" → LLM이 docx skill·python-docx·word MCP 중 자율 선택 |
+
+### Step 4 — 비동기 검토 모드
+
+HB 직접 발화 인용: *"내가 마무리하면 diff로 확인하고 납득되지 않는 것만 질문해줘"*.
+
+본 모드는 *매 turn HB 확인 X*. LLM이 Plan §workflow Step 시퀀스 한 묶음 dive 후 HB가 결과를 diff로 검토. 검토 결과는 Step 5 검증 단계 (deliverable-review)와 결합.
+
+**비동기 검토 트리거**:
+- Plan §workflow 한 묶음 closure (예: Step 1·2·3 closure → HB diff 검토 trigger)
+- HB 명시 인터럽트 ("잠깐, X 다시 보자") → Step 5 yellow state machine 발동
+- Plan §workflow 전체 closure → Step 6 검증 단계 진입
+
+### Step 5 — 실행 중 인터럽트 + yellow state machine
+
+Plan workflow·분기 충돌 신호 발생 또는 workflow 실행 boundary 7건 보호 경계 침범 시 즉시 정지 + 황색 신호 보고.
+
+**yellow trigger 케이스** (PRD §7 §단계 3 인터럽트 영역 line 138~144 정합):
+- workflow Step 시퀀스 이탈 (Plan 본문 따르기 자율 선택 발생)
+- workflow 실행 boundary 7건 침범 (cwd·write scope·read-only refs·branch·commit·no-touch·external visibility 영역)
+- 분기 시나리오 명시 X 변형 도달
+- GT 자산 내용 부족 catch
+- 외부 입력 도착 (HB 인터럽트·외부 신호 수령)
+- 기존 분기 처리 미정의 영역 도달
+
+**yellow state machine 6 step** (조용한 계획 변경 차단, codex r5 P2.4 + r8 P1.1 + r10 P2.3 정합):
+
+1. **실행 중지** — 현 step 진행 X
+2. **Plan artifact §변경 이력 영역에 revision history row 추가** — yellow trigger·변경 영역 명시. Plan path는 `{input plan path}` (drafts/{topic}/plans/...md 또는 docs/superpowers/plans/...md 둘 다 영역, codex r6 P3.5 정합)
+3. **변경된 `workflow / 분기 / 앵커 라인` 영역 본문 patch**
+4. **`/deliverable-review target={input plan path} subtype=plan` 게이트 호출**
+5. **review_gate metadata 갱신** (codex r8 P1.1 + r9 P1.1 + r10 P2.3 + r11 P1.2 정합) — Plan frontmatter `review_gate` 영역 8 필드 모두 갱신:
+   - `status`: pass / revise-minor / revise-major / block (Recommendation Mapping 정합)
+   - `reviewed_at`: {execution_date}
+   - `reviewer`: deliverable-review
+   - `review_target`: `{input plan path}`
+   - `review_evidence`: path 또는 "inline: §Review Gate"
+   - `closure_note`: "" (revise-minor 시 본문 필수)
+   - `reviewed_revision`: 본 yellow 시점 §변경 이력 *최신 row id* (codex r10 P1.1 — required primary)
+   - `plan_fingerprint`: 갱신된 Plan 본문의 새 hash (optional diagnostic)
+6. **갱신된 `review_gate`를 Step 1 입력 조건 + freshness 검증으로 재확인 후 resume** (revise-major·block → red, PRD/HB 회귀)
+
+**red 분기는 Plan 수정 X — PRD/HB 회귀로 고정** (PRD §단계 4 검증 신호등 영역 정합).
+
+본 인터럽트는 Step 6 검증 단계의 황·적 분기보다 *시점이 빠르다*. Execute → 검증 → 분기 회귀 경로가 매 turn 대응 가능.
+
+### Step 6 — 다음 흐름 진입 (deliverable-review)
+
+Plan §workflow 전체 closure 후 deliverable-review 게이트 진입.
+
+`/deliverable-review target={Step 4 산출물 경로} subtype={subtype}`.
+
+검증 7 영역 + 신호등 분기 + Recommendation 매핑 결과:
+- 녹 + ship → 산출물 완료 후보 (HB 최종 점검)
+- 황 + revise-minor → Step 5 yellow state machine 발동
+- 적 + revise-major / block → HB/PRD 회귀
+
+---
+
+## Output Format
+
+본 스킬은 직접 산출물 schema 정의 X — Plan §workflow Step 시퀀스 본문이 산출물 schema 영역. 단 Step 5 yellow state machine 발동 시 Plan artifact frontmatter `review_gate` metadata 갱신 영역만 본 스킬 책임.
+
+**review_gate metadata 갱신 schema** (Step 5 본문 영역 답습):
+
+```yaml
+review_gate:
+  status: pass | revise-minor | revise-major | block
+  reviewed_at: YYYY-MM-DD
+  reviewer: deliverable-review
+  review_target: path/to/plan.md
+  review_evidence: path/to/review.md 또는 "inline: §Review Gate"
+  closure_note: "{revise-minor 시 closure 명시}"
+  reviewed_revision: "{§변경 이력 최신 row id 또는 version}"
+  plan_fingerprint: "sha256:<canonical-plan-hash>"  # optional diagnostic
+```
+
+---
+
+## Escape Hatches
+
+4종. 통상 영역 외 즉시 발동.
+
+- **Step 1 입력 조건 fail-closed**: review_gate metadata 부재 또는 `status: pending` 또는 `revise-minor` + closure_note 빈 영역 → 실행 중지 + plan-nondev 회귀 안내
+- **HB 명시 인터럽트**: HB가 "잠깐 X 다시 보자" 신호 → Step 5 yellow state machine 즉시 발동
+- **HB 스킵 신호**: "그냥 바로 진행해" → Step 4 비동기 검토 모드 default. 단 Step 6 deliverable-review 게이트는 의무 (skip X)
+- **red 분기 catch**: Step 5에서 revise-major·block 결과 → red 처리, HB/PRD 회귀 (Plan 수정 X)
+
+---
+
+## Question Quality Pre-Self-Check
+
+본 스킬은 *진행자*라 질문 출력 영역 적음. 단 다음 case에서 질문 출력:
+
+- Step 1 입력 조건 fail-closed → "plan-nondev §Step 5로 회귀할까요?" HB 1줄 선택
+- Step 5 yellow state machine 발동 → "yellow trigger 영역: {trigger}. Plan §workflow / 분기 / 앵커 라인 patch 직접 진행할까요, HB 인터럽트 대기할까요?" HB 1줄 선택
+- Step 6 deliverable-review 결과 적 1+ → "PRD 회귀 영역: {영역}. PRD 명시 신호 대기할까요?" HB 1줄 선택
+
+---
+
+## Red Flags — STOP and check input·freshness
+
+질문 출력·실행 진행 직전 다음 생각이 들면 **STOP**.
+
+| 합리화 | 실제 |
+|---|---|
+| "review_gate metadata 부재해도 실행 진입" | Step 1 fail-closed 위반. unreviewed Plan execute 진입 X |
+| "freshness 검증 부재만으로 fail-closed X" | reviewed_revision 부재는 fail-closed (codex r9 P1.1) |
+| "plan_fingerprint 부재면 fail-closed" | plan_fingerprint는 optional diagnostic — 부재만으로는 fail-closed X (codex r11 P1.2) |
+| "Step 5 yellow trigger 무시하고 진행" | yellow state machine 6 step 의무. 조용한 계획 변경 차단 |
+| "Plan §workflow 명시 외 step 자율 추가" | workflow는 강 통제. 자율 추가 시 yellow state machine 발동 |
+| "revise-major도 Plan patch만으로 진입 가능" | red 분기는 Plan 수정 X — HB/PRD 회귀 고정 |
+| "PRD 매 턴 주입 token cost 부담돼서 skip" | Step 2 의무. PRD 요약본은 ≤ 500 token cap이라 부담 적음. Context Collapse 차단이 본질 |
+
+---
+
+## Rationalization Counters
+
+| 합리화 | 반박 |
+|---|---|
+| "Plan §workflow Step 1·2 같이 dive해서 진행 가속" | 강 통제 위반. workflow Step 시퀀스는 Plan 본문 따르기 강제. 가속 영역은 Step 4 비동기 검토 모드 (한 묶음 dive 후 HB diff)로 처리 |
+| "도구 자율 허용이라 branch·commit도 자율 선택" | 도구 자율 = 함수·라이브러리 자율. branch·commit·write scope·external visibility는 *Plan workflow boundary 7건* 영역이라 강 통제 |
+| "yellow state machine Step 5 review_gate 갱신 skip하고 resume" | Step 5 의무. metadata 갱신 후 Step 1 입력 조건 + freshness 재확인 영역 통과 후에만 resume |
+| "Step 6 deliverable-review 영역 skip 후 직접 ship" | 검증 단계 의무. unreviewed 산출물 ship X (PRD §단계 4 정합) |
+| "PRD 매 턴 주입은 첫 응답에만 적용" | 매 응답 시작 의무. Context Collapse는 매 turn 진행 영역 |
+
+---
+
+## Notes
+
+- **PRD v2.4 매핑**: 본 스킬은 PRD `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §5 §단계 3 Execute = `execute-nondev` (신규) 매핑 영역. PRD §7 §단계 3 통제 강도 line 135~145 + §주 영속 결정 line 264 정의를 본 스킬 출력에 직접 흡수
+- **개정 규율**: 본 스킬 수정 시 반드시 `skill-creator` 경유 (rules/workflow.md §스킬 수정)
+- **dogfood 영역**: 본 스킬 첫 dogfood는 본 cycle Task 5·6 영역 또는 별도 비개발자 작업 진입 시점. plan v1.2 (drafts/nondev-harness/plans/2026-05-14-prd-v2-self-application-plan.md, *Execute 작성 스킬 부재* evidence pack)와 신규 execute-nondev 진행 비교 영역은 별도 dogfood cycle로 carry-forward