@henry1981/nondev-harness-plugin 0.1.0 → 0.2.1

package/skills/clarify-nondev/skill.md

@@ -1,11 +1,11 @@
 ---
 name: clarify-nondev
-description: Use when starting a non-developer deliverable task requiring PRD authoring before plan/execute/review — SOP/QMS/compliance document, audit/legal response, markdown-body rule·skill·harness revision, or wiki filing/reference curation. Performs task-type judgment, just-in-time context search, and PRD 8-element generation as plan-nondev input. Triggers on "비개발자 작업 시작", "SOP 개정", "법률 메모 작성", "audit 응답", "compliance 검토", "wiki filing", "reference 정리", "규제 질의 답변", "규칙 개정", "스킬 개정", "비개발자 PRD 작성". Skip for programming tasks (use superpowers:brainstorming) or single-unit tasks (한 줄 수정·파일 1개 cp·메모리 항목 추가 등). Medical-device regulatory work enters here and is delegated to medical-device-ra-qa-frame at Step 1 after domain identification.
+description: Use when starting a non-developer deliverable task requiring PRD authoring before plan/execute/review — SOP/QMS/compliance document, audit/legal response, markdown-body rule·skill·harness revision, or wiki filing/reference curation. Performs task-type judgment, just-in-time context search, and PRD 8-element generation as plan-nondev input. Triggers on "비개발자 작업 시작", "SOP 개정", "법률 메모 작성", "audit 응답", "compliance 검토", "wiki filing", "reference 정리", "규제 질의 답변", "규칙 개정", "스킬 개정", "비개발자 PRD 작성". Skip for programming tasks (use superpowers:brainstorming) or single-unit tasks (한 줄 수정·파일 1개 cp·메모리 항목 추가 등).
 ---
 
 # Clarify-nondev — 비개발자 PRD 8 항목 생성기
 
-비개발자 산출물 작업 진입 시 PRD `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §7 §단계 1 정의 8 항목을 채워 plan-nondev 입력으로 넘긴다. 본 스킬은 PRD v2.4 §5 §단계 1 매핑 영역의 PRD 생성기 역할이다.
+비개발자 산출물 작업 진입 시 §단계 1 PRD 8 항목을 채워 plan-nondev 입력으로 넘긴다. 본 스킬은 비개발자 하네스 4단계 흐름(PRD → Plan → Execute → Review) 중 §단계 1(PRD 생성기) 역할이며, PRD 8 항목·완성 판단 신호등 5 항목 정의를 자체 보유한다(§Output Format·§Workflow Step 5).
 
 ## 언제 사용하는가
 
@@ -21,15 +21,12 @@ description: Use when starting a non-developer deliverable task requiring PRD au
 - 프로그래밍 작업 (코드 구현·bug fix·리팩토링) → `superpowers:brainstorming`
 - 단건 작업 (검증 단위 1개, 한 줄 수정·파일 1개 cp·메모리 추가 등) — 직접 진행, PRD 작성 불필요
 
-참고: 의료기기 인허가 특화 작업도 본 스킬로 진입한다. Step 1에서 의료기기 SaMD·허가·임상시험·수가 등 도메인 판정 시 `medical-device-ra-qa-frame`으로 위임되며 본 스킬은 Step 2 진입 없이 종료된다 (§Workflow Step 1 참조).
-
 ## 전제·의존성
 
-본 스킬 성립 전제 3종. 위반 시 아래 Step에서 자산 호출 실패 또는 출력 schema 재작성 필요.
+본 스킬 성립 전제 2종. 위반 시 아래 Step에서 자산 호출 실패 또는 출력 schema 재작성 필요.
 
-1. **PRD v2 본문 실존**: `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` 영역에 §7 §단계 1 PRD 8 항목 정의·§9 신호등 5 항목·§주 영속 결정 본문 보존
-2. **모노레포 자산 실존**: `.claude/agents/narrator.md`·`strategist.md`·`critic.md` + `.claude/skills/medical-device-ra-qa-frame/skill.md` 4건 존재
-3. **plan-nondev 스킬 입력 계약 수락**: 후속 plan-nondev 스킬이 본 스킬 §Output Format PRD 8 항목 markdown 본문을 입력으로 수락. plan-nondev가 다른 형식 요구 시 §Output Format 재작성 필요
+1. **보조 agent 실존**: `critic`·`narrator`·`strategist` 3 agent가 plugin 번들에 동봉돼 Agent tool로 호출 가능 (§Asset Invocation Matrix). 부재 시 해당 Step의 보조 호출만 스킵하고 기본 흐름은 유지
+2. **plan-nondev 스킬 입력 계약 수락**: 후속 plan-nondev 스킬이 본 스킬 §Output Format PRD 8 항목 markdown 본문을 입력으로 수락. plan-nondev가 다른 형식 요구 시 §Output Format 재작성 필요
 
 ---
 
@@ -39,16 +36,14 @@ description: Use when starting a non-developer deliverable task requiring PRD au
 
 ### Step 1 — 작업 타입 판정 + 도메인 라벨 결정
 
-HB 첫 발화 분석 + 작업 타입 + 도메인 라벨 동시 결정.
+사용자 첫 발화 분석 + 작업 타입 + 도메인 라벨 동시 결정.
 
 - **작업 타입 명시 있으면** (예: "SOP 개정 작업", "compliance 검토") → 도메인 라벨 catch 후 Step 2 진입
-- **명시 없으면** 1질문 출력 — "이 작업은 어느 도메인 영역인가요? (예: rwe-vendor-audit / compliance/pasta-singapore-hsa / iso-13485 SOP / 다른 도메인 라벨)"
-
-도메인 라벨은 PRD v2.4 §7 §단계 1 §1 정의 — 분류 코드 (c/f/d/g)가 아닌 도메인 라벨 형태. PRD §단계 1 §1 직접 흡수 영역.
+- **명시 없으면** 1질문 출력 — "이 작업은 어느 도메인 영역인가요? (예: 감사 대응 / 규제 컴플라이언스 검토 / SOP 개정 / 다른 도메인 라벨)"
 
-**의료기기 인허가 도메인 판정 시 위임**: 작업 타입 확정 과정에서 의료기기 SaMD·허가·임상시험·수가·NHT·IFU·품목분류·급여·기술문서·인허가 전략 등 도메인 키워드가 핵심 주제로 판정되면 `medical-device-ra-qa-frame`로 위임 + 본 스킬 Step 2 진입 없이 종료. 위임 후 medical-device-ra-qa-frame이 도메인 frame 주입 + 명확화를 담당한다.
+도메인 라벨은 분류 코드가 아닌 도메인 영역 명칭 형태다 (§Output Format §1 정합).
 
-**혼합 브랜치 처리**: rules/workflow.md §작업 진입 판정 gate 적용:
+**혼합 브랜치 처리**: 핵심 산출물의 1차 형태로 분기한다:
 - 핵심 산출물이 markdown 본문 → 비개발자 규율 (본 스킬 진행)
 - 핵심 산출물이 hook 스크립트·command 스크립트 → 프로그래밍 인접 (본 스킬 중단, `superpowers:brainstorming`으로 위임)
 - 본문이 wiki 페이지·reference 정리 → 비개발자 규율 (본 스킬 진행)
@@ -60,9 +55,9 @@ LLM 자율 호출. 사전 surface 절차 강제 없음 — 아래 3 항목 체
 
 | # | 자문 | 호출 도구 |
 |---|---|---|
-| (a) | HB 첫 발화에 파일명·SOP 코드·DP 번호·도메인 용어 등장했는가? | Grep / Glob |
-| (b) | 작업 타입 기반 자료군 — SOP면 `sop/`·`refs/`·wiki entity / 감사면 `rwe-vendor-audit/`·`audit_QA_Talking_Points` / 규칙·스킬이면 `rules/`·`.claude/skills/` / wiki면 `wiki/sources/` | Glob + Read |
-| (c) | 관련 wiki 페이지·`tasks/lessons.md`·memory 항목·`deliverables/` 선행 사례 | Grep + wiki query |
+| (a) | 사용자 첫 발화에 파일명·SOP 코드·DP 번호·도메인 용어 등장했는가? | Grep / Glob |
+| (b) | 작업 타입 기반 자료군 — SOP면 절차서·규정 디렉토리 / 감사면 audit 대응 자료 / 규칙·스킬이면 rules·skill 디렉토리 / 지식 베이스면 소스 디렉토리 | Glob + Read |
+| (c) | 관련 지식 베이스 페이지·교훈 기록·memory 항목·선행 산출물 사례 | Grep + 지식 베이스 query |
 
 호출 안 해도 되면 스킵. **호출 결과는 Step 3·Step 4의 input**.
 
@@ -77,40 +72,40 @@ PRD 8 항목 전체 작성 진입 전 cutoff 4 조건 모두 충족 여부 catch
 
 4 조건 모두 충족 시 PRD Lite 4 항목 축약본 산출 (작업 유형·작업 목표·산출물·제약). PRD 8 항목 전체 작성 부담 우회. Step 4 PRD 8 항목 채우기 영역 → PRD Lite 4 항목 채우기 영역으로 단축.
 
-**PRD Lite도 생략 X 영역** (HB 명시 정합): repo 변경·외부 발신·규제·법규 판단·source_fidelity 요구 있으면 plan-nondev + execute-nondev + deliverable-review 흐름 생략 X. PRD Lite는 *작성 부담 단축*이지 *후속 흐름 생략*이 아니다.
+**PRD Lite도 생략 X 영역** (사용자 명시 정합): repo 변경·외부 발신·규제·법규 판단·source_fidelity 요구 있으면 plan-nondev + execute-nondev + deliverable-review 흐름 생략 X. PRD Lite는 *작성 부담 단축*이지 *후속 흐름 생략*이 아니다.
 
 cutoff 4 조건 중 1건이라도 X면 Step 4 PRD 8 항목 전체 작성 영역 진입.
 
 ### Step 4 — PRD 8 항목 채우기
 
-PRD v2.4 §7 §단계 1 정의 8 항목을 순차 채움. PRD `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §7 line 98~111 영역 본문 직접 참조 (v2.4 ship 시점 실측 기준).
+§Output Format에 정의된 PRD 8 항목을 순차 채운다.
 
 각 항목 채우기 흐름:
 
 | # | 항목 | 채우기 source | 채우기 영역 |
 |---|---|---|---|
 | 1 | **작업 유형** | Step 1 도메인 라벨 | 도메인 라벨 형태 (분류 코드 X). PRD §7 §1 정합 |
-| 2 | **작업 목표** | HB 첫 발화 + Step 2 검색 | 한 단어·한 줄 압축. 모호 시 PRD 미완성 신호 — Step 5 hb_judgment_required 1라운드로 결정 |
-| 3 | **성공 판단 기준** | HB 첫 발화 + 도메인 amplification | 암묵지→명시지 변환 동반. 상황 논리·정서적 요인 명시. 시간 압박 시 trade-off 우선순위(PRD §3 3-layer — Never sacrifice / Can compress first / Escalate to HB) 인용 |
-| 4 | **지식 요구사항** | Step 2 검색 결과 | 기준(GT, 강제) + 참조(선택, HB 명시 시 추가). GT는 *문서·폴더 경로 단위*까지 (그 아래 줄·섹션은 plan-nondev 영역). 참조는 PRD에서 명시적으로 추가 가능 |
-| 5 | **산출물** | HB 첫 발화 | 형태(필수) + 목적(필수) + 대상(선택, 외부 발신 시 필수). 외부 발신 산출물의 경우 대상의 *특이 성향·필수 키워드·반드시 피해야 할 표현*까지 명시 |
+| 2 | **작업 목표** | 사용자 첫 발화 + Step 2 검색 | 한 단어·한 줄 압축. 모호 시 PRD 미완성 신호 — Step 5 hb_judgment_required 1라운드로 결정 |
+| 3 | **성공 판단 기준** | 사용자 첫 발화 + 도메인 amplification | 암묵지→명시지 변환 동반. 상황 논리·정서적 요인 명시. 시간 압박 시 trade-off 우선순위(PRD §3 3-layer — Never sacrifice / Can compress first / Escalate to 사용자) 인용 |
+| 4 | **지식 요구사항** | Step 2 검색 결과 | 기준(GT, 강제) + 참조(선택, 사용자 명시 시 추가). GT는 *문서·폴더 경로 단위*까지 (그 아래 줄·섹션은 plan-nondev 영역). 참조는 PRD에서 명시적으로 추가 가능 |
+| 5 | **산출물** | 사용자 첫 발화 | 형태(필수) + 목적(필수) + 대상(선택, 외부 발신 시 필수). 외부 발신 산출물의 경우 대상의 *특이 성향·필수 키워드·반드시 피해야 할 표현*까지 명시 |
 | 6 | **산출물 ↔ 참조 연계 역할** | Step 2 검색 결과 + GT 분석 | 본문 직접 인용 / 구조 틀 / 검증 기준 중 어느 역할인지 (3종) |
 | 7 | **스킬 (계획-구현-검증 흐름)** | 도메인 + plan-nondev·execute-nondev·deliverable-review 매핑 | 분량 강제 X, 함축 추구하되 강제 X. 명명된 자산 인용 또는 흐름 풀어 적기 |
-| 8 | **제약** | HB 첫 발화 + Step 2 검색 + 도메인 amplification | 표준 6 범주(시간·범위·형식·과거 결정·외부 의존·도메인 규제) 체크리스트 + 유사 작업 회상 + 암묵지 트리거 질문 세 보조 방법 병행. *불필요한 확장 금지* 영역 (PRD §8 — 미사여구·일반론·작업 노트 어휘 산출물 추가 X) |
+| 8 | **제약** | 사용자 첫 발화 + Step 2 검색 + 도메인 amplification | 표준 6 범주(시간·범위·형식·과거 결정·외부 의존·도메인 규제) 체크리스트 + 유사 작업 회상 + 암묵지 트리거 질문 세 보조 방법 병행. *불필요한 확장 금지* 영역 (PRD §8 — 미사여구·일반론·작업 노트 어휘 산출물 추가 X) |
 
 LLM 자율 채우기 영역 + Step 5에서 hb_judgment_required 영역 catch.
 
 ### Step 5 — 핵심 결정 라운드 + PRD 신호등 self-check
 
-Step 4 PRD 8 항목 채우기 결과를 *PRD 작성 단계 결정 3분류*로 분리 (skill 자체 구조, PRD 원문 명시 X — Step 4·5 반복 round 차단 + HB 개입 영역 cap을 위한 본 skill 내부 보조 분류):
+Step 4 PRD 8 항목 채우기 결과를 *PRD 작성 단계 결정 3분류*로 분리 (skill 자체 구조, PRD 원문 명시 X — Step 4·5 반복 round 차단 + 사용자 개입 영역 cap을 위한 본 skill 내부 보조 분류):
 
-- **confirmed**: HB 첫 발화·문서·이전 세션·PRD에서 이미 닫힌 결정. 본 Step에서 묻지 않고 Step 6 출력에만 반영
+- **confirmed**: 사용자 첫 발화·문서·이전 세션·PRD에서 이미 닫힌 결정. 본 Step에서 묻지 않고 Step 6 출력에만 반영
 - **open**: LLM이 로컬 탐색(Read·Grep·Glob·wiki query) 또는 자율 판단으로 닫을 수 있는 결정. 본 Step에서 LLM이 먼저 닫는다 (질문 출력 X)
 - **hb_judgment_required**: 도메인 판단·정책 결정·되돌리기 어려운 경계(adapter 승격 여부 등). 본 Step에서 §Question Quality Pre-Self-Check 통과 후 1라운드 1질문으로 묻는다
 
 분류 후 hb_judgment_required 0건이면 Step 5 스킵 + PRD 신호등 self-check 영역 진입.
 
-**PRD §9 신호등 5 항목 self-check**: PRD 8 항목 채우기 후 PRD `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §9 line 196~212 영역 5 항목 시뮬레이션 (v2.4 ship 시점 실측 기준):
+**PRD 완성 판단 — 신호등 5 항목 self-check**: PRD 8 항목 채우기 후 다음 5 항목을 시뮬레이션한다:
 
 | # | 항목 | 시뮬레이션 질문 | 신호 |
 |---|---|---|---|
@@ -120,23 +115,23 @@ Step 4 PRD 8 항목 채우기 결과를 *PRD 작성 단계 결정 3분류*로
 | 4 | 계획-구현-검증 흐름 명료성 | 세 단계 흐름이 모호함 없이 정리됐는가? | 녹/황/적 |
 | 5 | 제약 체크리스트 답변 후 추가 없음 | 표준 6 범주 답변 후 추가 항목이 없는가? | 녹/황/적 |
 
-- 전 항목 녹 → Step 6 출력 진입 (PRD §9 원문 "spec/plan 진입" 정합)
-- 황 1+ → HB 보강 후 재평가 (PRD §9 원문) — skill 본문에서 LLM이 Step 4 회귀로 자동 보강 시도 가능하나, 보강 결과는 HB 재평가 의무. PRD §주 "LLM 자율주행 차단" 정합
-- 적 1+ → PRD 미완성 — HB 명시 신호 대기
+- 전 항목 녹 → Step 6 출력 진입
+- 황 1+ → 사용자 보강 후 재평가 — LLM이 Step 4 회귀로 자동 보강 시도 가능하나, 보강 결과는 사용자 재평가 의무 (LLM 자율주행 차단)
+- 적 1+ → PRD 미완성 — 사용자 명시 신호 대기
 
-**최종 보증**: HB 명시 신호("이제 spec/plan 가자") — 신호등이 모호할 때 backstop.
+**최종 보증**: 사용자 명시 신호("이제 spec/plan 가자") — 신호등이 모호할 때 backstop.
 
 라운드 상한 3 (Step 1 + Step 4 보강 + Step 5 합계). 3라운드 초과 시 §Escape Hatches "라운드 상한 도달" 발동.
 
 ### Step 6 — 출력 생성 + 다음 흐름 진입
 
-§Output Format PRD 8 항목 markdown 본문 산출 → HB에게 제시 + 승인 요청 → 승인 후 plan-nondev 진입 (default).
+§Output Format PRD 8 항목 markdown 본문 산출 → 사용자에게 제시 + 승인 요청 → 승인 후 plan-nondev 진입 (default).
 
 ---
 
 ## Output Format — PRD 8 항목 markdown 본문
 
-Step 6 출력. PRD `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §7 §단계 1 본문 형식 답습. 산출 위치는 §산출물 위치 영역 참조.
+Step 6 출력. PRD 8 항목 markdown 본문 형식은 다음과 같다. 산출 위치는 §산출물 위치 영역 참조.
 
 ### Full PRD (8 항목)
 
@@ -167,7 +162,7 @@ related_paths:
 
 - {판단 기준 1}
 - {판단 기준 2}
-- 시간 압박 trade-off 우선순위 — Never sacrifice (source fidelity·regulatory correctness·HB judgment boundaries) / Can compress first (optional polish·nonessential automation·broad research·secondary docs) / Escalate to HB when (Never sacrifice 영역 흔들림 시점)
+- 시간 압박 trade-off 우선순위 — Never sacrifice (source fidelity·regulatory correctness·사용자 judgment boundaries) / Can compress first (optional polish·nonessential automation·broad research·secondary docs) / Escalate to 사용자 when (Never sacrifice 영역 흔들림 시점)
 
 ## 4. 지식 요구사항
 
@@ -215,8 +210,8 @@ related_paths:
 
 **분기 처리** (PRD §9 정합):
 - 전 항목 녹 → plan-nondev 진입 정합
-- 황 1+ → 해당 항목 보강 후 HB 재평가 의무 (LLM 자동 ship X)
-- 적 1+ → PRD 미완성, HB 명시 신호 대기 후 재작성
+- 황 1+ → 해당 항목 보강 후 사용자 재평가 의무 (LLM 자동 ship X)
+- 적 1+ → PRD 미완성, 사용자 명시 신호 대기 후 재작성
 
 ## 10. 본 PRD 변경 이력
 
@@ -265,11 +260,11 @@ prd_lite: true
 
 PRD 산출물 위치는 작업 영역에 따라 분기:
 
-- **PRD가 RWE Vendor Audit·SOP·compliance 도메인** → `{project}/specs/YYYY-MM-DD-{topic}-prd.md` (예: `compliance/pasta-singapore-hsa/specs/2026-05-15-{topic}-prd.md`)
-- **PRD가 비개발자 하네스·rules·skill 영역** → `docs/superpowers/specs/YYYY-MM-DD-{topic}-prd.md`
-- **PRD가 drafts 영역 (실험·아이디어)** → `drafts/{topic}/specs/YYYY-MM-DD-{topic}-prd.md`
+- **도메인 프로젝트 산출물** → 해당 프로젝트의 spec 디렉토리 (예: `{project}/specs/YYYY-MM-DD-{topic}-prd.md`)
+- **규칙·스킬·하네스 개정** → 저장소의 spec·문서 디렉토리
+- **실험·초안 영역** → drafts 디렉토리 (예: `drafts/{topic}/specs/YYYY-MM-DD-{topic}-prd.md`)
 
-frontmatter `related_paths`에 GT 자산 경로·후속 plan/handoff 경로 등록 의무 (KHC `rules/handoff.md` 정합).
+frontmatter `related_paths`에 GT 자산 경로·후속 plan 경로를 등록한다.
 
 ---
 
@@ -284,7 +279,7 @@ PRD Lite는 plan-nondev Lite로 축약 가능하나 *후속 흐름 자체*는
 2. 외부 발신 X
 3. 산출물 생성 X
 4. 기존 문서 조회·단순 답변 영역
-5. HB 명시 승인
+5. 사용자 명시 승인
 
 5 조건 중 1건이라도 X면 plan-nondev 강제 흐름 의무.
 
@@ -294,10 +289,10 @@ PRD Lite는 plan-nondev Lite로 축약 가능하나 *후속 흐름 자체*는
 
 4종. 라운드 상한 도달 이전이어도 조건 만족 시 바로 발동.
 
-- **명확하면 스킵**: HB 첫 발화에 작업 타입 + PRD 8 항목 + 핵심 결정까지 모두 명시 → Step 1~5 전체 스킵, Step 6 바로 진입
-- **라운드 상한 도달 (3라운드)**: "현재까지 명확화된 사항만으로 진행할까요, 아니면 추가 라운드 필요할까요?" HB 1줄 선택
-- **HB 통찰로 결정 축 재정의 요청**: HB가 "이 결정 축 자체가 맞나?" / "이거 더 고민할 요소야" / "잠깐 이 방향 다시 보자" 신호 감지 시 → 즉시 현재 라운드 중단 + 결정 축 재검토 진입
-- **HB 스킵 신호**: "그냥 바로 진행해" / "Clarify 스킵" 신호 → Step 6로 바로 진입, PRD 본문에 "Clarify 생략됨(HB 스킵 요청)" 기록
+- **명확하면 스킵**: 사용자 첫 발화에 작업 타입 + PRD 8 항목 + 핵심 결정까지 모두 명시 → Step 1~5 전체 스킵, Step 6 바로 진입
+- **라운드 상한 도달 (3라운드)**: "현재까지 명확화된 사항만으로 진행할까요, 아니면 추가 라운드 필요할까요?" 사용자 1줄 선택
+- **사용자 통찰로 결정 축 재정의 요청**: 사용자가 "이 결정 축 자체가 맞나?" / "이거 더 고민할 요소야" / "잠깐 이 방향 다시 보자" 신호 감지 시 → 즉시 현재 라운드 중단 + 결정 축 재검토 진입
+- **사용자 스킵 신호**: "그냥 바로 진행해" / "Clarify 스킵" 신호 → Step 6로 바로 진입, PRD 본문에 "Clarify 생략됨(사용자 스킵 요청)" 기록
 
 ---
 
@@ -307,13 +302,10 @@ PRD Lite는 plan-nondev Lite로 축약 가능하나 *후속 흐름 자체*는
 
 | 자산 | 위치 | 호출 규약 | 호출 시점 | 목적 |
 |---|---|---|---|---|
-| `clarify:vague` | `~/.claude/plugins/cache/team-attention-plugins/clarify/2.0.0/skills/vague/SKILL.md` | Skill tool | Step 4·5 요구사항이 계속 애매할 때 | 반복 질문으로 요구사항 구체화 |
-| `clarify:unknown` | 동일 경로 variant `unknown/` | Skill tool | Step 5 전략 blind spot 감지 시 | 4분면 분석으로 숨은 가정 표면화 |
-| `clarify:metamedium` | 동일 경로 variant `metamedium/` | Skill tool | Step 1~5 "내용 vs 형식" 재검토 신호 시 | 작업 형식 자체 재정의 |
-| `narrator` | `.claude/agents/narrator.md` | Agent tool `subagent_type: narrator` | Step 6 출력 직전 | HB에게 현재 진행도·전체 맥락 설명 |
-| `strategist` | `.claude/agents/strategist.md` | Agent tool `subagent_type: strategist` | Step 5 분기 시점 대안 필요 시 | 현재 접근 외 대안 + 트레이드오프 |
-| `critic` | `.claude/agents/critic.md` | Agent tool `subagent_type: critic` | Step 5 권장안 확정 직전 | Devil's advocate로 약점·리스크 점검 |
-| `medical-device-ra-qa-frame` | `.claude/skills/medical-device-ra-qa-frame/skill.md` | Skill tool | Step 1 결과 의료기기 인허가 도메인 판정 시 | 하위 도메인 스킬로 위임, 본 스킬 종료 |
+| `narrator` | `${CLAUDE_PLUGIN_ROOT}/agents/narrator.md` (plugin 번들) | Agent tool `subagent_type: narrator` | Step 6 출력 직전 | 사용자에게 현재 진행도·전체 맥락 설명 |
+| `strategist` | `${CLAUDE_PLUGIN_ROOT}/agents/strategist.md` (plugin 번들) | Agent tool `subagent_type: strategist` | Step 5 분기 시점 대안 필요 시 | 현재 접근 외 대안 + 트레이드오프 |
+| `critic` | `${CLAUDE_PLUGIN_ROOT}/agents/critic.md` (plugin 번들) | Agent tool `subagent_type: critic` | Step 5 권장안 확정 직전 | Devil's advocate로 약점·리스크 점검 |
+| `clarify` plugin (vague·unknown·metamedium) | 외부 clarify plugin (설치 시) | Skill tool | Step 4·5 요구사항 애매 / 전략 blind spot / 내용 vs 형식 재검토 시 | 반복 질문·4분면 분석·형식 재정의 — 미설치 시 LLM 직접 처리로 대체 |
 
 ---
 
@@ -329,8 +321,8 @@ PRD Lite는 plan-nondev Lite로 축약 가능하나 *후속 흐름 자체*는
 ### 체크 2 — 로컬 탐색 선행
 
 - 이 질문의 답을 Read·Glob·Grep·wiki query로 LLM이 직접 확인 가능한가?
-- 가능하면 **먼저 탐색** → 탐색 결과 바탕으로 질문 재평가 → 여전히 HB 판단 필요 시에만 질문 출력
-- "로컬 탐색 없이 추정 질문"은 HB 명시 안티패턴. 위반 시 HB 리뷰 흐름 붕괴
+- 가능하면 **먼저 탐색** → 탐색 결과 바탕으로 질문 재평가 → 여전히 사용자 판단 필요 시에만 질문 출력
+- "로컬 탐색 없이 추정 질문"은 사용자 명시 안티패턴. 위반 시 사용자 리뷰 흐름 붕괴
 
 ### 체크 3 — 1라운드 1질문 원칙
 
@@ -353,11 +345,11 @@ PRD Lite는 plan-nondev Lite로 축약 가능하나 *후속 흐름 자체*는
 
 | 합리화 | 실제 |
 |---|---|
-| "HB에게 일단 물어보는 게 빠르다" | 탐색 가능한 정보를 묻는 건 HB 시간 낭비 + 추정 기반 응답 유도 |
+| "사용자에게 일단 물어보는 게 빠르다" | 탐색 가능한 정보를 묻는 건 사용자 시간 낭비 + 추정 기반 응답 유도 |
 | "여러 가능성 다 물어보자" | 체크 3 위반. 1라운드 1질문 원칙 |
 | "이 질문은 필수는 아니지만..." | 체크 1 실패 신호. 본질무관이면 출력 금지 |
-| "HB가 알려주지 않으면 어차피 진행 못 해" | 진짜 그런지 검증해라 — 대부분 LLM이 로컬 탐색으로 해소 가능 |
-| "이 정도는 가볍게 물어봐도..." | "가볍게"가 HB 리뷰 흐름을 깨는 주원인 |
+| "사용자가 알려주지 않으면 어차피 진행 못 해" | 진짜 그런지 검증해라 — 대부분 LLM이 로컬 탐색으로 해소 가능 |
+| "이 정도는 가볍게 물어봐도..." | "가볍게"가 사용자 리뷰 흐름을 깨는 주원인 |
 
 ---
 
@@ -366,17 +358,16 @@ PRD Lite는 plan-nondev Lite로 축약 가능하나 *후속 흐름 자체*는
 | 합리화 | 반박 |
 |---|---|
 | "Step 2 자율이라고 했으니 탐색 안 해도 된다" | 자율 = 필요 판단은 자율, 필요하면 무조건 호출. "호출 안 함" default 아님 |
-| "HB가 작업 타입 명시했으니 Step 1 스킵" | 맞다. Step 2·3·4·5는 여전히 진행 — 판단 조기 종료 금지 |
+| "사용자가 작업 타입 명시했으니 Step 1 스킵" | 맞다. Step 2·3·4·5는 여전히 진행 — 판단 조기 종료 금지 |
 | "PRD 8 항목 중 1~2개는 생략해도 된다" | plan-nondev 입력 계약 위반. 해당 없으면 명시적 "해당 없음" 표기 |
 | "PRD Lite cutoff 4 조건 중 3건만 충족해도 Lite 적용" | cutoff 4 조건 모두 충족 시만 Lite. 1건이라도 X면 PRD 8 항목 전체 작성 |
 | "PRD Lite는 후속 흐름도 생략 가능" | Lite는 *작성 부담 단축*이지 *후속 흐름 생략* X. plan-nondev + execute-nondev + deliverable-review 흐름은 그대로 |
-| "라운드 상한 넘어도 한 번만 더..." | 상한 도달 시 escape hatch 발동이 규율. 연장은 HB 명시 승인 후에만 |
+| "라운드 상한 넘어도 한 번만 더..." | 상한 도달 시 escape hatch 발동이 규율. 연장은 사용자 명시 승인 후에만 |
 | "PRD 신호등 황 1건은 무시해도 된다" | 황 1+ → Step 4 회귀 의무. 신호등 우회는 PRD 미완성 ship으로 직결 |
 
 ---
 
 ## Notes
 
-- **PRD v2.4 매핑**: 본 스킬은 PRD `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §5 §단계 1 PRD = `clarify-nondev` (개정) 매핑 영역. PRD §7 §단계 1 8 항목 + §9 신호등 5 항목 정의를 본 스킬 출력에 직접 흡수
-- **개정 규율**: 본 스킬 수정 시 반드시 `skill-creator` 경유 (rules/workflow.md §스킬 수정)
-- **dogfood 영역**: 본 스킬 자체가 *비개발자 하네스 PRD 작성기*라 첫 dogfood는 비개발자 작업 진입 시점. 본 cycle (plan v2.12 Task 7 E2E smoke test)에서 4 skill 연계 dogfood 진행
+- **하네스 내 위치**: 본 스킬은 비개발자 하네스 4단계 중 §단계 1(PRD) 생성기다. PRD 8 항목 + 완성 판단 신호등 5 항목 정의를 자체 보유한다.
+- **개정 규율**: 본 스킬 수정 시 skill-creator 경유.

package/skills/deliverable-review/SKILL.md

@@ -5,23 +5,23 @@ description: Use when finishing a document deliverable (law memo, SOP, tech spec
 
 # 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.
+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** the user 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.
+Verification is the thinnest axis of most document workflows: doctrine is strong ("verify before done", "diagnose the problem first"), but there is no automation for document deliverables, so the same verification failures keep recurring. This skill closes that loop by turning recorded feedback 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.
+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 user explicitly says `/deliverable-review`, "산출물 검증", "리뷰 돌려", "검증 게이트", "검토 돌려"
+- A deliverable file under `drafts/`, `deliverables/`, `compliance/`, `wiki/pages/` was just created or substantially edited, and the user 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
+- the user 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`
@@ -33,7 +33,7 @@ Do **not** trigger on:
 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.
+3. **No argument** — auto-detect deliverable candidates from `git status` + recent Write/Edit history, then ask the user which to review.
 
 ## Dispatch Logic
 
@@ -57,7 +57,7 @@ Type detection has **two axes**:
 - File name contains `sop-`, `법규-`, `compliance-`, `audit-`, `contract-`, `계약-`
 
 **spec** if any of:
-- Path contains `drafts/harness-engineering/`, `docs/superpowers/specs/`, `docs/superpowers/plans/`
+- Path contains `specs/`, `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-`, `제안-`, `사양-`
@@ -80,7 +80,7 @@ Detect subtype in this order. First match wins.
 | `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은 "어떤 순서로 만드는가" |
+| `plan` | Frontmatter `type: plan`; path `plans/`; 단계적 실행 순서·마일스톤·체크포인트 구조. spec과 구분: spec은 "무엇을 만드는가", plan은 "어떤 순서로 만드는가" |
 | `spec` | Frontmatter `type: spec`; content에 acceptance criteria·요구사항·user story 구조 |
 | `architecture` | Filename `arch-`, `architecture-`; 구성도·다이어그램이 핵심이고 본문이 그 해설인 구조. spec과 구분: 요구사항보다 구조 자체가 주제 |
 | `report` | Filename `report-`, `보고서-`, `현황-`; 기간 요약·상태 보고 성격 |
@@ -120,15 +120,17 @@ Do **not** pre-filter feedback memory here — the reviewer does that dynamicall
 
 ### 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 카테고리 패턴.
+After the domain reviewer dispatch, run the voice gate against the same file. This catches 문체·voice 원칙 위반과 ai-tell 문체 패턴.
+
+**자산 가용성 — peer-dependency (standalone)**: voice gate는 `humanize-korean` voice 자산(`humanize-monolith`·`ai-tell-detector` 등)에 대한 peer-dependency다 — 이 자산은 본 플러그인에 번들되지 않으며, 설치된 환경에서만 작동한다. 판정은 *reactive*로 한다: voice gate agent 디스패치를 시도하고, 미등록(unknown subagent_type 등)으로 실패하면 본 Step 3.5를 건너뛴 것으로 처리한다 — 사전에 설치 여부를 별도 점검하지 않는다. skip 시 Step 4로 진행하며, report의 Voice Gate 섹션에 "voice 자산 미설치 — domain reviewer 결과만 반영"을 명시하고, Step 4 Recommendation 종합은 domain reviewer 판정만으로 결정한다.
 
 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 |
+| Subtype = `SOP`·`legal-memo`·`regulation-analysis`·`audit-response`·`contract` (법규·계약·SOP 도메인 산출물) | **strict (auto-promote)** | `ai-tell-detector` → `korean-style-rewriter` → 병렬(`content-fidelity-auditor` + `naturalness-reviewer`) |
+| User 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에 넣는다.
@@ -150,11 +152,11 @@ The voice gate produces:
 
 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가 적용 여부 결정.
+Do **not** auto-apply voice rewriting to the original deliverable file. Voice gate output(`final.md`)은 *제안*이며 사용자가 적용 여부 결정.
 
 ### Step 4 — Format the result
 
-The reviewer returns a structured report. Present it to HB as:
+The reviewer returns a structured report. Present it to the user as:
 
 ```
 ## Deliverable Review — {{filename}}
@@ -195,7 +197,7 @@ Domain reviewer 판정과 voice gate 등급을 AND 종합:
 - 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/*` 정합 검증이 더 정확하기 때문이다.
+**동일 영역 판정 충돌 해소** (위 AND 종합 표 전체에 적용 — 특정 행의 부연이 아니다): AND 종합 표는 *등급*의 종합이다. domain reviewer와 voice gate가 *동일 텍스트 영역*에 상반된 판정을 내면(예: 한쪽은 voice 위반, 다른쪽은 정상) domain reviewer 판정을 우선한다. voice gate는 ai-tell 패턴·문체 탐지에 특화돼 있으나, 산출물 voice 규율의 *문맥 예외*(룰 정의 문서 본문 인용 등) 판정은 domain reviewer의 프로젝트 룰 정합 검증이 더 정확하기 때문이다.
 
 ### Candidate feedback to file
 (optional, present only if the reviewer found a new failure pattern)
@@ -208,42 +210,42 @@ Surface WARN items prominently even when FAIL is zero — they're the ones that
 
 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 정합)
+### 신호등 분기 (PRD §단계 4 정합)
 
 | 신호 | 의미 | 처리 |
 |---|---|---|
-| 녹 | 검증 7 영역 모두 PASS | HB 최종 점검으로 |
+| 녹 | 검증 7 영역 모두 PASS | 사용자 최종 점검으로 |
 | 황 | Plan 수정 수준의 WARN 1+ | Agent 자체 처리 — **yellow state machine 6 step** (아래) |
-| 적 | PRD 수정 필요 FAIL 1+ 또는 산출물 본질 결함 | HB 확인 루프로 회귀 (Plan 수정 X) |
+| 적 | PRD 수정 필요 FAIL 1+ 또는 산출물 본질 결함 | 사용자 확인 루프로 회귀 (Plan 수정 X) |
 
-**yellow state machine 6 step** (codex r5 P2.4 + r8 P1.1 + r10 P2.3 정합 — 조용한 계획 변경 차단 + review_gate 갱신 cap + freshness 전파):
+**yellow state machine 6 step** (조용한 계획 변경 차단 + 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 회귀)
+5. **review_gate metadata 갱신** — Plan frontmatter `review_gate` 영역 8 필드 모두 갱신 (status·reviewed_at·reviewer·review_target·review_evidence·closure_note·**reviewed_revision·plan_fingerprint**, 단일 규칙). reviewed_revision 부재 시 *fail-closed* (review_gate 미기록 + review 재호출). status: `block`은 *명시 block recommendation* 영역만 사용 (schema enum 정합).
+6. 갱신된 `review_gate`(+ freshness)를 execute-nondev 입력 조건으로 재확인 후 resume (revise-major·block → red 격상, PRD/사용자 회귀)
 
 verification_type별 추가 분기:
 - state_update FAIL → 자동 revise-minor 이상
 - source_fidelity FAIL → 자동 revise-major 이상 (GT Drift catch 강화)
 
-### Recommendation ↔ Signal Mapping (codex r6 P2.2 정합)
+### Recommendation ↔ Signal Mapping
 
 | Recommendation | Signal | 처리 |
 |---|---|---|
-| ship | green | HB final inspection |
+| ship | green | User 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 회귀 |
+| block | red | 사용자/PRD 회귀 |
 
 **무조건 red 영역** (recommendation과 무관):
 - source_fidelity FAIL — 인용 정확성·원문 대조 실패
 - regulatory correctness FAIL — 법규·SOP·고시 정합 실패
-- explicit HB judgment boundary 침범 — HB 결정 영역 자율 처리
+- explicit 사용자 judgment boundary 침범 — 사용자 결정 영역 자율 처리
 
-### Signal ↔ Recommendation ↔ review_gate.status 정규화 (codex r8 P2.3)
+### Signal ↔ Recommendation ↔ review_gate.status 정규화
 
 | Signal | Recommendation | review_gate.status |
 |---|---|---|
@@ -252,20 +254,20 @@ verification_type별 추가 분기:
 | 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.
+**`pass` 영역 조건**: `Signal=green` AND `Recommendation=ship` 시만 `review_gate.status: pass` 기록. 다른 조합은 본 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)
+### deliverable-review Output Format (확장 schema)
 
-**본 schema는 기존 deliverable-review 기본 report format을 *대체 X, 확장*** (codex r9 P1.2). 기존 필수 섹션은 유지:
+**본 schema는 기존 deliverable-review 기본 report format을 *대체 X, 확장***. 기존 필수 섹션은 유지:
 - **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 정합):
+**추가 필수 섹션** (외부 fence four-backtick):
 
 ````markdown
 ### Signal
@@ -273,8 +275,8 @@ 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 여부
+- red/yellow 판정 근거 — **WARN/FAIL evidence line 영역 참조 의무** (count만 아닌 line-level 근거)
+- 무조건 red 영역(source_fidelity FAIL·regulatory FAIL·사용자 boundary 침범) trigger 여부
 
 ### Review Gate Metadata (subtype=plan only)
 ```yaml
@@ -285,8 +287,8 @@ review_gate:
   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, 값 존재 시만 비교
+  reviewed_revision: "§변경 이력 row id 또는 version"  # freshness anchor — required primary
+  plan_fingerprint: "sha256:<canonical-plan-hash>"  # canonical body rule: plan-nondev §3. optional diagnostic, 값 존재 시만 비교
 ```
 ````
 
@@ -302,30 +304,30 @@ Each `deliverable-*-reviewer` agent must:
 
 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.
+4. **Name the feedback source.** Every WARN or FAIL must cite which `feedback_*.md` or which static rule it came from. This is how the user 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`.
+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 the user 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`을 갖는다.
+7. **Verification type 라벨링.** 매 PASS/WARN/FAIL 항목은 다음 4분류 중 하나의 `verification_type`을 갖는다.
 
    - **`source_fidelity`** — 인용 정확성·원문 대조·출처 명시·법조문/SOP 코드/링크 일치. 예: M1·M2·M3·G1·S2.
-   - **`rule_conformance`** — `rules/*` 문체·voice·금지어·구조·번역체·한영 병기 같은 규율. 예: G15·M12·S9·content-writing.md.
+   - **`rule_conformance`** — 프로젝트 룰(문체·voice·금지어·구조·번역체·병기) 같은 규율. 예: G15·M12·S9.
    - **`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로 위임됐는지.
+   - **`state_update`** — 상태 환류·후속 문서(handoff·spec·index 등) 갱신 누락·status vocabulary 충돌. 예: 산출물이 명시된 후속 갱신 의무를 빠뜨렸는지, 검증이 후속 review로 위임됐는지.
 
-   각 항목은 단일 `verification_type` 1개로 라벨링한다. 모호하면 가장 강한 신호 1개 선택. 정적 체크리스트(G1~G15·M1~M16·P1~P20·S1~S17)는 reviewer 본문에서 verification_type을 노출 가능한 시점에 1회 라벨링하면 충분하다 — 이번 PRD adapter 단계에서는 SKILL.md contract에만 기록한다.
+   각 항목은 단일 `verification_type` 1개로 라벨링한다. 모호하면 가장 강한 신호 1개 선택. 정적 체크리스트(G1~G15·M1~M16·P1~P20·S1~S17)는 reviewer 본문에서 verification_type을 노출 가능한 시점에 1회 라벨링하면 충분하다.
 
    `state_update` FAIL은 자동 `revise-minor` 이상으로 권고한다. 이는 wrap·다음 세션 진입에서 stale handoff·status vocabulary 충돌로 직결되는 항목이라 단독 선언이 필요하다.
 
-8. **적대적 검토자 페르소나** — agent body는 "이 정도면 괜찮다" default 평가 회로 차단을 위해 *적대적 검토자 페르소나* 적용. 페르소나 본문은 각 reviewer agent body §0 영역에 명시 (Task 5 Step 3).
+8. **적대적 검토자 페르소나** — agent body는 "이 정도면 괜찮다" default 평가 회로 차단을 위해 *적대적 검토자 페르소나* 적용. 페르소나 본문은 각 reviewer agent body §0 영역에 명시.
 
-9. **GT Drift catch 의무** — source_fidelity verification_type 영역의 PASS 표지는 *GT 인용 line·section 단위까지 grep 검증 완료* 후에만 허용. LLM 내장 지식 우선 패턴 차단 (rules/workflow.md §검증 주체 분리 정합).
+9. **GT Drift catch 의무** — source_fidelity verification_type 영역의 PASS 표지는 *GT 인용 line·section 단위까지 grep 검증 완료* 후에만 허용. LLM 내장 지식 우선 패턴 차단 (검증 주체 분리 원칙 정합).
 
 ## 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.
+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. The user decides when to split.
 
 Current roster:
 - `deliverable-general-reviewer` — fallback + incubator
@@ -333,7 +335,7 @@ Current roster:
 - `deliverable-spec-reviewer` — 기술 spec·제안서·아키텍처 문서
 
 Future candidates (do not build until pattern justifies):
-- `deliverable-linkedin-reviewer` — voice/tone check for HB's LinkedIn posts
+- `deliverable-linkedin-reviewer` — voice/tone check for the user's LinkedIn posts
 - `deliverable-wiki-reviewer` — cross-reference integrity, orphan detection
 
 ## Red Flags — STOP and run the full gate
@@ -343,18 +345,18 @@ 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. |
+| "I already read the source carefully" | A past session said that exact sentence before the same feedback 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 user said it's ready, they know best" | The user 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.**
+**No exceptions. If a file matches the trigger conditions, the gate runs. The user 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"
+If the named reviewer agent is not registered (e.g. the plugin bundle is incomplete):
+1. Warn the user 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