@kaydash9999/banker-plugins 0.6.0 → 0.7.0

package/skills/refresh-readme/SKILL.md

@@ -0,0 +1,222 @@
+---
+name: refresh-readme
+description: "(banker) 코드가 움직인 뒤 뒤처진 README 를 현재 프로젝트에 맞게 갱신. 산문 주장을 매니페스트·소스 트리·패키지 매니페스트와 대조해 드리프트를 잡고, 코드펜스·URL·플래그를 보호하며 간결하게 고쳐 쓴다. 'refresh-readme'/'README 갱신·최신화'/'README 가 코드와 안 맞아'/'README 드리프트' 시 사용."
+---
+
+# refresh-readme: README 드리프트 해소 (코드와 문서 정합)
+
+README 는 저장소에서 가장 먼저 읽히면서 가장 늦게 고쳐지는 파일이다.
+코드는 릴리스마다 움직이는데 README 의 산문은 작성 시점에 멈춰 있고, 그 차이는 **어떤 테스트도 잡지 않는다.**
+이 스킬은 그 드리프트를 코드 쪽 사실과 대조해 찾아내고, README 를 현재 프로젝트에 맞게 고쳐 쓴다.
+
+임무는 **정확성**이다. 고쳐 쓸 때의 품질 기준(누락 없이 간결하게, 감탄사·과장·이모지 없이)은
+갱신물이 지켜야 할 조건이지 임무 자체가 아니다. 답변은 한글(기술 토큰·경로·명령은 영문).
+
+**런타임:** 런타임 무관하다. 대상은 저장소 안의 README 파일이고, 필요한 건 파일 읽기·쓰기와 `git`·`grep` 뿐이다.
+Claude Code(OMC)·Codex CLI(OMX) 양쪽에서 동일하게 동작한다.
+**마크다운 파서 라이브러리를 끌어오지 마라.** banker 는 dependencies 0 이다. 대조도 검증도 무의존으로 푼다.
+
+## When to use
+- 코드가 움직였는데 README 가 따라오지 않았을 때: 기능 추가·삭제, 이름 변경, 개수 변화, 명령·경로 변경.
+- 릴리스 직전에 README 의 산문 주장이 실제와 맞는지 확인할 때.
+- README 가 레퍼런스 문서로서 읽기 나쁠 때(감탄사·과장·이모지). 이건 갱신에 딸려 처리한다.
+- 사용자가 `refresh-readme`/`README 갱신`/`README 최신화`/`README 드리프트` 라고 할 때.
+
+## When NOT to use
+- **README 가 아닌 파일.** 범위는 README 파일뿐이다. SKILL.md·CHANGELOG·주석·위키는 밖이다.
+- **코드 슬롭 정리.** `ai-slop-cleaner`(OMC 네이티브) 소관이다. 그건 **코드 전용**이고 자기 문서에서 "clean up formatting" 을 명시적 비적합으로 선언한다. 산문·README 는 대상이 아니다. banker 는 OMC 네이티브를 중복 번들하지 않는다.
+- **영문 산문 윤문.** `humanizer`(banker) 소관이다. 스코프가 **영문 산문**이고 기본 자세가 개성·1인칭 주입이라, 한국어 레퍼런스 문서에는 역행한다. README 가 영문이고 목적이 "읽는 맛"이면 그쪽으로 보내라.
+- **`.gitignore` 정리.** `refresh-git-ignore` 소관이다. 구조가 형제일 뿐 대상 파일이 다르다. 그 스킬은 README 를 보지 않는다.
+- **없는 README 를 새로 쓰는 것.** 이건 드리프트 해소지 작성이 아니다. 초안이 필요하면 별도 지시로 간다.
+
+## 고정 정책 (범위·품질 기준)
+- **대상: README 파일만.** 기본은 저장소 루트 하나. 여러 개면 목록을 제시하고 확인받는다.
+- **사실은 코드에 있다.** README 를 근거로 README 를 고치지 마라. 문서 안에서 아귀가 맞아도 코드와 틀릴 수 있다.
+- **드리프트 판정이 난 문장만 고친다.** 전면 재작성 금지. 문서를 통째로 다시 쓰면 검토 불가능한 diff 가 나오고 그 안에 새 오류가 섞인다.
+- **갱신물의 품질 기준** (고쳐 쓸 때 챙길 조건):
+  - **누락 없이 간결하게.** 사실을 빼서 짧게 만드는 건 간결이 아니라 손실이다.
+  - **유치한 감탄사·과장된 표현 금지.** 과장 형용사가 걸리면 지우는 게 아니라 **사실로 바꾼다.** 그 자리엔 원래 수·이름·조건이 들어갔어야 한다.
+  - **이모지 금지.**
+  - **em dash 같은 ai slop 이 느껴지는 표현도 없어야 한다.** 단 아래 "마커 정직성" 을 먼저 읽어라. 이건 증상 처리지 임무가 아니다.
+- 커밋·push 는 사용자가 명시할 때만.
+
+## 보호 구간 (불가침)
+산문 규칙을 문서 전체에 기계적으로 걸면 **문서화된 명령이 깨지고 한국어 표기가 훼손된다.** 둘 다 가설이 아니라 실재한다.
+
+### 코드: ` -- ` 함정
+안티슬롭 지침은 산문의 이중하이픈(` -- `)을 em dash 대용으로 보고 지우라고 한다.
+그런데 셸에서 ` -- ` 는 POSIX end-of-options 다. 이 저장소에도 그런 줄이 있다:
+
+```
+claude mcp add context7 -s user -- npx -y @upstash/context7-mcp
+```
+
+여기서 ` -- ` 를 지우면 뒤의 `-y` 를 `claude mcp add` 가 자기 옵션으로 먹으려 든다.
+문서화된 MCP 설치 명령이 그대로 죽는다. 저장소 안에서 같은 모양이 여러 건 반복된다.
+
+**산문의 이중하이픈과 이 ` -- ` 는 문자적으로 동일하다.** 정규식으로는 절대 구분되지 않는다.
+**오직 펜스 인지만이 구분한다.**
+
+보호 대상:
+- 코드펜스 안 전부
+- 인라인 코드 안 전부
+- URL (하이픈·이중하이픈이 경로·쿼리에 들어간다)
+- `--flag` 형태의 옵션 (산문에 맨몸으로 나와도)
+- 표 안의 명령·경로 셀
+
+**`sed`/`awk` 일괄 치환은 그 자체로 결함이다.** 펜스 상태를 모르는 도구로 문서 전체를 훑는 순간 위 구분이 사라진다.
+편집은 읽고, 위치를 특정하고, **한 군데씩** 한다. 무엇을 왜 바꿨는지 셀 수 있어야 한다.
+
+### 한국어 표기
+영문 튜닝된 휴리스틱은 한국어 표기에서 오탐한다. 대표가 가운뎃점 U+00B7(`·`)이다.
+한국어 문서는 이걸 나열 구분자로 쓴다(`설계·구현·검증`). 규칙이 이걸 특수문자 슬롭으로 잘못 걸면
+한 군데가 아니라 문서 전역 수십·수백 군데가 한꺼번에 훼손된다.
+
+화이트리스트를 먼저 세운다. 최소한 `·`(나열), `「」`·`『』`(인용·제목), `～`(범위), 전각 괄호·따옴표.
+**한국어 문서에서 관용적으로 쓰이는 구두점은 슬롭이 아니라 표기다.** 지우기 전에 그게 이 문서의 언어에서 정상인지부터 판정한다.
+
+## 마커 정직성
+**단독 em dash 는 AI 증거가 아니다.** em dash 사용은 LLM 보다 훨씬 오래됐고 편집자·기자가 늘 쓴다.
+신호는 **빈도**지 존재가 아니며, 다른 징후와 뭉쳐 나타날 때에만 의미가 있다.
+
+인용 출처도 같은 경고를 한다. Wikipedia 의 "Signs of AI writing"(CC BY-SA)은 이 징후 목록을
+**고쳐야 할 문제로 다루지 말라**고 명시한다. 이유는 품질이 아니라 탐지다: 목록대로 다듬으면 글이 좋아지는 게 아니라 탐지만 어려워진다.
+
+그래서 이 스킬의 프레이밍은 안티슬롭이 아니다. 질문은 하나다: **"이 README 가 정확하고 간결한가."**
+슬롭은 **증상**으로 다룬다. 과장된 형용사는 "AI 티가 난다"라서 고치는 게 아니라 **그 문장이 사실을 안 말하고 있어서** 고친다.
+사실을 말하는 문장이 우연히 마커를 하나 밟았다면 그건 고칠 대상이 아니다.
+
+**마커 목록을 여기에 옮겨 적지 마라.** `humanizer` 가 이미 그 목록을 갖고 있고, humanizer 자신도 그 안에서 갈라져 있다
+(한 곳은 em dash 를 hard constraint 라 하고, 다른 곳은 단독 em dash 는 증거가 아니라고 한다).
+여기서 재서술하면 banker 가 **서로 모순되는 사본 3개**를 지게 된다. 마커 판단이 필요하면 humanizer 를 읽고 위임한다.
+
+## 워크플로
+
+### 0. 대상 확정
+```bash
+git rev-parse --show-toplevel
+git ls-files | grep -i 'readme'
+```
+- 기본 대상은 저장소 루트의 README 하나다.
+- 여러 개면(모노레포 패키지별 등) 목록을 제시하고 **어느 것을 갱신할지 확인받는다.** 전부 훑어 diff 를 부풀리지 마라.
+- README 가 없으면 여기서 멈춘다. 작성은 이 스킬이 아니다.
+
+### 1. 산문 주장 추출 (README 쪽)
+README 를 **끝까지 읽고** 검증 가능한 주장을 뽑는다. 주장 = 사실이 뒷받침해야 하는 문장.
+- **수량**: 개수·버전·크기
+- **고유명**: 스킬·커맨드·모듈·명령 이름
+- **경로**: 파일·디렉터리
+- **동작**: 설치·실행 방법
+- **요구사항**: 런타임·의존성
+
+수량 주장은 문서 전역에서 **전부** 찾는다. 한 곳만 고치면 다음 릴리스에 문서 내부끼리 어긋난다.
+```bash
+grep -nE '[0-9]+ *(개|files|skills|commands)' README.md
+```
+
+### 2. 사실 수집 (코드 쪽)
+사실의 위치는 저장소마다 다르다. 판정 기준은 하나다: **빌드·설치·테스트가 실제로 읽는 파일이 사실이다.**
+흔한 곳은 패키지 매니페스트(버전·의존성·엔트리포인트·스크립트), 배포 매니페스트(실제로 배포되는 표면 목록),
+소스 트리(디렉터리와 파일이 곧 사실), CI 설정(실제로 도는 명령).
+
+이 계열 저장소의 예:
+```bash
+ls -d skills/*/ | wc -l              # 디렉터리 수. 이게 스킬 수라고 단정하지 마라
+ls -d skills/*/SKILL.md | wc -l      # 런타임이 실제로 세는 것
+node -e "const m=require('./codex/manifest.json');console.log(m.surfaces.filter(s=>s.type==='skill').length)"
+node -e "const p=require('./package.json');console.log(p.version, JSON.stringify(p.dependencies||{}))"
+```
+
+**앞의 두 줄이 갈리면 그 차이가 사실이다.** 이 저장소에서 실제로 갈린다: 디렉터리는 49 인데 `SKILL.md` 보유는 48 이다.
+`skills/ultra-init-workspace/` 는 런타임 산출물 디렉터리라 `SKILL.md` 가 없고, 그래서 배포 매니페스트에도 없고 `package.json` `files[]` 도 negation 으로 뺀다.
+즉 "디렉터리를 세면 스킬 수" 라는 그럴듯한 가정이 **여기서 1 을 더 센다.** 세 곳(매니페스트·`files[]`·테스트의 `SKILL.md` 필터)이 이미 48 을 말하는데 디렉터리 카운트만 49 라면, 틀린 쪽은 카운트다.
+
+**README 는 어떤 경우에도 사실이 아니다. 그리고 사실을 세는 명령도 틀릴 수 있다. 세 소스가 같은 값을 말할 때만 통과다.**
+
+### 3. 대조 (삼각검증)
+이 대조가 이 스킬의 **유일한 신규 능력**이다. 나머지(문체·슬롭)는 다른 스킬이 이미 한다.
+주장마다 사실을 붙여 표로 만든다. 산문 주장 ↔ 매니페스트 ↔ 소스 트리가 같은 값을 말해야 통과다.
+
+| README 주장 | 위치 | 코드 사실 | 근거 | 판정 |
+|---|---|---|---|---|
+| "스킬 42개" | 10행·131행 | 48 | `ls -d skills/*/SKILL.md` = 48, 매니페스트 skill 표면 = 48 (디렉터리 카운트는 49 라 셋 중 혼자 다르다) | 드리프트: 2곳 다 고침 |
+| "`--fast` 지원" | 60행 | 없음 | 파서에 해당 플래그 없음 | 드리프트: 문장 삭제 |
+| "Node 18+ 필요" | 20행 | `engines.node: ">=18"` | package.json | 통과 |
+
+(표는 예시다. 주장·사실·근거·판정 4열이 본질이고 행은 그 저장소에서 나온다.)
+
+**흔한 실례:** 산문에 "스킬 N개" 같은 수를 하드코딩해두고 그 수가 **어떤 테스트와도 묶여 있지 않은** 경우다.
+스킬을 하나 추가해도 CI 는 초록이고 README 만 조용히 틀려진다. 릴리스마다 오차가 벌어지지만 아무도 실패를 보지 못한다.
+
+판정은 3종:
+- **통과**: 주장 = 사실.
+- **드리프트**: 주장 ≠ 사실 → 고친다.
+- **Unknown**: 사실 쪽에 대응하는 게 없다 → **지어내지 말고** 사용자에게 올린다.
+
+**대조는 양방향이다.**
+- README 에만 있는 것 = **유령**. 지워진 기능이 문서에 남았다.
+- 코드에만 있는 것 = **누락**. 추가된 기능이 문서에 없다. 이쪽을 더 자주 놓친다. README 를 읽는 것만으로는 절대 안 보이기 때문이다.
+
+### 4. 갱신
+- 3단계에서 **드리프트 판정이 난 문장만** 고친다.
+- 고쳐 쓸 때 위 "고정 정책" 의 품질 기준 4개를 지킨다.
+- 편집은 한 군데씩. 보호 구간을 지난다.
+- 수량 주장은 발견한 **모든 위치**를 같은 커밋에서 고친다.
+
+### 5. 검증 (보고 의무)
+**검증은 재대조다.** 고쳤다는 기억이 아니라 **명령을 다시 돌린 결과**로 판정한다. 라이브러리는 필요 없다.
+
+1. **주장 재대조** (본 검증): 2단계 사실 수집 명령을 **전부 다시 돌려** 갱신된 문장과 맞춘다.
+2. **옛 값 잔존 0**: 수량 주장은 문서 전역이다. 무관한 매치는 눈으로 배제하고, 남은 게 옛 값이면 아직 안 끝났다.
+```bash
+grep -n '42' README.md
+```
+3. **코드 무손상 (필수)**: diff 를 **전수로** 읽는다. 코드펜스·인라인 코드·URL·`--flag` 에 걸린 변경은 **하나도 없어야 한다.** 사실 정정으로 명령 자체가 바뀐 경우가 아니면 전부 회귀다. 하나라도 설명하지 못하면 되돌린다.
+```bash
+git diff -- README.md
+grep -c '^```' README.md   # 갱신 전과 같아야 한다(펜스는 짝수)
+```
+4. **한국어 표기 무손상**: 감소분이 "지운 문장 몫" 으로 설명돼야 한다. 설명되지 않는 감소는 규칙이 오탐한 것이다. 즉시 되돌린다.
+```bash
+grep -c '·' README.md   # 갱신 전 값과 비교
+```
+5. **경로 실재**: MISSING 이 나오면 그것도 드리프트다(파일이 옮겨졌거나 지워졌다).
+```bash
+grep -oE '\]\([^)]+\)' README.md | cut -c3- | cut -d')' -f1 \
+  | grep -vE '^(https?:|#|mailto:)' \
+  | while read -r p; do [ -e "${p%%#*}" ] || echo "MISSING: $p"; done
+```
+6. **품질 기준 자기점검**: 갱신된 문장에 이모지·감탄사·과장이 남았는지 읽는다. 원래 있던 것이라도 이번 범위다.
+
+### 6. 리포트 (4-field)
+**변경 파일**(README 만) / **드리프트 표**(주장 → 사실 → 근거 → 조치) / **검증**(재대조 결과·코드 무손상·표기 카운트 비교) / **Unknown**(코드에 근거가 없어 판정 못 한 주장. 사용자 확인 필요).
+커밋은 "push" 대기로 명시한다.
+
+## 함정
+- **README 를 근거로 README 를 고치는 것.** 문서 안에서 아귀가 맞아도 코드와 틀릴 수 있다. 사실은 항상 코드 쪽에 있다.
+- **`sed`/`awk` 일괄 치환.** 펜스 상태를 모르는 도구는 산문의 이중하이픈과 셸의 ` -- ` 를 구분하지 못한다. 위험이 아니라 결함이다.
+- **누락 방향을 안 보는 것.** README 만 읽으면 "코드에 있는데 문서에 없는 것" 은 절대 안 보인다.
+- **수량 주장을 한 곳만 고치는 것.** 같은 수가 여러 곳에 흩어져 있다. 다음 릴리스엔 문서 내부끼리도 어긋난다.
+- **전면 재작성.** 드리프트 3건을 고치겠다고 문서를 다 다시 쓰면 검토가 불가능해지고 새 오류가 섞인다.
+- **영문 휴리스틱을 한국어에 그대로 거는 것.** `·` 같은 표기가 대량 훼손된다.
+- **마커 목록을 여기서 재서술하는 것.** humanizer 에 위임한다. 사본이 늘면 모순이 늘고, 그 모순은 이미 실재한다.
+- **슬롭 제거를 임무로 착각하는 것.** 임무는 정확성이다. 정확한 문장이 우연히 마커를 밟았다고 고치면 문서만 나빠진다.
+- **파서 라이브러리 도입.** dependencies 0 을 지킨다. 지시문과 `grep` 으로 푼다.
+- **범위 밖 파일에 손대는 것.** SKILL.md·CHANGELOG 는 이 스킬이 아니다.
+- **없는 사실을 지어내 채우는 것.** 코드에 근거가 없으면 Unknown 이다.
+
+## 원칙
+- 임무는 정확성이다. 문체는 갱신물의 품질 기준이지 목적이 아니다.
+- 사실은 코드에 있다. README 는 어떤 경우에도 사실이 아니다.
+- 대조는 양방향이다. 유령과 누락을 같이 본다.
+- 편집은 한 군데씩. 일괄 치환 금지.
+- 보호 구간(펜스·인라인 코드·URL·플래그)은 불가침이다.
+- 한국어 표기는 슬롭이 아니라 표기다. 지우기 전에 언어를 판정한다.
+- 판정은 재대조로 한다. 기억 금지.
+- 근거 없는 주장은 Unknown 으로 올린다. 지어내지 않는다.
+- 마커 판단은 humanizer 소관이다. 여기서 사본을 만들지 않는다.
+- 무의존으로 푼다.
+
+ARGUMENTS: [--check] [README 경로] (없으면 저장소 루트 README 를 대조 → 갱신 → 재대조)
+- `--check`: 아무것도 고치지 않는다. 대조만 돌려 드리프트 표와 Unknown 만 보고한다.
+- README 경로: 대상을 특정한다(모노레포에서 패키지 README 를 지정할 때).

package/skills/summary-wiki/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: summary-wiki
+description: "(banker) 지금까지 쌓인 위키 페이지 전량을 docs/ 아래 단일 파일로 개조식 요약. 사용자가 아는 지식과 위키에 쌓인 내용의 차이를 식별하는 sync 검토용. 읽기 전용이며 stale 한 wiki_list 대신 파일을 직접 열거한다. 'summary-wiki'/'위키 요약'/'위키 지식 동기화'/'위키 digest' 시 사용."
+---
+
+# summary-wiki: 위키 전량을 docs/ 단일 파일로 개조식 요약 (sync 검토용)
+
+위키는 세션을 넘어 쌓이지만, 사용자는 그 안의 무엇이 이미 아는 것이고 무엇이 처음 보는 것인지 알 방법이 없다.
+이 스킬은 지금까지 쌓인 페이지 전부를 `docs/` 아래 **단일 파일**의 개조식 digest 로 접어, 훑는 것만으로 그 경계를 가를 수 있게 한다.
+
+**목적이 형태를 규정한다.** 이건 위키의 축약본이 아니라 **차이를 식별하기 위한 sync 검토 도구**다. 그래서 항목은 훑을 수 있어야 하고, 항목마다 출처가 붙어 원본으로 갈 수 있어야 한다.
+
+여기서 오작동의 대가는 요약이 조금 거친 것이 아니라 **조용한 누락**이다. 한 페이지가 빠져도 digest 는 멀쩡해 보이고 성공으로 보고된다. 사용자는 훑고 나서 "내가 모르는 게 없구나" 라고 결론짓지만, 놓친 페이지가 바로 그 결론이 틀린 이유다. 그래서 아래의 열거 규칙과 읽기 전용 규칙은 편의보다 우선한다. 답변은 한글(기술 토큰·슬러그·경로는 영문).
+
+**런타임:** 위키의 **위치와 접근 경로가 두 런타임에서 다르다.** 이 스킬에서 가장 자주 잘못 복사되는 사실이다.
+
+| | Claude Code (OMC) | Codex CLI (OMX) |
+|---|---|---|
+| 위키 위치 | `.omc/wiki/` | `omx_wiki/` (repo 레벨) |
+| 접근 | `wiki_*` MCP 도구 | `omx wiki <tool> --input <json> --json` CLI |
+| stale 인덱스 대응 | 도구 없음. 파일 직접 열거로 우회 | `wiki_refresh` 있음 |
+
+- **Codex 에 `wiki_*` MCP 는 없다.** 형제 스킬(append_wiki·compact-wiki)의 caveat 문구 "uses wiki_* MCP (OMC/OMX)" 는 **부정확하다. 복사하지 마라.** 정확히는 `Claude = wiki_* MCP on .omc/wiki`, `Codex = omx wiki CLI on omx_wiki/` 다.
+- OMX 의 `wiki_refresh` 는 OMC 에 없다. Codex 에서는 stale 인덱스를 도구로 고칠 수 있다. 다만 그건 완화책이지 이 스킬의 전제가 아니다.
+- **비대칭이 이 스킬을 거의 건드리지 못한다.** 열거를 파일에서 하고(아래 "최대 함정") 본문을 파일 read 로 읽으면, 런타임 차이는 **디렉터리 경로 하나**로 줄어든다. 도구 계층은 여기서 의존 대상이 아니라 우회 대상이다.
+
+## When to use
+- 위키가 여러 세션에 걸쳐 쌓여, 사용자가 그 안에 무엇이 들었는지 더는 파악하지 못할 때.
+- 자리를 비운 사이 에이전트가 기록한 지식을 사람이 따라잡아야 할 때.
+- 사용자가 아는 것과 위키에 쌓인 것의 **차이**를 확인하려 할 때(이 스킬의 본래 목적).
+- 위키 원본은 그대로 두고 훑을 사본만 필요할 때.
+- 사용자가 `summary-wiki`/`위키 요약`/`위키 지식 동기화`/`위키 digest` 라고 할 때.
+
+## When NOT to use
+- **위키를 정리·압축하려 할 때.** 그건 `compact-wiki` 다. 아래 표를 보라.
+- **새 지식을 기록할 때.** `append_wiki` 소관이다.
+- **위키를 Obsidian 그래프로 정규화할 때.** `obsidizer` 소관이다.
+- **사실 하나를 찾을 때.** `wiki_query` 나 grep 이 훨씬 싸다. digest 는 전수 훑기용이지 검색 인덱스가 아니다.
+- **위키가 몇 장 안 될 때.** 원본을 직접 읽는 게 싸다. digest 관리 비용이 본전을 넘는다.
+
+| | summary-wiki | compact-wiki |
+|---|---|---|
+| 위키에 대한 동작 | **읽기 전용** | **제자리 파괴적 변형**(스냅샷 → 병합 ingest → 검증 → 삭제) |
+| 산출물 | `docs/` 아래 별도 digest | 위키 자신 |
+| 페이지 수 | 그대로 | 줄어든다 |
+| 목적 | 사람이 차이를 식별 | 위키의 중복 제거 |
+| 되돌리기 | 파일 지우면 끝 | 백업에서 복원 |
+
+둘을 섞지 마라. digest 를 만들다 "이왕 읽는 김에" 중복을 합치기 시작하면 그건 compact-wiki 이고, 이 스킬의 읽기 전용 보장이 그 자리에서 깨진다.
+
+## 최대 함정: `wiki_list` 를 쓰지 마라
+
+`wiki_list` 는 위키를 열거하지 않는다. **stale 한 `index.md` 를 읽는다.** 도구 설명이 그렇게 자백한다("Reads the auto-maintained index").
+
+- 실측: 같은 시점 `wiki_list` = 16, `wiki_lint` = 17. 한 페이지가 목록에 없었다.
+- `index.md` 는 **구조적으로 stale 하다.** 인덱스 갱신이 특정 경로에서만 일어나고, SessionStart 재생성은 파일이 **물리적으로 없을 때만** 걸린다. 즉 아무도 staleness 를 검사하지 않는다. 낡은 인덱스는 존재한다는 이유만으로 살아남는다.
+- **이 누락은 조용히 성공을 보고하며 이 스킬의 목적을 정확히 배반한다.** digest 는 완전해 보이고, 사용자는 그걸 근거로 모르는 게 없다고 결론짓는다.
+
+→ **파일을 직접 열거한다.** 예약파일 3종(`index.md`·`log.md`·`environment.md`)은 지식 페이지가 아니므로 제외한다.
+
+```bash
+W=.omc/wiki    # Codex(OMX) 면 omx_wiki
+ls "$W"/*.md | grep -vE '/(index|log|environment)\.md$'
+```
+
+`wiki_lint` 는 열거가 아니라 **대조**에 쓴다(4단계). `wiki_list` 와는 대조조차 하지 마라. stale 한 쪽이라 맞으면 헛된 안심을, 틀리면 혼란만 준다.
+
+## 읽기 전용 (협상 대상 아님)
+
+이 스킬은 **위키에 쓰지 않는다.** 예의가 아니라 쓰기가 손실을 내기 때문이다.
+
+- OMC 위키의 프론트매터는 **READ 시점에 9-key 로 절단된다.** 페이지를 읽어 되쓰는 순간 그 9개 밖의 필드는 사라진다. 읽고 쓰는 왕복 자체가 파괴적이다.
+- 그러므로 digest 를 만들려고 위키를 손대는 모든 동작이 금지다. 태그 정리도, 링크 보수도, 오타 수정도 여기서는 하지 않는다. 눈에 띄면 **보고만 한다.**
+- **digest 를 위키 안에 두지 마라.** 위키의 일부가 되는 순간 다음 digest 의 입력이 되어 자기를 요약하기 시작한다. 산출물은 언제나 위키 밖(`docs/`)이다.
+
+## 제목은 파일명에서 복원되지 않는다
+
+슬러그는 64자에서 잘린다. **잘린 자리는 표시되지 않는다.**
+
+- 실례: `claude-code-context-usage-signals-and-compaction-automation-ceil.md` 의 실제 제목은 `Claude Code Context Usage Signals And Compaction Automation Ceiling` 이다. 파일명만 보면 `ceil` 이 원래 단어인지 잘린 조각인지 알 수 없다.
+- 파일명을 되돌려 제목을 짓지 마라. 하이픈을 공백으로 바꾸고 첫 글자를 올리는 복원은 **틀린 제목을 자신 있게 만들어낸다.**
+- **제목은 프론트매터 `title:` 에서 읽는다.** 없으면 본문 H1. 둘 다 없을 때만 슬러그를 쓰고, **추정임을 표시한다.**
+
+## 출처 표기
+
+digest 의 모든 항목에는 원본으로 돌아갈 경로가 붙는다. 출처 없는 항목은 검증할 수 없어 sync 검토에 쓸모가 없다.
+
+**`[[slug|제목]]` piped 형식을 쓰지 마라.** OMC 는 링크의 inner text 전체를 슬러그화해 존재하지 않는 슬러그를 주조한다. digest 가 `.omc/wiki/` 밖에 있으면 이 주조 자체는 발화하지 않지만, 그 대신 링크가 클릭되지 않거나 404 가 된다. 어느 쪽이든 이득이 없다.
+
+→ **슬러그 텍스트 + 파일 경로 문자열**로 둔다.
+
+- 좋음: `omc-wiki-storage-internals-and-their-traps` / `.omc/wiki/omc-wiki-storage-internals-and-their-traps.md`
+- 나쁨: `[[omc-wiki-storage-internals-and-their-traps|OMC Wiki Storage Internals]]`
+
+출처는 **페이지 절 헤더 아래 한 줄**이면 충분하다. 그 절의 항목들은 페이지 단위로 이미 출처가 붙은 것이다. 항목마다 반복하지 마라.
+
+## 개조식 (관행이지 규정이 아니다)
+
+먼저 정직하게. **`개조식` 은 어문규범이나 행정업무운영 편람에 명명된 문체로 규정되어 있지 않다.** 규범화된 것은 둘뿐이다.
+
+- 마침표 규정: 명사·명사형으로 끝나는 문장 뒤의 마침표는 **원칙이되 생략을 허용**한다. 찍어도 안 찍어도 적법하다. 한 문서 안에서 **일관되기만** 하면 된다.
+- 편람의 항목 구분 체계: 항목 기호와 들여쓰기의 층위.
+
+그러므로 이 절은 **"규정 준수" 가 아니라 "관행 준수"** 다. 규정이라고 말하지 마라. 없는 권위를 빌리는 것이다.
+
+### 형태 규칙
+
+관행으로서의 개조식이 요구하는 것은 불릿이 아니라 **압축**이다.
+
+- **한 항목 한 사실.** 두 사실이면 두 항목으로 쪼갠다.
+- **명사·명사형으로 종결한다.** 서술형 종결(`-다`·`-습니다`)은 쓰지 않는다.
+- **마침표는 문서 전체에서 한 방식으로.** 찍든 안 찍든 섞지 않는다.
+- **중첩은 2단까지.** 3단 이상은 공문서 관행을 벗어나고, 훑기라는 목적도 함께 깨진다.
+- 수식·완충 표현을 걷어낸다. 남는 것은 사실과 출처다.
+
+### 실패 모드: 불릿만 다는 것
+
+"개조식으로 써" 라는 지시를 받으면 문장 앞에 `- ` 를 붙이고 끝내는 쪽으로 수렴하기 쉽다. **그건 개조식이 아니라 줄바꿈이다.**
+
+나쁨:
+
+```
+- 위키 인덱스는 자동으로 유지되는 것처럼 보이지만 실제로는 특정 경로에서만 갱신되기 때문에 오래된 상태로 남아 있을 수 있습니다.
+```
+
+좋음:
+
+```
+- wiki_list 는 위키가 아니라 index.md 를 읽음
+- index.md 갱신 경로가 제한적이라 구조적으로 stale
+- 실측: wiki_list 16 vs wiki_lint 17
+```
+
+나쁨 쪽이 무엇을 하는지 보라. 서술형 종결, 한 항목에 세 사실, 완충 표현("것처럼 보이지만", "수 있습니다"). 훑을 수 없고, 어느 부분이 새 정보인지 가릴 수 없다. 좋음 쪽은 세 항목이 각각 독립적으로 참·거짓을 가릴 수 있고, 사용자가 셋 중 아는 것만 건너뛸 수 있다. **그 건너뛰기가 이 스킬의 값어치 전부다.**
+
+## 워크플로
+
+### 0. 열거 (추정 금지)
+어떤 런타임의 위키인지 먼저 판정하고, 파일을 직접 열거한다. 여기서 찍은 값이 4단계 검증의 before 다.
+
+```bash
+W=.omc/wiki; [ -d "$W" ] || W=omx_wiki; echo "wiki: $W"
+PAGES=$(ls "$W"/*.md | grep -vE '/(index|log|environment)\.md$')
+echo "$PAGES" | wc -l                    # 페이지 수
+echo "$PAGES" | xargs cksum | cksum      # 위키 지문. 4단계에서 이 값과 대조한다.
+```
+
+- 두 디렉터리가 다 없으면 위키가 없는 것이다. 만들지 마라. 요약할 게 없다고 보고하고 끝낸다.
+- 지문(`cksum`)은 읽기 전용을 **주장이 아니라 관측**으로 만들기 위한 것이다. 나중에 같은 값이 나와야 한다.
+
+### 1. 읽기
+제목은 프론트매터 `title:` 에서, 항목은 본문에서 읽는다. 파일명에서 추론하지 마라.
+
+**비용 함정:** 페이지 전량 full read 는 컨텍스트를 크게 먹는다. 위키가 커진 뒤에는 digest 를 만드는 행위가 **정작 compaction 을 유발할 수 있다.** 요약하려다 요약당하는 것이다.
+
+- 페이지 수와 총 크기를 먼저 재고, 큰 경우 사용자에게 알린 뒤 진행한다.
+  ```bash
+  echo "$PAGES" | xargs du -ch | tail -1
+  ```
+- 크면 `--pages` 로 범위를 좁힌다. 다만 **좁혔다는 사실을 digest 헤더에 적는다.** 부분 digest 를 전수 digest 로 보이게 두면 이 스킬의 실패 모드(조용한 누락)를 인자로 재현하는 것이다.
+- **읽지 않은 페이지는 digest 에 넣지 않는다.** 제목만 보고 항목을 지어내는 것이 여기서 가장 나쁜 실패다. 지어낸 항목도 그럴듯해 보이고, 사용자는 그걸 "아는 것" 으로 분류해 넘긴다.
+
+### 2. 자리 잡기 (docs/ 와 .gitignore)
+산출물은 타깃 repo 의 `docs/wiki-digest.md` 단일 파일이다. `docs/` 가 없으면 만든다.
+
+**왜 `.gitignore` 인가:** 위키는 `.omc/`(Codex 면 `omx_wiki/`) 아래에 있다. 로컬 전용이고 보안 감사 대상 밖이다. 즉 위키 내용은 **공개를 전제로 쓰이지 않았고 시크릿 스캔을 거친 적도 없다.** digest 를 tracked 파일로 올리는 순간 그 내용이 공개 repo 로 승격된다. 승격은 조용하고, 히스토리에 남아 되돌리기 어렵다.
+
+```
+# summary-wiki: local wiki digest (wiki is local-only and never audited for publication)
+docs/wiki-digest.md
+```
+
+- **`.gitignore` 는 그 프로젝트의 파일이지 우리가 만든 게 아니다.** 무엇을 왜 추가하는지 사용자에게 한 줄로 알리고 진행한다.
+- **멱등하게.** 이미 무시되고 있으면(상위 규칙·`docs/` 통째 무시 등) 추가하지 않는다.
+  ```bash
+  git check-ignore -q docs/wiki-digest.md && echo "이미 무시됨: 추가 불필요"
+  ```
+- git repo 가 아니면(`git rev-parse --git-dir` 실패) 이 단계를 건너뛴다. 에러가 아니다.
+- 사용자가 digest 를 커밋 대상으로 원한다고 **명시하면** 그건 사용자의 repo 다. 추가하지 않는다. 대신 4단계 시크릿 스캔을 그때 더더욱 건너뛰지 마라.
+
+### 3. digest 렌더
+단일 파일. 페이지당 한 절. 절마다 개조식 항목.
+
+```markdown
+# wiki digest
+
+- 대상: `.omc/wiki/` (Claude/OMC)
+- 페이지: 17 (예약파일 3종 제외)
+- 열거: 파일 직접 열거 (`wiki_list` 미사용)
+- 생성: 2026-07-16
+
+## OMC Wiki Storage Internals And Their Traps
+`omc-wiki-storage-internals-and-their-traps` / `.omc/wiki/omc-wiki-storage-internals-and-their-traps.md`
+
+- 프론트매터는 READ 시점에 9-key 로 절단됨
+- 슬러그 cap 64자. 파일명에서 제목 복원 불가
+- index.md 는 갱신 경로가 제한적이라 구조적으로 stale
+- 실측: wiki_list 16 vs wiki_lint 17
+```
+
+- **절 헤더의 제목은 프론트매터 `title:` 값 그대로.** 번역하거나 다듬지 마라. 원본과 문자열이 같아야 사용자가 대조할 수 있다.
+- 헤더 바로 아래 한 줄에 **슬러그와 파일 경로.** 그 절의 출처는 이걸로 끝이다.
+- 항목은 **그 페이지에서 실제로 알 수 있는 것**만. 목차를 옮기는 게 아니다. "설정 방법을 설명함" 은 항목이 아니다. 그런 항목만 늘어놓은 digest 는 훑어도 아는 것과 모르는 것이 갈리지 않아 목적을 달성하지 못한다.
+- 페이지 순서는 열거 순서(사전순) 그대로. **중요도로 재정렬하지 마라.** 재정렬은 판단이고, 판단은 사용자 몫이다.
+- 헤더의 메타(대상·페이지 수·열거 방식·생성일)를 **지우지 마라.** 이 digest 가 무엇을 근거로 완전하다고 주장하는지가 거기 있다.
+- 생성일은 `date +%F` 로 찍는다. 추측 금지.
+
+### 4. 검증 (보고 의무)
+**digest 를 썼다는 사실로 성공을 선언하지 마라.** 파일은 언제나 써진다. 한 페이지가 빠진 digest 도 똑같이 잘 써지고 똑같이 완전해 보인다.
+
+**시크릿 스캔이 먼저다(게이트).** 통과 전에는 경로를 사용자에게 알리지도, 파일을 다른 곳으로 옮기지도 마라.
+- digest 에 키·토큰·자격증명·내부 호스트·개인정보가 실렸는지 본다. 위키는 감사받은 적이 없으므로 **깨끗하다고 가정할 근거가 없다.**
+- 하나라도 나오면 digest 에서 지우고 **그 자리에 원본 경로만 남긴다.** 사용자는 원본으로 가면 된다. digest 가 사본을 만들 이유가 없다.
+
+**개수 대조.** 열거 수와 digest 의 절 개수가 같아야 한다.
+```bash
+echo "$PAGES" | wc -l                    # 열거 수
+grep -c '^## ' docs/wiki-digest.md       # digest 절 수
+```
+다르면 digest 는 미완성이다. 차액을 찾아 채우기 전까지 보고하지 마라.
+
+**위키 무변경 확인.** 0단계 지문과 같아야 한다.
+```bash
+echo "$PAGES" | xargs cksum | cksum      # 0단계 값과 동일해야 한다
+```
+
+체크리스트. 하나라도 아니오면 고치고 다시 본다.
+- 절 개수 == 열거 수인가.
+- 예약파일 3종이 절로 섞여 들어가지 않았는가.
+- 절 헤더 제목이 **원본 `title:` 과 문자열이 같은가.** 파일명에서 복원한 제목이 하나라도 있으면 틀렸다.
+- 모든 절에 슬러그와 파일 경로가 붙었는가.
+- `[[...|...]]` piped 링크가 0인가.
+- 서술형 종결(`-다`·`-습니다`)이 항목에 남지 않았는가. 마침표 방식이 문서 전체에서 일관된가.
+- 3단 이상 중첩이 없는가.
+- 지문이 0단계와 같은가. **다르면 위키를 건드린 것이다.** 무엇을 바꿨는지 찾아 되돌린다.
+
+사용자에게는 파일 경로와 **한 줄 요약**을 준다. 파일을 열게 하지 마라.
+
+```
+docs/wiki-digest.md: 17 페이지 요약(예약 3종 제외, 파일 직접 열거). 위키 무변경(지문 일치). 시크릿 스캔 통과.
+```
+
+## 함정
+- **`wiki_list` 로 열거하는 것.** 이 스킬에서 지식이 조용히 사라지는 유일하고 실재하는 경로다. `index.md` 는 구조적으로 stale 하고 아무도 그 사실을 검사하지 않는다.
+- **예약파일을 지식 페이지로 세는 것.** `index.md`·`log.md`·`environment.md` 를 세면 개수 대조가 통과하면서 실제로는 틀린다.
+- **파일명에서 제목을 복원하는 것.** 64자에서 잘린 슬러그는 자기가 잘렸다고 말하지 않는다.
+- **digest 를 만들며 위키를 손보는 것.** 프론트매터가 READ 왕복만으로 9-key 로 절단된다. 눈에 띈 문제는 보고만 한다.
+- **digest 를 위키 안에 두는 것.** 다음 digest 의 입력이 되어 자기를 요약하기 시작한다.
+- **`[[slug|제목]]` 을 쓰는 것.** 유령 슬러그를 주조하거나(위키 안) 404 를 만든다(위키 밖).
+- **개조식을 불릿으로 오해하는 것.** 문장 앞에 `- ` 를 붙이는 건 줄바꿈이지 압축이 아니다.
+- **개조식을 규정이라고 말하는 것.** 규범화된 것은 마침표 규정과 편람의 항목 체계뿐이다.
+- **마침표 유무를 문서 안에서 섞는 것.** 둘 다 적법하지만 섞는 것은 아니다.
+- **페이지를 안 읽고 제목만으로 항목을 쓰는 것.** 지어낸 항목도 그럴듯해 보인다.
+- **부분 digest 를 전수 digest 처럼 두는 것.** 범위를 좁혔으면 헤더에 적는다.
+- **digest 를 tracked 로 올리는 것.** 감사받은 적 없는 로컬 전용 내용이 공개 repo 로 승격된다.
+- **caveat 를 형제 스킬에서 복사하는 것.** Codex 에 `wiki_*` MCP 는 없다.
+- **전량 read 의 비용을 무시하는 것.** 요약하려다 compaction 을 유발할 수 있다.
+- **compact-wiki 로 미끄러지는 것.** 읽는 김에 합치기 시작하면 읽기 전용 보장이 깨진다.
+- **파일을 썼다는 사실로 완료를 선언하는 것.** 판정은 개수 대조와 지문 대조다.
+
+## 원칙
+- 열거는 파일에서 한다. 인덱스는 위키가 아니다.
+- 위키에 쓰지 않는다. 산출물은 위키 밖 단일 파일이다.
+- 제목은 프론트매터에서, 항목은 본문에서. 파일명은 경로일 뿐 근거가 아니다.
+- 모든 항목은 원본으로 돌아갈 수 있어야 한다. 출처 없는 항목은 sync 검토에 쓸모가 없다.
+- 개조식은 관행이지 규정이 아니다. 관행으로서 지키고, 규정이라 말하지 않는다.
+- 형태의 근거는 목적이다. 훑어서 아는 것과 모르는 것이 갈려야 한다. 안 갈리면 형식이 틀린 것이다.
+- 판정은 관측으로 한다. 개수와 지문을 대조하기 전에는 완료가 아니다.
+- 감사받지 않은 내용을 공개 경로로 승격하지 않는다.
+- 읽지 않은 것은 쓰지 않는다.
+
+ARGUMENTS: [--out <파일>] [--pages <slug,...>] [--dir <위키경로>] (없으면 `.omc/wiki/`(Codex 면 `omx_wiki/`) 전량을 `docs/wiki-digest.md` 로 요약)
+- `--out <파일>`: 산출 경로를 바꾼다. `.gitignore` 게이트와 시크릿 스캔은 그 경로에 그대로 적용한다.
+- `--pages <slug,...>`: 지정한 페이지만 요약한다. **범위를 좁혔다는 사실을 digest 헤더에 적는다.** 적지 않으면 부분 digest 가 전수 digest 로 읽힌다.
+- `--dir <위키경로>`: 위키 위치를 직접 지정한다. 자동 판정은 `.omc/wiki/` → `omx_wiki/` 순으로 존재하는 쪽이다.
+- 어느 경우에도 `wiki_list` 는 쓰지 않는다. 열거는 언제나 파일 직접 열거다.