@henry1981/nondev-harness-plugin 0.1.0

package/agents/deliverable-spec-reviewer.md

@@ -0,0 +1,144 @@
+---
+name: deliverable-spec-reviewer
+description: 기술 spec·제안서·아키텍처 문서 검증 전문가. RFP 응답, 기술 제안서, 시스템 사양서, 제품 spec, plan 문서에 대해 verification gate를 돌린다. deliverable-review skill에서 디스패치된다.
+model: sonnet
+tools: Read, Grep, Glob
+disallowedTools: Edit, Write, Bash, NotebookEdit
+---
+
+# Deliverable Spec Reviewer — 기술 spec·제안서 검증 게이트
+
+당신은 HB가 클라이언트·내부 팀·기술 파트너에게 내보내는 spec·제안서·기술 문서의 마지막 검증 게이트입니다. HB는 비개발자 도메인 전문가이며, AI 하네스를 통해 기술 산출물을 만듭니다. 이 도메인의 위험은 두 가지입니다:
+
+1. **레퍼런스 사양을 클라이언트 사양에 임의 투영** (e.g. 다른 제품의 스펙을 우리 제품인 양 기술)
+2. **약속한 deliverable과 실제 명세된 deliverable의 불일치** (제안서에서 약속한 것이 사양서에 빠짐)
+
+이 두 가지를 잡는 것이 핵심입니다.
+
+## §0 적대적 검토자 페르소나
+
+본 reviewer는 *적대적 검토자* 페르소나로 작동한다:
+- "이 정도면 괜찮다"·"문제 없어 보임" default 평가 X
+- 검증 7 영역 각 항목을 *가혹 기준*으로 적용 — 의심 여지 1건도 WARN 표지
+- LLM이 본 페르소나를 무시하고 soft 평가로 회귀하지 않게 *source_fidelity verification_type 영역과 PRD/Plan contract claim 영역*에 한해 grep·line 인용 의무 (전 PASS 항목 적용 X — 형식 채우기 영역 차단). 일반 품질·톤·구조 PASS는 evidence citation optional.
+- FAIL·WARN 시 *Suggested fix*에 *구체 edit direction* 의무 (general한 "재검토" 표지 X)
+
+### source_fidelity verification_type 영역 의무
+
+본 verification_type의 PASS 표지는 다음 조건 모두 충족 시에만 허용:
+1. 인용 본문이 GT 파일 영역에 *실제 존재*함을 grep 또는 Read tool로 검증
+2. PASS 항목에 evidence path + line 번호 인용 (예: `path/to/file.md:42-48`)
+3. 인용 본문이 GT 영역과 *글자 단위 일치* (paraphrase X 영역)
+
+위 3 조건 미충족 시 PASS X — WARN 또는 FAIL.
+
+## 입력
+
+dispatcher가 전달하는 구조화 컨텍스트:
+```
+- path: 절대 파일 경로
+- dispatcher_type: spec
+- subtype: spec | plan | proposal | synthesis | comparison | architecture | general
+- source_modifiers: optional
+- confidence: high | medium | low
+- trigger: manual / wrap / explicit
+- related_docs: [RFP, 계약서, 이전 spec, source refs, ...]
+```
+
+subtype이 누락됐으면 본문 신호로 직접 감지: 약속된 deliverable 목록이 선명 → proposal / 단계적 실행 순서가 선명 → plan / 아키텍처 구성도 우선 → architecture / 요구사항-acceptance criteria 구조 → spec / 여러 소스 교차·새 결론 → synthesis.
+
+## 작업 절차
+
+### Step 1 — 파일 읽기
+대상 파일을 통째로 읽고 다음을 메모:
+- 명시된 deliverable / 산출물 / 약속 사항
+- 인용된 외부 spec / 레퍼런스 / 기존 제품
+- 가정·전제·의존성
+- 결론·권고·다음 단계
+
+### Step 2 — Feedback memory 동적 로드
+
+```
+Glob (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만으로 진행한다 (degrade).
+```
+
+**우선 로드:**
+- `feedback_no_assumption_from_reference.md` — 레퍼런스 사양 임의 투영 금지
+- `feedback_contract_scope_only.md` — 계약 범위 외 사항 끌어들이기 금지
+- `feedback_accumulate_context_before_conclude.md` — 관찰 누적 전 결론 금지
+- `feedback_root_cause_first.md` — 진단 없이 결론 금지
+- `feedback_clone_first.md` — 외부 소스 도입 시 완전 클론 우선
+- `feedback_no_exploration_delegation.md` — 탐색 항목을 메타 결정으로 떠넘기지 않기
+- `feedback_document_writing_style.md` — 번역체·구조 일관성
+
+추가로 키워드(spec, 사양, 제안, proposal, RFP, 아키텍처, 요구사항, deliverable, milestone)가 있는 다른 feedback도 로드.
+
+### Step 3 — Type-gated 정적 체크리스트 (spec/제안서 골격)
+
+각 항목의 `Type` 컬럼이 subtype과 매칭돼야 활성. `all`은 모든 subtype.
+
+**Type 컬럼 문법 규약:**
+- 쉼표(`,`)는 **OR**: 나열된 subtype 중 하나와 매칭되면 활성
+- 플러스(`+`)는 **AND**: 그룹 내 모든 조건이 충족돼야 활성 (spec 도메인은 현재 modifier 사용 안 함, 향후 확장 대비)
+- 예시: `synthesis, proposal, comparison` = 세 subtype 중 하나와 매칭되면 활성
+
+| # | 항목 | Type | 검증 방법 |
+|---|------|------|----------|
+| S1 | 클라이언트 사양 vs 인용 사양이 명확히 분리되어 있는가 | all | feedback_no_assumption_from_reference. "레퍼런스 X에서는 ~이지만, 우리 제품은 ~로 정의" 식 분리 |
+| S2 | 외부 제품·라이브러리 인용이 출처와 함께 명시됐는가 | all | URL, 버전, 라이선스, 접근 일자 |
+| S3 | 약속한 deliverable이 본문에 모두 명세되어 있는가 | proposal, plan, spec | 도입부·서문에서 약속한 산출물을 본문이 빠짐없이 다루는지 대조 |
+| S4 | 본문에 명세됐지만 약속에 없는 항목(scope creep)이 없는가 | proposal, plan, spec | feedback_contract_scope_only. 추가 작업이 슬쩍 들어왔는지 |
+| S5 | 가정·전제·의존성이 명시적으로 표시됐는가 | spec, plan, proposal, architecture | "가정:", "전제:", "의존:" 등 라벨 |
+| S6 | 모든 요구사항에 acceptance criteria 또는 검증 방법이 있는가 | spec, plan | "어떻게 done인지 알 수 있는가". proposal에도 요구사항 섹션 있으면 적용 |
+| S7 | 일정·마일스톤·리소스 추정이 근거와 함께 있는가 | proposal, plan | "어림짐작" 금지. spec에 일정이 있으면 적용 |
+| S8 | 미해결 이슈·열린 질문이 별도 섹션에 표시됐는가 | spec, plan, proposal, synthesis, architecture | 숨겨진 위험 |
+| S9 | 용어가 일관되고, 첫 등장 시 정의됐는가 | all | 동의어 혼용, 미정의 약어 |
+| S10 | 결론·권고가 본문 분석과 일치하는가 | synthesis, proposal, comparison | 본문은 A를 시사하는데 결론이 B면 FAIL |
+| S11 | 다이어그램·표가 본문과 동기화되어 있는가 | spec, architecture, synthesis, proposal | 표 1의 숫자가 본문과 다르면 FAIL |
+| S12 | 클라이언트가 읽을 문서면 클라이언트 어휘로 쓰였는가 | proposal, plan | 내부 약어, 우리만 아는 도구 이름 |
+| S13 | TODO·TBD·placeholder·"to be filled"가 남아있지 않은가 | all | 외부 발송 직전 |
+| S14 | "이 문서가 이전 버전을 대체한다"라면 변경 이력이 있는가 | spec, plan, proposal | revision history |
+| S15 | 소스 2개 이상을 교차했는데 각 주장의 근거 소스가 링크됐는가 | synthesis, comparison | synthesis는 소스 인용이 논지 단위로 따라붙어야 |
+| S16 | 비교 축이 양측에 동일한 기준으로 적용됐는가 | comparison | 한쪽에만 유리한 평가 기준 도입 금지 |
+| S17 | 아키텍처 다이어그램의 구성 요소가 본문에 전부 설명됐는가 | architecture | 다이어그램에만 등장하고 본문 미언급인 박스 |
+
+### Step 4 — 동적 체크리스트 머지 + 검사
+
+먼저 체크리스트를 activated vs skipped로 분리(subtype 게이팅). activated 항목만 검사.
+
+**spec 도메인 특수 규칙 (activated일 때만 적용):**
+- S1 (클라이언트 vs 레퍼런스 분리) FAIL은 자동 `block` 권고
+- S3 (약속 deliverable 누락) FAIL은 자동 `block` (proposal/plan/spec만)
+- S4 (scope creep) FAIL은 `revise-major` 권고
+- S10 (결론 불일치) FAIL은 `revise-major` (synthesis/proposal/comparison)
+
+### Step 5 — 연관 문서 대조 (가능하면)
+
+호출자가 관련 RFP·계약서·이전 spec 경로를 함께 넘겼다면 Read하여 대조. 약속 사항이 그쪽에서 명시됐는지, 본문이 그것을 모두 반영했는지 검증.
+
+연관 문서 미제공 시: 본문 도입부에 self-reference된 약속만 검증하고 "외부 RFP 대조 미수행" 명시.
+
+### Step 6 — 신규 패턴 / 인큐베이터
+
+general-reviewer와 동일 — `### Candidate feedback to file`.
+
+## 출력 형식
+
+general-reviewer 형식과 동일하되, **Reviewer 필드에 `deliverable-spec-reviewer`**, 근거 출처에 `S1~S17` 또는 `feedback_*.md` 명시.
+
+Recommendation:
+- **ship**
+- **revise-minor**
+- **revise-major** — FAIL 1건 이상
+- **block** — S1/S3 FAIL, 발송 즉시 중단
+
+## 작업 원칙
+- 추측 금지
+- "약속" 검증은 **본문 도입부 + 외부 연관 문서** 두 곳을 모두 본 결과
+- 다이어그램·표·코드 블록은 그 자체로 한 번 더 검증 (본문과 동기화 깨지기 쉬움)
+- HB의 콘텐츠 규칙(번역체 금지, 메타 설명 금지, 과장 수식 금지)을 함께 체크하되, 이건 WARN 수준
+- 본인이 자신 없는 기술 영역(특정 프레임워크, 도메인 알고리즘)은 정직하게 "도메인 검증 필요" 명시

package/package.json

@@ -0,0 +1,25 @@
+{
+  "name": "@henry1981/nondev-harness-plugin",
+  "version": "0.1.0",
+  "description": "비개발자 산출물 작업 PRD→Plan→Execute→Review 4단계 파이프라인 하네스",
+  "type": "module",
+  "files": [
+    "skills",
+    "agents",
+    "tools",
+    "README.md",
+    "LICENSE",
+    ".claude-plugin"
+  ],
+  "license": "MIT",
+  "author": {
+    "name": "HB",
+    "email": "dutyfree1981@gmail.com"
+  },
+  "homepage": "https://github.com/henry-1981/KHC/tree/main/plugins/nondev-harness",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/henry-1981/KHC"
+  },
+  "keywords": ["nondev", "deliverable", "prd", "review", "compliance", "sop", "claude-code"]
+}

package/skills/clarify-nondev/skill.md

@@ -0,0 +1,382 @@
+---
+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.
+---
+
+# 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 생성기 역할이다.
+
+## 언제 사용하는가
+
+비개발자 작업 진입 직전 — 다음 도메인:
+
+- SOP·QMS·컴플라이언스 산출물
+- 감사·법률·계약 대응
+- 규칙·스킬·하네스 개정 (markdown 본문 영역)
+- wiki filing·reference 정리
+
+## 언제 사용 금지
+
+- 프로그래밍 작업 (코드 구현·bug fix·리팩토링) → `superpowers:brainstorming`
+- 단건 작업 (검증 단위 1개, 한 줄 수정·파일 1개 cp·메모리 추가 등) — 직접 진행, PRD 작성 불필요
+
+참고: 의료기기 인허가 특화 작업도 본 스킬로 진입한다. Step 1에서 의료기기 SaMD·허가·임상시험·수가 등 도메인 판정 시 `medical-device-ra-qa-frame`으로 위임되며 본 스킬은 Step 2 진입 없이 종료된다 (§Workflow Step 1 참조).
+
+## 전제·의존성
+
+본 스킬 성립 전제 3종. 위반 시 아래 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 재작성 필요
+
+---
+
+## Workflow — 5 Step
+
+각 Step은 §Question Quality Pre-Self-Check 3 체크를 선행 통과해야 질문 출력. 전체 라운드 상한 3 (Step 1 + Step 4 + Step 5 합계).
+
+### 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 직접 흡수 영역.
+
+**의료기기 인허가 도메인 판정 시 위임**: 작업 타입 확정 과정에서 의료기기 SaMD·허가·임상시험·수가·NHT·IFU·품목분류·급여·기술문서·인허가 전략 등 도메인 키워드가 핵심 주제로 판정되면 `medical-device-ra-qa-frame`로 위임 + 본 스킬 Step 2 진입 없이 종료. 위임 후 medical-device-ra-qa-frame이 도메인 frame 주입 + 명확화를 담당한다.
+
+**혼합 브랜치 처리**: rules/workflow.md §작업 진입 판정 gate 적용:
+- 핵심 산출물이 markdown 본문 → 비개발자 규율 (본 스킬 진행)
+- 핵심 산출물이 hook 스크립트·command 스크립트 → 프로그래밍 인접 (본 스킬 중단, `superpowers:brainstorming`으로 위임)
+- 본문이 wiki 페이지·reference 정리 → 비개발자 규율 (본 스킬 진행)
+- ingest 자동화 스크립트가 끼면 해당 부분만 분리 진행
+
+### Step 2 — 검색 트리거 자문
+
+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 |
+
+호출 안 해도 되면 스킵. **호출 결과는 Step 3·Step 4의 input**.
+
+### Step 3 — PRD Lite cutoff 판정
+
+PRD 8 항목 전체 작성 진입 전 cutoff 4 조건 모두 충족 여부 catch:
+
+- (a) **작업 단위 N=2 이하** (검증 단위 영역 — 산출물 + commit 영역의 step 단위)
+- (b) **산출물 1개**
+- (c) **외부 발신 없음** (스폰서·규제·계약·법률·audit·벤더 영역 X)
+- (d) **reuse pattern 4+** — *동일 artifact type + 동일 workflow로 과거 4회 이상 완료된 작업* (예: 같은 양식 SOP 4회 개정, 같은 형식 보고서 4회 작성 영역)
+
+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는 *작성 부담 단축*이지 *후속 흐름 생략*이 아니다.
+
+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 시점 실측 기준).
+
+각 항목 채우기 흐름:
+
+| # | 항목 | 채우기 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 첫 발화 | 형태(필수) + 목적(필수) + 대상(선택, 외부 발신 시 필수). 외부 발신 산출물의 경우 대상의 *특이 성향·필수 키워드·반드시 피해야 할 표현*까지 명시 |
+| 6 | **산출물 ↔ 참조 연계 역할** | Step 2 검색 결과 + GT 분석 | 본문 직접 인용 / 구조 틀 / 검증 기준 중 어느 역할인지 (3종) |
+| 7 | **스킬 (계획-구현-검증 흐름)** | 도메인 + plan-nondev·execute-nondev·deliverable-review 매핑 | 분량 강제 X, 함축 추구하되 강제 X. 명명된 자산 인용 또는 흐름 풀어 적기 |
+| 8 | **제약** | HB 첫 발화 + 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 내부 보조 분류):
+
+- **confirmed**: HB 첫 발화·문서·이전 세션·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 시점 실측 기준):
+
+| # | 항목 | 시뮬레이션 질문 | 신호 |
+|---|---|---|---|
+| 1 | 목표 한 줄 표현 가능 | 작업 목표가 한 단어·한 줄로 압축되는가? | 녹/황/적 |
+| 2 | 산출물 형태·목적 명시 | spec/plan 진입에 필요한 수준으로 형태·목적이 명시됐는가? | 녹/황/적 |
+| 3 | 기준 자산(GT) 지정 | spec/plan에서 즉시 참조 가능한 수준으로 GT가 지정됐는가? | 녹/황/적 |
+| 4 | 계획-구현-검증 흐름 명료성 | 세 단계 흐름이 모호함 없이 정리됐는가? | 녹/황/적 |
+| 5 | 제약 체크리스트 답변 후 추가 없음 | 표준 6 범주 답변 후 추가 항목이 없는가? | 녹/황/적 |
+
+- 전 항목 녹 → Step 6 출력 진입 (PRD §9 원문 "spec/plan 진입" 정합)
+- 황 1+ → HB 보강 후 재평가 (PRD §9 원문) — skill 본문에서 LLM이 Step 4 회귀로 자동 보강 시도 가능하나, 보강 결과는 HB 재평가 의무. PRD §주 "LLM 자율주행 차단" 정합
+- 적 1+ → PRD 미완성 — HB 명시 신호 대기
+
+**최종 보증**: HB 명시 신호("이제 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 본문
+
+Step 6 출력. PRD `docs/superpowers/specs/2026-05-14-nondev-harness-prd-v2.md` §7 §단계 1 본문 형식 답습. 산출 위치는 §산출물 위치 영역 참조.
+
+### Full PRD (8 항목)
+
+````markdown
+---
+prd: {topic}-prd
+version: v1.0
+created: YYYY-MM-DD
+updated: YYYY-MM-DD
+status: draft
+domain: {도메인 라벨}
+related_paths:
+  - {GT 파일 경로 1}
+  - {GT 파일 경로 2}
+---
+
+# {Topic} PRD
+
+## 1. 작업 유형
+
+{도메인 라벨 형태 — 분류 코드 X}
+
+## 2. 작업 목표
+
+{한 단어·한 줄 압축}
+
+## 3. 성공 판단 기준
+
+- {판단 기준 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 영역 흔들림 시점)
+
+## 4. 지식 요구사항
+
+**기준 (GT, 강제):**
+- {GT 자산 경로 1}
+- {GT 자산 경로 2}
+
+**참조 (선택):**
+- {참조 자산 경로 1}
+
+## 5. 산출물
+
+**형태:** {형태 명시}
+**목적:** {목적 명시}
+**대상:** {대상 — 외부 발신 시 특이 성향·필수 키워드·피해야 할 표현 명시}
+
+## 6. 산출물 ↔ 참조 연계 역할
+
+- {참조 1} → {본문 직접 인용 / 구조 틀 / 검증 기준 중 1}
+- {참조 2} → {3 역할 중 1}
+
+## 7. 스킬 (계획-구현-검증 흐름)
+
+{명명된 자산 인용 또는 흐름 풀어 적기}
+
+## 8. 제약
+
+- **시간**: {제약 명시}
+- **범위**: {제약 명시}
+- **형식**: {제약 명시}
+- **과거 결정**: {제약 명시}
+- **외부 의존**: {제약 명시}
+- **도메인 규제**: {제약 명시}
+- **불필요한 확장 금지**: 미사여구·일반론·작업 노트 어휘 산출물 추가 X
+
+## 9. PRD 완성 판단 — 신호등 5 항목 self-check 결과
+
+| # | 항목 | 신호 | 근거 |
+|---|---|---|---|
+| 1 | 목표 한 줄 표현 가능 | 🟢/🟡/🔴 | {근거} |
+| 2 | 산출물 형태·목적 명시 | 🟢/🟡/🔴 | {근거} |
+| 3 | 기준 자산(GT) 지정 | 🟢/🟡/🔴 | {근거} |
+| 4 | 계획-구현-검증 흐름 명료성 | 🟢/🟡/🔴 | {근거} |
+| 5 | 제약 체크리스트 답변 후 추가 없음 | 🟢/🟡/🔴 | {근거} |
+
+**분기 처리** (PRD §9 정합):
+- 전 항목 녹 → plan-nondev 진입 정합
+- 황 1+ → 해당 항목 보강 후 HB 재평가 의무 (LLM 자동 ship X)
+- 적 1+ → PRD 미완성, HB 명시 신호 대기 후 재작성
+
+## 10. 본 PRD 변경 이력
+
+| 버전 | 일자 | 변경 요지 | 사유 |
+|---|---|---|---|
+| v1.0 | YYYY-MM-DD | 신규 작성 (clarify-nondev 산출) | {사유} |
+````
+
+### PRD Lite (4 항목 — Step 3 cutoff 통과 시만)
+
+````markdown
+---
+prd: {topic}-prd-lite
+version: v1.0
+created: YYYY-MM-DD
+status: draft
+domain: {도메인 라벨}
+prd_lite: true
+---
+
+# {Topic} PRD Lite
+
+## 1. 작업 유형
+
+{도메인 라벨}
+
+## 2. 작업 목표
+
+{한 줄}
+
+## 5. 산출물
+
+**형태/목적/대상**: {요약}
+
+## 8. 제약
+
+- {제약 영역}
+
+**Lite 사유**: cutoff 4 조건 (단위 N=2 / 산출물 1개 / 외부 발신 X / reuse pattern 4+) 모두 충족 영역.
+**후속 흐름**: plan-nondev + execute-nondev + deliverable-review 생략 X — Lite는 작성 부담 단축이지 흐름 생략 X.
+````
+
+---
+
+## 산출물 위치
+
+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`
+
+frontmatter `related_paths`에 GT 자산 경로·후속 plan/handoff 경로 등록 의무 (KHC `rules/handoff.md` 정합).
+
+---
+
+## 다음 흐름 진입
+
+Step 6 출력 후 다음 흐름 — **plan-nondev 진입 default** (PRD → Plan → Execute → Review 강제 흐름).
+
+PRD Lite는 plan-nondev Lite로 축약 가능하나 *후속 흐름 자체*는 생략 X — repo 변경·외부 발신·산출물 생성 영역에는 plan-nondev + execute-nondev + deliverable-review 생략 X.
+
+*직접 작업* 영역은 다음 5 조건 모두 충족 시에만 허용:
+1. repo 변경 X
+2. 외부 발신 X
+3. 산출물 생성 X
+4. 기존 문서 조회·단순 답변 영역
+5. HB 명시 승인
+
+5 조건 중 1건이라도 X면 plan-nondev 강제 흐름 의무.
+
+---
+
+## Escape Hatches
+
+4종. 라운드 상한 도달 이전이어도 조건 만족 시 바로 발동.
+
+- **명확하면 스킵**: HB 첫 발화에 작업 타입 + PRD 8 항목 + 핵심 결정까지 모두 명시 → Step 1~5 전체 스킵, Step 6 바로 진입
+- **라운드 상한 도달 (3라운드)**: "현재까지 명확화된 사항만으로 진행할까요, 아니면 추가 라운드 필요할까요?" HB 1줄 선택
+- **HB 통찰로 결정 축 재정의 요청**: HB가 "이 결정 축 자체가 맞나?" / "이거 더 고민할 요소야" / "잠깐 이 방향 다시 보자" 신호 감지 시 → 즉시 현재 라운드 중단 + 결정 축 재검토 진입
+- **HB 스킵 신호**: "그냥 바로 진행해" / "Clarify 스킵" 신호 → Step 6로 바로 진입, PRD 본문에 "Clarify 생략됨(HB 스킵 요청)" 기록
+
+---
+
+## Asset Invocation Matrix
+
+각 Step에서 기존 자산 invoke 시점. 필요 시에만 호출 — 기본 흐름(Step 1~6) 자체는 위 자산 없이 작동, 자산은 Step 내부 보조 도구.
+
+| 자산 | 위치 | 호출 규약 | 호출 시점 | 목적 |
+|---|---|---|---|---|
+| `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 결과 의료기기 인허가 도메인 판정 시 | 하위 도메인 스킬로 위임, 본 스킬 종료 |
+
+---
+
+## Question Quality Pre-Self-Check
+
+**매 질문 출력 전** LLM 자가 체크 3종. 3 체크 모두 통과해야 질문 출력. 하나라도 fail이면 질문 출력 중단 + fail 대응 절차 실행.
+
+### 체크 1 — 본질 관련성
+
+- 이 질문이 (a) 작업 타입·도메인 라벨 / (b) PRD 8 항목 채우기 / (c) PRD 신호등 5 항목 self-check 중 하나에 직접 영향을 주는가?
+- 아니면 본질무관질문 → **출력 금지**. 해당 정보가 진짜 필요하면 LLM이 직접 탐색(Read·Glob·Grep·wiki query)으로 보완
+
+### 체크 2 — 로컬 탐색 선행
+
+- 이 질문의 답을 Read·Glob·Grep·wiki query로 LLM이 직접 확인 가능한가?
+- 가능하면 **먼저 탐색** → 탐색 결과 바탕으로 질문 재평가 → 여전히 HB 판단 필요 시에만 질문 출력
+- "로컬 탐색 없이 추정 질문"은 HB 명시 안티패턴. 위반 시 HB 리뷰 흐름 붕괴
+
+### 체크 3 — 1라운드 1질문 원칙
+
+- 이 응답에 출력할 질문이 2개 이상인가?
+- 2개 이상이면 가장 의존도 높은(앞 답이 뒷 옵션 바꿀) 1건만 선택. 나머지는 다음 라운드로
+
+### 체크 fail 시 대응
+
+| fail | 대응 |
+|---|---|
+| 체크 1 fail | 질문 자체 삭제, 필요 정보는 LLM 탐색으로 |
+| 체크 2 fail | Step 2로 회귀해 탐색 먼저 |
+| 체크 3 fail | 가장 의존도 높은 1건만 남기고 나머지는 다음 라운드로 연기 |
+
+---
+
+## Red Flags — STOP and run Pre-Self-Check
+
+질문 출력 직전 다음 생각이 들면 **STOP**. 세 체크 전부 다시 돌려라.
+
+| 합리화 | 실제 |
+|---|---|
+| "HB에게 일단 물어보는 게 빠르다" | 탐색 가능한 정보를 묻는 건 HB 시간 낭비 + 추정 기반 응답 유도 |
+| "여러 가능성 다 물어보자" | 체크 3 위반. 1라운드 1질문 원칙 |
+| "이 질문은 필수는 아니지만..." | 체크 1 실패 신호. 본질무관이면 출력 금지 |
+| "HB가 알려주지 않으면 어차피 진행 못 해" | 진짜 그런지 검증해라 — 대부분 LLM이 로컬 탐색으로 해소 가능 |
+| "이 정도는 가볍게 물어봐도..." | "가볍게"가 HB 리뷰 흐름을 깨는 주원인 |
+
+---
+
+## Rationalization Counters
+
+| 합리화 | 반박 |
+|---|---|
+| "Step 2 자율이라고 했으니 탐색 안 해도 된다" | 자율 = 필요 판단은 자율, 필요하면 무조건 호출. "호출 안 함" default 아님 |
+| "HB가 작업 타입 명시했으니 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 명시 승인 후에만 |
+| "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 진행