@taejung3852/project-scaffold 0.1.0

package/skills/brief/references/dashboard.md

@@ -0,0 +1,140 @@
+# brief dashboard — 프로젝트 대시보드
+
+프로젝트 현황을 markdown → terminal → web UI 순으로 렌더링한다.
+wiki/의 devlog, conventions, decisions 데이터를 읽어 자동으로 생성한다.
+
+## 목차
+
+- 렌더 모드
+- 데이터 수집
+- 대시보드 구성
+- markdown·terminal·web 렌더링
+- TODO 관리와 갱신 규칙
+
+
+## Step 0 — 렌더 모드 확인
+
+`/brief dashboard` 실행 시 모드를 확인한다:
+
+| 모드 | 트리거 | 설명 |
+|---|---|---|
+| **markdown** | `/brief dashboard` 또는 `/brief dashboard md` | wiki/dashboard.md 갱신 |
+| **terminal** | `/brief dashboard term` | 터미널에 컬러 출력 |
+| **web** | `/brief dashboard web` | browser로 HTML 열기 |
+
+인자가 없으면 markdown 모드 기본값.
+
+---
+
+## Step 1 — 데이터 수집
+
+다음 파일들을 읽어 데이터를 수집한다:
+
+| 데이터 | 소스 |
+|---|---|
+| 오늘 할 일 | `wiki/dashboard.md` 의 TODO 섹션 (있으면) |
+| 최근 devlog | `raw/dev-logs/` 최신 3개 파일 |
+| 마일스톤 진행도 | `wiki/conventions/01-project-overview.md` 의 마일스톤 |
+| 미해결 결정 | `raw/decisions/` 중 `ingest_status: "⏳ pending"` |
+| wiki 건강 | `wiki/log.md` 최신 lint 결과 (있으면) |
+
+---
+
+## Step 2 — 대시보드 구성
+
+대시보드는 다음 섹션으로 구성된다:
+
+```text
+## 📋 오늘 할 일
+- [ ] 항목 1
+- [ ] 항목 2
+
+## 📈 마일스톤 진행도
+| 마일스톤 | 상태 | 진행도 |
+|---|---|---|
+| MVP | 진행 중 | 60% |
+
+## 📝 최근 devlog (최신 3개)
+- YYYY-MM-DD: 요약 한 줄
+
+## ⚠️ 주의 필요
+- 미처리 결정: n개
+- wiki 모순: n개 (있으면)
+
+## 🔗 빠른 링크
+- [[wiki/index.md]] | [[wiki/log.md]] | [[wiki/conventions/]]
+```
+
+---
+
+## Step 3 — 렌더링
+
+### markdown 모드
+
+`wiki/dashboard.md`를 갱신한다.
+
+```yaml
+---
+title: Dashboard
+updated: YYYY-MM-DD HH:MM
+---
+```
+
+기존 파일이 없으면 생성. 있으면 전체 갱신.
+
+### terminal 모드
+
+ANSI 컬러 코드로 터미널에 직접 출력한다:
+
+```bash
+echo -e "\033[1;34m📋 오늘 할 일\033[0m"
+# ... 섹션별 출력
+```
+
+명세서 형식 사용 (bold, color, separator lines).
+
+### web 모드
+
+`wiki/dashboard.html`을 생성하고 브라우저로 연다:
+
+```bash
+open wiki/dashboard.html  # macOS
+xdg-open wiki/dashboard.html  # Linux
+```
+
+HTML은 간단한 인라인 CSS 포함. 외부 CDN 의존 없음.
+
+---
+
+## 갱신 시점
+
+`.hooks/devlog-auto.sh`는 커밋 후 `raw/dev-logs/`만 갱신한다. dashboard는 사용자가 현황을 요청하거나 `/brief dashboard`를 실행할 때 최신 wiki와 raw를 읽어 갱신한다.
+
+---
+
+## 오늘 할 일 관리
+
+사용자가 TODO를 추가하려면:
+
+> `/brief dashboard add [항목]`
+
+`wiki/dashboard.md`의 TODO 섹션에 항목을 추가한다.
+
+완료 처리:
+
+> `/brief dashboard done [번호]`
+
+`[ ]` → `[x]` 로 변경. 완료된 항목은 다음 갱신 시 devlog에 자동 기록.
+
+---
+
+## 규칙
+
+| 항목 | 규칙 |
+|---|---|
+| 기본 모드 | markdown. terminal·web은 명시적 요청 시만 |
+| 입력 데이터 | wiki/ 와 raw/ 는 읽기 전용 |
+| 출력 파일 | markdown 모드에서 `wiki/dashboard.md` 생성·전체 갱신 허용 |
+| 갱신 | `/brief dashboard` 또는 현황 브리핑 요청 시 실행 |
+| HTML 생성 | 외부 CDN 없음. 인라인 CSS만 |
+| 이전 대시보드 | 갱신 시 덮어씀. 버전 관리는 git에 위임 |

package/skills/brief/references/handoff.md

@@ -0,0 +1,130 @@
+# brief handoff — 세션 인계
+
+지금까지의 대화와 작업 컨텍스트를 압축해 저장하고, 다음 세션(또는 다른 에이전트)이 그대로 이어받을 수 있게 한다.
+`/clear`나 새 세션 시작으로 컨텍스트가 끊겨도 처음부터 다시 설명할 필요가 없다.
+
+## 목차
+
+- 모드 결정
+- save: 대화·git 컨텍스트 저장
+- load: 최근 인계 복원
+- list: 저장본 탐색
+- clean: 확인 후 오래된 인계 삭제
+
+
+## Step 0 — 모드 결정
+
+`/brief handoff` 실행 시 모드를 확인한다.
+
+| 모드 | 트리거 | 동작 |
+|---|---|---|
+| `save` | `/brief handoff save [다음 세션 목표]` 또는 세션 종료 의도 표현 시 | 현재까지 대화·작업 압축 저장 |
+| `load` | `/brief handoff load` | 가장 최근 저장본 복원 |
+| `list` | `/brief handoff list` | 저장된 인계 목록 표시 |
+| `clean` | `/brief handoff clean [N일]` | N일(기본 30일) 이상 지난 저장본 삭제 |
+
+인자가 없으면 묻는다:
+
+> "세션을 저장할까(save), 이전 세션을 불러올까(load)?"
+
+인자로 텍스트가 주어지면(`/brief handoff save 다음엔 인증 모듈 테스트 작성`) 다음 세션이 무엇에 집중할지에 대한 설명으로 간주하고, 문서 내용을 그 목표에 맞춰 작성한다.
+
+---
+
+## Step 1 — save
+
+### 1-1. 대화 요약
+
+지금까지의 대화에서 다음을 정리한다:
+
+- 무엇을 하려고 시작했는지
+- 무엇을 완료했는지
+- 진행 중이던 작업과 그 상태
+- 막힌 부분·미해결 질문
+- 다음 세션이 집중할 목표 (인자로 받았으면 그걸 우선, 없으면 자연스러운 다음 단계 추론)
+
+**이미 다른 산출물(PR, 커밋, 결정 문서, 이슈, diff)에 적혀 있는 내용은 다시 풀어 쓰지 않는다.** 경로나 URL로 참조한다.
+
+### 1-2. git 컨텍스트 (보조 정보)
+
+```bash
+git branch --show-current
+git log -5 --oneline
+git status --short
+```
+
+### 1-3. 추천 스킬
+
+다음 세션에서 바로 실행하면 좋을 스킬을 1~3개 제안한다 (예: `raw/`에 pending 파일이 있으면 `/wiki ingest`, PR 올리기 직전이면 `/review`).
+
+### 1-4. 민감 정보 검열
+
+API 키, 토큰, 비밀번호, 개인정보 등이 대화나 git 출력에 포함돼 있으면 `[REDACTED]`로 가린다.
+
+### 1-5. 저장
+
+`raw/handoffs/YYYY-MM-DD_HHmm.md` 에 저장한다:
+
+```markdown
+---
+date: YYYY-MM-DD HH:mm
+branch: [브랜치명]
+---
+
+## 다음 세션 목표
+[인자로 받은 목표, 없으면 추론한 다음 단계]
+
+## 지금까지
+[무엇을 하려 했고, 무엇을 완료했는지]
+
+## 진행 중 / 막힌 부분
+[미완료 작업, 미해결 질문]
+
+## 관련 산출물
+- [PR/커밋/문서 경로나 URL — 내용 중복 금지, 참조만]
+
+## 추천 스킬
+- `/스킬명` — [이유]
+```
+
+> 이 파일은 `ingest_status` 필드를 쓰지 않는다 — `/wiki ingest` 대상이 아니다. 세션 운영 기록일 뿐 wiki에 통합할 지식이 아니다.
+
+저장 후 채팅에 같은 내용을 요약해 출력한다.
+
+---
+
+## Step 2 — load
+
+`raw/handoffs/` 에서 가장 최근 파일을 읽는다 (날짜가 인자로 주어지면 해당 파일).
+
+읽은 내용을 그대로 정리해 출력하고, 저장 시점 이후 git 상태가 달라졌으면 알려준다:
+
+```bash
+git status --short
+```
+
+> "저장 시점 이후 변경된 파일이 있어: [목록]"
+
+---
+
+## Step 3 — list
+
+`raw/handoffs/` 파일들을 날짜 역순으로, 각 파일의 "다음 세션 목표" 한 줄과 함께 나열한다.
+
+---
+
+## Step 4 — clean
+
+기본 30일(인자로 지정 시 해당 일수) 이상 지난 파일 목록을 보여주고 삭제 확인을 받는다. **확인 없이 삭제하지 않는다.**
+
+---
+
+## 규칙
+
+| 항목 | 규칙 |
+|---|---|
+| 저장 위치 | `raw/handoffs/` — `/wiki ingest` 대상 아님 (`ingest_status` 필드 생략) |
+| 중복 금지 | PR·커밋·결정 문서에 이미 있는 내용은 재서술하지 않고 경로/URL로만 참조 |
+| 민감 정보 | API 키·토큰·개인정보는 저장 전 반드시 검열 |
+| load 시 git 상태 비교 | 저장 시점과 달라진 게 있으면 반드시 알림 |
+| 삭제(clean) | 항상 사용자 확인 후 진행 |

package/skills/brief/references/report.md

@@ -0,0 +1,163 @@
+# brief report — 목적별 리포트 생성
+
+회의·인터뷰·스프린트 등의 내용을 받아 목적에 맞는 문서를 생성한다.
+
+## 목차
+
+- 리포트 타입과 원본 수집
+- 내부용·팀 공유용 출력 선택
+- 회의·인터뷰·ADR·스프린트 포맷
+- 저장 경로와 작성 규칙
+
+
+## Step 0 — 리포트 타입 선택
+
+```text
+1) 회의록        — 팀 정기 회의, 기획 회의
+2) 인터뷰 리포트 — 사용자·고객·팀원 딥인터뷰
+3) ADR           — Architecture Decision Record, 기술 결정 문서
+4) 스프린트 요약 — 스프린트 회고·계획
+```
+
+인자로 타입이 명시된 경우(`/brief report 인터뷰`) 바로 해당 타입으로 진행한다.
+
+---
+
+## Step 1 — 원본 내용 수집
+
+**인자가 파일 경로인 경우:** 해당 파일을 읽는다.
+
+**인자가 없거나 타입만 있는 경우:**
+
+> "리포트로 만들 내용을 붙여넣어 주세요. 완료되면 END 입력."
+
+붙여넣은 내용을 그대로 사용한다. 내용을 수정하거나 요약하지 않는다.
+
+---
+
+## Step 2 — 출력 모드 선택
+
+> "어떤 용도로 만들까요?
+> 1) 내 파악용 — 상세 인사이트·의문점·주관적 해석 포함
+> 2) 팀 공유용 — 결정사항·액션아이템·담당자 중심의 공유 문서
+> 3) 둘 다 — 두 버전 동시 생성"
+
+---
+
+## Step 3 — 리포트 생성
+
+### 내 파악용 포맷
+
+```markdown
+# [제목] — 내부 메모 (YYYY-MM-DD)
+
+## 1분 요약
+(핵심 3줄 이내)
+
+## 상세 내용
+### 논의된 주제들
+(항목별 정리)
+
+### 내 해석 & 인사이트
+- 이 결정이 [X]에 미치는 영향:
+- 확인이 더 필요한 사항:
+- 아직 해결 안 된 의문:
+
+### 주목할 인용
+> "..." — [발화자]
+
+## 다음에 알아볼 것들
+- [ ] ...
+```
+
+### 팀 공유용 포맷
+
+```markdown
+# [제목] (YYYY-MM-DD)
+
+**참석자:** ...
+**작성자:** ...
+
+## 결정사항
+| # | 결정 내용 | 배경 |
+|---|---|---|
+| 1 | | |
+
+## 액션아이템
+| 항목 | 담당자 | 기한 |
+|---|---|---|
+| | | |
+
+## 논의 요약
+(회의 흐름 중심으로 간결하게)
+
+## 다음 미팅
+- 일시:
+- 안건:
+```
+
+### ADR 포맷 (타입 3 선택 시)
+
+```markdown
+# ADR-NNN: [제목]
+
+**상태:** proposed | accepted | deprecated
+**날짜:** YYYY-MM-DD
+**결정자:** ...
+
+## 맥락
+(이 결정이 필요했던 배경·제약·문제)
+
+## 결정
+(우리가 선택한 것과 이유)
+
+## 결과
+**긍정적:**
+**부정적:**
+**중립적·트레이드오프:**
+```
+
+### 스프린트 요약 포맷 (타입 4 선택 시)
+
+```markdown
+# 스프린트 [N] 요약 (YYYY-MM-DD ~ YYYY-MM-DD)
+
+## 완료
+- [x] ...
+
+## 미완료 & 이유
+- [ ] ... — 이유:
+
+## 회고
+**잘 된 것:**
+**개선할 것:**
+
+## 다음 스프린트 목표
+1. ...
+```
+
+---
+
+## Step 4 — 저장 및 출력
+
+| 용도 | 저장 경로 |
+|---|---|
+| 내 파악용 | `wiki/meetings/YYYY-MM-DD_[slug]_internal.md` |
+| 팀 공유용 | `wiki/meetings/YYYY-MM-DD_[slug]_shared.md` |
+
+저장 후:
+- 저장 경로 출력
+- **팀 공유용**은 마크다운 블록으로도 바로 출력 (Slack·Notion에 복붙 가능하도록)
+- **둘 다**인 경우 두 파일 모두 저장 후 공유용만 블록 출력
+
+---
+
+## 규칙
+
+| 항목 | 규칙 |
+|---|---|
+| 원본 내용 | 수정·삭제 금지. 리포트는 재구성이지 편집이 아님 |
+| 사실 vs 해석 | 내 파악용에서만 해석 허용. 팀 공유용은 사실과 결정만 |
+| 담당자 불명확 시 | `TBD`로 표시하고 괄호에 후보 명시 |
+| 기한 불명확 시 | `미정`으로 표시 (임의 날짜 생성 금지) |
+| ADR 번호 | `wiki/meetings/` 내 기존 ADR 파일 수 + 1로 자동 부여 |

package/skills/review/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: review
+description: "프로젝트 변경사항을 wiki/conventions 기준으로 검토한다. 정적 분석과 LLM 맥락 판단을 결합해 네이밍, 아키텍처, 테스트, 에러 처리, 보안 위반을 찾는다. 코드 리뷰, PR 준비, 컨벤션 검증, 변경사항 품질 점검 시 사용."
+---
+
+# /review — 컨벤션 기반 변경사항 검토
+
+LLM 기반 리뷰 + 정적 분석 도구를 조합해서 코드를 검증한다.
+wiki/conventions/의 팀 규칙을 기준으로 판단한다.
+
+---
+
+## Step 0 — 대상 결정
+
+**인자가 있으면**: 해당 파일·디렉토리를 대상으로 한다.
+
+**인자가 없으면**: 변경된 파일 목록을 확인한다.
+
+```bash
+{ git diff --name-only HEAD; git ls-files --others --exclude-standard; } | sort -u
+```
+
+- 파일이 있으면 해당 목록으로 진행
+- 파일이 없으면: "변경된 파일이 없습니다. 파일 경로를 직접 지정해주세요."
+
+---
+
+## Step 1 — 컨벤션 로드
+
+`wiki/conventions/`에서 코드 관련 페이지를 읽는다:
+
+우선순위:
+1. `wiki/conventions/03-naming.md` — 네이밍 규칙
+2. `wiki/conventions/05-architecture.md` — 아키텍처 규칙
+3. `wiki/conventions/06-tdd.md` — TDD 규칙 (테스트 파일 확인)
+4. `wiki/conventions/11-error-handling.md` — 에러 핸들링
+5. `wiki/conventions/12-security.md` — 보안 규칙
+
+> wiki/conventions/ 가 없으면: "/wiki setup으로 먼저 컨벤션을 정의해주세요." 안내 후 종료.
+
+---
+
+## Step 2 — 정적 분석 실행
+
+`wiki/conventions/02-tech-stack.md`에서 기술 스택 확인 후 해당 도구를 실행한다.
+
+| 스택 | 도구 | 명령 |
+|---|---|---|
+| Python | pylint | `pylint [파일]` |
+| Python | mypy | `mypy [파일]` |
+| JavaScript/TypeScript | eslint | `npx eslint [파일]` |
+| Java | checkstyle | `checkstyle [파일]` |
+
+도구가 설치되지 않은 경우: 조용히 건너뛰지 않는다. 설치 명령어를 안내하고 설치할지 물어본다.
+- 설치를 원하면: 안내한 명령어로 설치 후 그 도구로 검증을 이어간다
+- 원치 않으면: 그 도구만 "미설치(스킵)"로 표시하고 나머지는 계속 진행
+
+결과를 저장해두고 Step 3에서 함께 활용한다.
+
+---
+
+## Step 3 — LLM 기반 리뷰
+
+로드한 컨벤션을 기준으로 대상 코드를 읽고 다음 항목을 점검한다:
+
+| 항목 | 점검 내용 |
+|---|---|
+| **네이밍** | 규칙과 다른 변수명·함수명·클래스명 |
+| **아키텍처** | 레이어 간 의존성 방향 위반, 금지된 직접 접근 |
+| **TDD** | 기능 코드에 대응하는 테스트 파일 누락 |
+| **에러 핸들링** | 나쁜 예외 처리 (bare except, 무시, 무분별한 print) |
+| **보안** | 하드코딩된 시크릿, 검증 없는 외부 입력 처리 |
+| **컨벤션 추가** | wiki/conventions/에 있는 기타 규칙 |
+
+LLM 리뷰는 정적 분석이 잡지 못하는 **맥락적 판단**에 집중한다.
+
+---
+
+## Step 4 — 통합 리포트
+
+정적 분석 + LLM 리뷰 결과를 합쳐 하나의 리포트로 제시한다:
+
+```text
+## /review 결과 — YYYY-MM-DD
+
+### 🔴 위반 (즉시 수정)
+- [naming] src/api/userHandler.py:23 — 함수명 `GetUser`는 PascalCase. snake_case 사용 필요
+  > 컨벤션: wiki/conventions/03-naming.md
+- [security] src/db/connect.py:5 — DB 비밀번호 하드코딩
+  > 컨벤션: wiki/conventions/12-security.md
+
+### 🟡 개선 권장
+- [tdd] src/services/payment.py — 대응 테스트 파일 없음
+- [error-handling] src/utils/parser.py:41 — bare except 사용
+
+### 🟢 정적 분석 결과
+pylint: 8.2/10 (경고 3개)
+mypy: 에러 없음
+```
+
+---
+
+## Step 5 — HITL 확인 (HIGH 위반 시)
+
+🔴 위반이 있으면:
+
+> "위반 사항이 있습니다. 수정 후 다시 실행하거나, 예외로 처리할 항목을 알려주세요.
+> 코드 병합 전에 수정을 권장합니다."
+
+- 수정 제안을 원하면 각 항목에 대해 수정 코드를 제안한다
+- 예외 처리 시: `wiki/conventions/`에 예외 규칙 추가 여부를 확인한다
+
+---
+
+## 규칙
+
+| 항목 | 규칙 |
+|---|---|
+| 컨벤션 기준 | wiki/conventions/ 없으면 실행 불가 |
+| 정적 도구 | 미설치 시 설치 명령어 안내 + 설치 여부 확인. 동의 없이 임의 설치 금지 |
+| 자동 수정 | 금지. 제안만 함 |
+| HITL | 🔴 위반 시 반드시 사람 확인 |
+| wiki 업데이트 | 예외 인정 시 conventions에 기록 |

package/skills/review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Convention Review"
+  short_description: "프로젝트 컨벤션을 기준으로 변경사항과 위험 검토"
+  default_prompt: "Use $review to review the current changes against project conventions."

package/skills/wiki/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: wiki
+description: "프로젝트 LLM Wiki의 전체 수명주기를 관리한다. 프로젝트 초기 설정과 컨벤션 인터뷰, 회의·결정·devlog 캡처, raw 소스 ingest, 프로젝트 맥락 query, wiki 품질 lint를 수행한다. 새 프로젝트 설정, 프로젝트 성격·과거 결정·진행 흐름 파악, 기록 저장, 지식 반영, wiki 정합성 점검이 필요할 때 사용."
+---
+
+# /wiki — 프로젝트 지식 수명주기
+
+사용자가 세부 명령을 기억하지 않아도 의도에 따라 모드를 선택한다. 명시된 모드가 있으면 그대로 사용한다.
+
+## 사용자 호출 UX
+
+자연어 요청에서 목적이 명확하면 바로 처리한다.
+
+- “왜 이 구조를 선택했지?” → query
+- “이 결정을 기록해줘” → capture
+- “오늘 작업을 개발 기록으로 남겨줘” → devlog
+
+사용자가 **`/wiki`만 단독으로 호출하면**, 컨벤션 존재 여부, pending raw, 현재 대화를 확인해 가장 적절한 행동을 추천한다.
+
+```text
+아직 프로젝트 컨벤션이 없어서 "프로젝트 초기 설정"을 먼저 하는 게 좋아 보여요.
+
+1. 프로젝트 초기 설정하기 ← 추천
+2. 프로젝트에 관해 질문하기
+3. 회의·결정 기록하기
+4. 오늘 작업 기록하기
+5. 쌓인 원본을 wiki에 반영하기
+6. wiki 상태 점검하기
+
+어떤 걸 할까요? 번호나 원하는 내용을 말해줘도 됩니다.
+```
+
+추천 규칙:
+
+1. 컨벤션이 없으면 초기 설정
+2. pending raw가 있고 작업 마무리 맥락이면 wiki 반영
+3. 질문형 요청이면 프로젝트 질의
+4. 회의·결정이 언급되면 기록
+5. 세션 종료 맥락이면 devlog
+6. 그 외에는 프로젝트 질의를 기본 추천
+
+이미 목적이 명확한 요청에는 메뉴를 보여주지 않는다.
+
+## 내부 모드 라우팅
+
+| 모드 | 대표 의도 | 읽을 참조 |
+|---|---|---|
+| `setup` | 프로젝트 최초 설정, 컨벤션 재정의 | `references/setup.md` + ambiguity 참조 3개 |
+| `capture` | 회의·결정 원문 보존 | `references/capture.md` |
+| `devlog` | 현재 세션 개발 기록 생성 | `references/devlog.md` |
+| `ingest` | pending raw 소스를 wiki에 반영 | `references/ingest.md` |
+| `query` | 프로젝트 성격·결정·기록·진행 상황에 답변 | `references/query.md` |
+| `lint` | 깨진 링크·고아 페이지·모순·stale 정보 점검 | `references/lint.md` |
+
+인자가 없으면 사용자 요청에서 모드를 추론한다. 결과가 둘 이상이면 딱 하나의 짧은 질문으로 확인한다.
+
+## 공통 원칙
+
+- `raw/`는 사람의 원본이다. ingest 상태 필드 외 본문을 수정하지 않는다.
+- `wiki/`는 에이전트가 유지하는 구조화된 지식이다. 사실과 해석을 구분하고 근거를 wikilink로 남긴다.
+- 기존 페이지 갱신을 새 페이지 생성보다 먼저 검토한다.
+- 모순은 한쪽을 지우지 말고 양쪽 출처를 `> ⚠️ 모순` 블록으로 보존한다.
+- 의미 있는 변경 뒤 `wiki/index.md`와 `wiki/log.md`를 동기화한다.
+- Graphify가 설치되어 있고 wiki가 바뀌었으면 `graphify update wiki/`를 실행한다.
+- 사용자가 단순히 프로젝트에 관해 질문하면 명시적 `/wiki query`가 없어도 query 모드로 처리한다.
+
+## setup 추가 참조
+
+setup 모드에서는 다음을 함께 읽는다.
+
+- `references/ambiguity-check.md` — 답변 라우팅
+- `references/clear-path.md` — 명확한 답변 처리
+- `references/unclear-path.md` — 미결정 항목의 기본값·TBD 처리

package/skills/wiki/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Project Wiki"
+  short_description: "프로젝트 설정과 지식 수명주기를 하나로 통합 관리"
+  default_prompt: "Use $wiki to set up or maintain this project's LLM Wiki."

package/skills/wiki/references/ambiguity-check.md

@@ -0,0 +1,16 @@
+# ambiguity-check — Intent Routing 진입점
+
+`wiki setup` 인터뷰의 모든 서브 질문에 적용하는 라우팅 규칙.
+질문을 던지기 **전** 아래 3-way routing으로 처리 경로를 결정한다.
+
+---
+
+## Routing 테이블
+
+| 분류 | 조건 | 참조 |
+|---|---|---|
+| **CLEAR** | 원하는 결과가 명확, 열린 항목은 선호·트레이드오프뿐 | `references/clear-path.md` |
+| **UNCLEAR** | 결과 자체가 모호하거나 아직 미결정 | `references/unclear-path.md` |
+| **FENCE** | CLEAR/UNCLEAR 구분 불명확 | CLEAR로 처리 + 딱 하나의 질문만 |
+
+> CLEAR/UNCLEAR 경계가 애매할 때만 **FENCE**로 분류한다. 진짜 미결정 항목은 UNCLEAR 경로에 남긴다.