Repository analysis · 한국어 · 2026-08-29

Paperthin은 어떻게 에이전트의 “반사 동작”을 설계하는가

GitHub 저장소 LilMGenius/paperthin의 v0.17.4 스냅샷을 기준으로, 28개 하네스 스킬 전부와 그 존재 이유, 호출 권한, 상호 오케스트레이션, 실제 코드가 보장하는 범위를 추적한 해설서입니다.

version 0.17.4commit 3bca07928 skillsMITplain Markdown harness
Executive summary

한 문장 결론

Paperthin은 범용 에이전트 런타임이 아니라, 에이전트 하네스가 읽고 따르는 “선언형 작업 패턴 라이브러리”입니다. 핵심 제품은 28개의 SKILL.md이고, JavaScript·Shell 코드는 설치 상태 알림과 카탈로그 정합성 검증을 보조합니다. 따라서 오케스트레이션 대부분은 코드 호출 그래프가 아니라 자연어로 적힌 /skill 호출 규약과 모델의 준수에 의해 실행됩니다.
28전체 스킬
16모델도 자동 호출 가능
12사람만 명시 호출
4관점 축: depth/breadth/coil/mesh

문제 정의

에이전트가 기본적으로 파일·옵션·설명을 계속 덧붙여 “그럴듯하지만 유지 불가능한 slop”을 만든다는 전제에서 출발합니다. 모든 스킬이 무언가를 줄이거나, 검증하거나, 분리하거나, 다음 사이클로 학습을 정제하도록 설계됐습니다.

중심 철학

저자를 믿지 말고 아티팩트를 믿어라. 작성자의 세션 기억과 자신감 대신, 현재 파일·외부 근거·낯선 독자·독립 관점으로 결과를 재검증합니다. “개선점이 없으면 아무것도 바꾸지 않는다”는 절제가 제품의 일부입니다.

Conceptual map

왜 네 개의 관점으로 나눴나

분류축은 대상 개수(cardinality) × 시간(time)입니다. 도메인별 플러그인 분리 대신 “지금 무엇을 어떤 범위에서 보느냐”를 폴더 구조로 고정해, 새 스킬의 위치를 기능명이 아니라 트리거 범위로 결정합니다.

depth/ · 하나 × 지금

손에 든 한 아티팩트를 정리·검증·압박합니다. 19개로 가장 큽니다.

breadth/ · 여럿 × 지금

여러 파일·플랫폼에 퍼진 하나의 진실이나 설치 상태를 수렴시킵니다. 2개입니다.

coil/ · 하나 × 여러 사이클

한 프로젝트의 학습, 재시작, 재진입, 다음 행동을 시간에 걸쳐 운반합니다. 6개입니다.

mesh/ · 여러 관점 × 여러 라운드

서로 다른 렌즈가 어디서 갈라지는지 보여 줍니다. 현재 prism 1개입니다.

이 분류는 의존성 계층이 아닙니다. 예를 들어 sip은 depth에 있지만 breadth의 ssotize를 호출합니다. 폴더는 “무엇을 호출하는가”가 아니라 “이 스킬이 직접 다루는 트리거/산출물의 범위”를 뜻합니다.
Architecture

실제로 실행되는 것과 프롬프트로 약속된 것

1. 선언 계층 — 제품의 본체

skills/<perspective>/<name>/SKILL.md가 이름, 자동 호출용 설명, Goal, Workflow, Rules, Verification을 담습니다. 모델은 이 문서를 읽고 작업 절차를 수행합니다. 별도의 타입 시스템, DAG 실행기, 상태 머신 엔진은 없습니다.

호출 표식

disable-model-invocation: true가 있으면 인간 전용입니다. 없으면 모델과 인간 모두 호출할 수 있습니다.

2. 등록 계층

.claude-plugin/plugin.json이 28개 경로와 순서를 등록합니다. npx skills add 설치도 문서화되어 있습니다.

3. 발견 계층

catalog.cjs가 설치 폴더를 읽고 빠진 스킬을 계산합니다. SessionStart/OpenCode 어댑터가 하루 한 번 모델 컨텍스트에 업그레이드 안내를 주입합니다.

4. 검증 계층

GitHub Actions가 구조, 링크, 스킬 참조, 카탈로그 복제본, 배포 홈을 검사하고 태그 릴리스 시 npm publish와 GitHub Release를 수행합니다.

저장소 구조

paperthin/ ├─ skills/ │ ├─ depth/ # 19: 한 아티팩트의 정리·검증·출하 │ ├─ breadth/ # 2: 여러 위치의 수렴 │ ├─ coil/ # 6: 반복 사이클의 학습·재진입 │ └─ mesh/ # 1: 독립 관점의 충돌 ├─ scripts/ # 카탈로그/발견 알림/정합성 검사 ├─ docs/readme/ # 10개 언어 번역본 ├─ .claude-plugin/plugin.json ├─ .github/workflows/{ci,release}.yml ├─ CLAUDE.md # 기여자·에이전트용 메커니즘 규약 ├─ README.md # 사용자용 카탈로그와 설명 └─ package.json # v0.17.4, npm 배포 메타데이터
Full catalog

28개 스킬 전수 해설

각 카드는 “무엇을 하는가”뿐 아니라 왜 별도 스킬로 존재하는가와 어디에 연결되는지를 요약합니다. 검색하거나 관점/호출 방식으로 필터링할 수 있습니다.

re0

MODEL

드리프트된 기존 아티팩트를 패치 흔적 없는 현재의 깨끗한 v0로 다시 씁니다.

이유
누적 수정은 과거·중복·과설명을 보존하기 때문.
핵심
끝까지 읽기 → 인접 진실 확인 → 잔여물 제거 → 냉독.
연결
sip의 마지막 정리 단계, drift 시 debloat에서 인계.
원문 SKILL.md

readchk

MODEL · READ

큰 비용을 쓰기 전에 사용자의 지시를 실제로 이해했는지 확인합니다.

이유
잘못 읽은 요청도 내부적으로는 그럴듯하게 완성될 수 있음.
핵심
내부 재진술 → 문맥 교차검증 → 진짜 갈림길만 질문.
연결
re0-plan이 full cycle의 이해 확인에 사용.
원문 SKILL.md

aim

MODEL · READ

얇은 요청과 큰 데이터 덩어리가 왔을 때 질문 대신 사용자의 의도를 먼저 제안합니다.

이유
사용자가 처음부터 요청 문장을 재작성하는 부담을 없앰.
핵심
전부 읽기 → 한 의도 제안 → 다음 일 제시 → 확인만 받기.
연결
nba와 반대편 페어: 인계 데이터에서 의도 vs 현재 상태에서 다음 행동.
원문 SKILL.md

modelchk

MODEL · READ

작업에 충분한 최저 capability tier와 reasoning effort를 중립 척도로 추천합니다.

이유
강한 모델을 무조건 쓰거나 값싼 모델로 위험 작업을 수행하는 낭비를 줄임.
핵심
fast/standard/frontier × glance/measured/thorough/exhaustive.
연결
re0-plan의 사이클 크기 산정; 실제 라우팅 권한은 없음.
원문 SKILL.md

hate

USER

계획을 죽일 수 있는 단 하나의 핵심 반론과 가장 싼 반증 실험을 반환합니다.

이유
체크리스트식 비판은 결정적인 실패 원인을 희석함.
핵심
load-bearing 가정 → 여러 공격축 → root 1개 → first nail 1개.
연결
re0-loop의 HATE 단계에서 인간이 명시 호출할 수 있음.
원문 SKILL.md

macrothink

USER · READ

세션의 프레이밍을 걷어낸 뒤 2~5개의 fresh read를 펼쳐 divergence부터 보여 줍니다.

이유
첫 답과 예시가 전체 탐색 공간을 잠식하는 터널비전을 깨기 위해.
핵심
stripped prompt → 기본 3개 독립 읽기 → 충돌을 root로 군집화.
연결
prism과 보완 페어; re0-plan에서 쟁점이 클 때 선택.
원문 SKILL.md

feynman

USER · READ

막 내린 결정을 사용자가 자기 말로 설명할 때까지 fresh critic이 빈틈을 하나씩 압박합니다.

이유
선택 직후에는 이해 없이도 옵션의 설명을 유창하게 반복하기 쉬움.
핵심
근거 없는 결정만 critic에 전달 → 한 gap씩 좁힘 → 미해결은 재검토 플래그.
연결
별도 context-free sub-session을 필수로 사용.
원문 SKILL.md

autobahn

MODEL

위험 인접 범위를 먼저 도려내고, 안전한 프롬프트만 본 새 서브에이전트가 나머지를 전력 실행합니다.

이유
위험한 일부 때문에 안전한 전체 결과까지 과도하게 축소되는 현상을 방지.
핵심
FRAME → CARVE → GUARD → clean RUN → 독립 재검사 → LEDGER.
연결
새 context subagent 필수; 제외물은 실행 종료 후 negative corpus로 기록.
원문 SKILL.md

reorder

USER

목록을 한 가지 명시된 원칙으로 재배열하되 내용은 한 글자도 고치지 않습니다.

이유
순서 자체가 정보이며, 항목 추가 순서가 의미 순서를 망가뜨림.
핵심
원칙 선택 → kin 군집화 → 이동만 → 미러 사본 동일 순서.
연결
README·plugin·catalog의 수동 순서 동기화에 사용.
원문 SKILL.md

detool

MODEL

장수해야 할 문서에 우연히 박힌 모델·벤더·CLI 이름을 실제 메커니즘으로 바꿉니다.

이유
도구명이 절차 그 자체로 굳으면 스택 변경 시 문서가 거짓이 됨.
핵심
역할 판정 → portable 영역만 중립화 → provenance/runbook은 구체적으로 유지.
연결
sip이 이식성 주장을 하는 아티팩트에 조건부 호출.
원문 SKILL.md

dedash

USER

em dash 역할을 하는 대시를 문맥별 쉼표·괄호·콜론·접속사로 교정합니다.

이유
일괄 치환은 range·minus·의도적 문체까지 훼손함.
핵심
역할별 판정, 사용자 지정 범위 고정, occurrence 단위 편집.
연결
공통 edit-safety 규약을 공유하지만 독립 문체 도구.
원문 SKILL.md

debloat

USER

의미는 맞지만 부풀어 오른 글을 load-bearing density까지 압축합니다.

이유
패딩·중복·벽 같은 열거가 정확한 문서도 읽기 어렵게 만듦.
핵심
필수 주장 고정 → 군더더기만 절단 → 구조·목소리 유지.
연결
중복이면 ssotize, drift면 re0로 인계.
원문 SKILL.md

shower

MODEL · READ

아티팩트 내용만 fresh sub-session에 넘겨 맥락 없는 독자가 이해하는지 냉독합니다.

이유
장기 세션의 작성자는 이미 아는 맥락을 잊을 수 없음.
핵심
의도는 숨김 → 블라인드 이해 보고 → 원래 의도와 비교.
연결
sip, re0-release, re0-merge의 첫 QA 관문.
원문 SKILL.md

factchk

MODEL

현실 주장에 대해 “이상해 보여도 사실인가 / 당연해 보여도 거짓인가”를 양방향 외부 검증합니다.

이유
사람과 모델의 상식은 현실을 두 방향 모두에서 오판함.
핵심
외부 소스 → 명백 오류는 수정, 해석 쟁점은 플래그.
연결
sip·re0-release에서 현실 주장이 있을 때만 호출.
원문 SKILL.md

mandela

MODEL · READ

평가·지표·실험에 외부 ground truth가 독립적으로 들어오는지 8가지 leakage 패턴으로 감사합니다.

이유
모델·설계자·채점기가 서로 만든 답을 검증하면 깨끗한 숫자도 순환논증임.
핵심
구성요소 분해 → 8패턴 검사 → 발화한 패턴과 independence fix만 반환.
연결
sip의 eval 조건부 검사; 고위험이면 독립 auditor N=1.
원문 SKILL.md

sip

MODEL · ORCH

방금 만든 결과를 이 저장소 자체의 clean-and-true 스킬 체인으로 맛봅니다.

이유
“완료 전에 검증”이라는 문구는 새 세션에서 자동으로 발화하지 않음.
핵심
shower → factchk/mandela → ssotize(audit) → detool → re0.
연결
대표 모델 호출 오케스트레이터; 사람 전용 스킬은 호출 금지.
원문 SKILL.md

re0-git

USER

이미 존재하는 커밋의 메시지만 저장소 문체와 commit-economy에 맞춰 다시 씁니다.

이유
git log만으로 다음 세션이 인계받게 하고, 커밋 유도 편향은 막음.
핵심
diff·주변 로그 읽기 → 메시지 재작성 → 서명·날짜·tree 동일성 검증.
연결
re0-release는 규칙을 내장하되 기존 커밋 수정 시 인간에게 실행 요청.
원문 SKILL.md

re0-release

USER · ORCH

출하 점검, 버전 결정, 커밋, 서명 태그, push, CI 릴리스 확인, 사이클 보관을 끝까지 걷습니다.

이유
공개 변경은 체크리스트 재구성보다 분리된 인간 승인 경계가 필요.
핵심
commit 전 승인과 tag+push 전 승인을 분리; workflow 일을 손으로 대체 금지.
연결
sip 실행, commit-economy 내장, re0-plan 폴더 retire.
원문 SKILL.md

re0-merge

USER · ORCH

외부 기여를 thesis gate로 심사하고 저자 크레딧을 보존해 land·release·close합니다.

이유
코드 수용과 장기 유지비, 기여자 인정이 한 흐름에서 깨지기 쉬움.
핵심
기본 surface deny → 냉독 → 승인 → authorship 보존 → 출시 후 credit close.
연결
shower, re0-git, re0-release를 이름으로 참조.
원문 SKILL.md

ssotize

MODEL

여러 위치에 흩어진 한 사실을 감사하고 승인 후 하나의 canonical home으로 수렴합니다.

이유
복사본은 drift하지만 참조는 따라감.
핵심
두 방법으로 전수 감사 → 분류 → 계획 공개 → 승인 → 정보 손실 없이 대체.
연결
sip에서는 audit만 자동; mutation은 별도 사용자 승인.
원문 SKILL.md

re0-upgrade

USER · ORCH

설치된 Paperthin을 현재 전체 카탈로그로 수렴시키고 발견 알림 훅을 연결합니다.

이유
부분 설치자는 새 스킬이 나와도 릴리스 피드를 보지 않으면 영원히 모름.
핵심
scope 확정 → shadow install 감지 → retire/add/refresh 계획 승인 → 검증·훅.
연결
catalog.cjs, SessionStart/OpenCode 어댑터, npx skills, GitHub star.
원문 SKILL.md

re0-plan

USER · ORCH

첫 반복 전에 .re0/iteration/<version>-<workname>/ casebook을 실제 내용과 함께 엽니다.

이유
빈 폴더와 구두 계획은 세션 중단 후 아무것도 전하지 못함.
핵심
lightweight는 RETRO 한 문단, full은 DESIGN/WORKFLOW/EVIDENCE.
연결
readchk, modelchk, 선택적 macrothinkre0-loop.
원문 SKILL.md

re0-loop

MODEL · ORCH

FRAME→BUILD→DRIVE→MEMO→HATE→WORK→BUILD AGAIN의 반복 학습 루프를 운전합니다.

이유
파일 수와 시간 대신 검증된 템플릿·모듈·제거된 anti-pattern을 진척으로 삼기 위해.
핵심
한 vertical slice, 실제 surface 증거, 학습 정제, 필요 시 재시작.
연결
re0-memo, nba, re0-work; hate는 인간 호출.
원문 SKILL.md

re0-memo

MODEL

끝났거나 실패한 사이클을 재사용 가능한 교훈, anti-pattern, gate, vocabulary로 바꿉니다.

이유
코드가 실패해도 실패의 구조는 다음 사이클의 자산이 될 수 있음.
핵심
개별 불만을 패턴 family로 일반화하고 evidence와 hard gate로 기록.
연결
re0-loop의 회고 단계; re0-plan이 만든 RETRO를 이어 씀.
원문 SKILL.md

re0-work

MODEL

검증된 계약·gate·테스트·negative corpus만 남기고 프로젝트/아티팩트를 v0에서 재시작합니다.

이유
기존 코드가 있다는 이유만으로 잘못된 구조를 계속 상속하는 관성을 끊음.
핵심
preserve/discard 분리 → 첫 gate → 하나의 완결 vertical loop.
연결
re0-loop 중간 결정으로 실행; nba가 필요성을 추천할 수 있음.
원문 SKILL.md

catchup

MODEL · READ

사람의 마지막 접점 이후 live state만 읽어 필요한 결정·변화·새 용어를 한 화면에 복구합니다.

이유
장기 에이전트 사이클이 인간의 mental model보다 빨리 진화함.
핵심
Needs you → Changed → New words, 전부 파일·커밋 근거.
연결
nba보다 먼저 지도를 복구하는 re-entry 페어.
원문 SKILL.md

nba

MODEL · READ

현재 사이클의 binding constraint를 읽고 메뉴가 아닌 단 하나의 next best action을 줍니다.

이유
선택지 목록은 막힌 프로젝트의 결정을 다시 사용자에게 떠넘김.
핵심
현재 단계·blank-out 원인 → 가장 싼 고레버리지 행동 → done when.
연결
re0-loop 단계 전환, re0-work 또는 인간 전용 스킬을 추천.
원문 SKILL.md

prism

USER · READ

한 아티팩트를 2~5개의 서로 다른 failure-mode lens로 읽고, 합의보다 충돌과 해결 질문을 반환합니다.

이유
다수 관점을 평균내면 가장 중요한 불일치가 사라짐.
핵심
렌즈별 verdict+핵심 이유 1개 → disagreement → 질문 1개.
연결
macrothink와 보완: 서로 다른 렌즈의 coverage vs 같은 문제의 fresh reads.
원문 SKILL.md
Orchestration

스킬들은 어떻게 함께 움직이나

Paperthin의 오케스트레이션은 세 층입니다. 명시적 호출(Workflow에 다른 스킬 이름), 페어링(런타임 의존성 없는 개념적 보완), 하네스 바깥 실행(fresh sub-session·CLI·CI)입니다.

re0-release → sip
출하 전 recursive QA를 실행합니다. 없으면 shower, factchk/mandela, ssotize, re0를 직접 재현합니다.
re0-merge → shower / re0-git / re0-release
냉독, 메시지 정리, 출하를 기여 반영 파이프라인에 묶습니다. 다만 user-only 연쇄 규칙과 긴장이 있습니다.
re0-plan → re0-loop → re0-memo ↔ re0-work
계획 casebook을 열고, 실제 surface 증거를 모으며, 학습만 보존해 필요 시 깨끗이 재시작합니다.
catchup → nba
먼저 인간의 지도를 live state로 복구한 다음, 그 지도 위에서 단 하나의 다음 행동을 고릅니다.
aim ↔ nba
같은 “하나만 제안” 형태를 서로 다른 끝에서 사용합니다: 들어온 데이터의 의도와 살아 있는 상태의 다음 수.
macrothink ↔ prism
둘 다 여러 관점을 쓰지만, 전자는 같은 문제의 fresh read 분산, 후자는 서로 다른 failure-mode lens의 충돌을 봅니다.

독립 컨텍스트를 직접 요구하는 스킬

스킬격리 방식왜 필요한가권한
shower아티팩트 내용만 fresh sub-session에 전달작성자의 숨은 문맥 차단읽기 전용 진단
feynman결정만 critic에 전달, 근거는 숨김결정을 만든 세션의 자기합리화 차단사람 설명을 압박
macrothinkbait 제거 후 2~5 fresh reads세션 프레이밍 분산사람 명시 호출
autobahn위험 원문을 못 보는 clean-run subagent안전 범위의 과소실행과 위험 재도입을 동시에 차단safe remainder 실행
mandela고위험 시 독립 auditor N=1 선택검증자가 자신의 분류를 재확인하는 누수 방지읽기 전용 감사
Runtime & delivery

설치, 발견 알림, CI, 릴리스

설치

README의 기본 경로는 npx skills@latest add LilMGenius/paperthin --global --agent '*'입니다. 각 스킬은 단독 설치될 수 있도록 필요한 런타임 규칙을 자기 문서 안에 품습니다. Claude 로컬 개발용으로는 scripts/link-skills.sh가 심볼릭 링크를 만듭니다.

새 스킬 발견

re0-upgrade가 현재 설치를 stale/missing/present/unknown으로 분류합니다. SessionStart 어댑터는 빠진 스킬이 있을 때 하루 한 번 모델 컨텍스트에 안내를 넣을 뿐, 설치를 자동 실행하지 않습니다.

CI

ci.yml은 skill shape, 참조, 상대 링크, catalog 복제본, ~/.re0/ 배포 홈을 점검합니다. 이는 구조적 drift guard이며 스킬 프롬프트의 의미적 품질을 자동 평가하지는 않습니다.

릴리스

서명된 vX.Y.Z 태그 push가 유일한 공개 트리거입니다. CI가 버전 일치 확인, npm publish --provenance, 태그 메시지 기반 GitHub Release 생성을 맡습니다.

발견 알림 데이터 흐름

catalog.cjs의 28개 이름 → ~/.agents/skills~/.claude/skills 비교 → missing 계산 → 24시간 throttle → Claude/Codex는 SessionStart JSON의 additionalContext, OpenCode는 system.transform에 주입 → 모델이 자연스러울 때 사용자에게 /re0-upgrade를 안내.
Design assessment

이 설계가 잘하는 것

1
각 스킬의 종료 조건이 선명합니다.

대부분이 Goal–Workflow–Rules–Verification 골격을 공유해 “좋게 해라”가 아니라 무엇을 확인해야 끝나는지를 명시합니다.

2
자동 호출과 인간 권한을 분리합니다.

커밋, 배포, 설치, 강한 비판, 관점 fan-out처럼 비용·편향·외부 상태를 바꾸는 동작은 user-only로 묶었습니다.

3
실패를 삭제하지 않고 다음 사이클의 corpus로 만듭니다.

re0-memo/re0-work/re0-loop와 release casebook 보관이 “코드가 죽어도 학습은 남는” 구조를 만듭니다.

4
작성자 편향을 구조적으로 다룹니다.

fresh context, 외부 source, independent ground truth, disagreement-first 등 서로 다른 메커니즘으로 자기확증을 쪼갭니다.

5
도구 독립성과 운영 구체성을 구분합니다.

detool은 durable 문서만 추상화하고 runbook·provenance는 구체적으로 남겨, “중립적이지만 쓸 수 없는 문서”를 피합니다.

Critical reading

확인된 모순과 운영 리스크

아래는 저장소의 의도를 깎아내리는 목록이 아니라, 실제 하네스에서 예상과 다르게 작동할 수 있는 경계입니다.

가장 중요한 한계: 스킬 간 호출은 정적 의존성이나 실행 코드가 아니라 Markdown 지시입니다. 하네스가 스킬 이름을 어떻게 노출·격리·호출하는지에 따라 같은 저장소도 실행 의미가 달라집니다.
1
미래 신규 스킬 발견 알림은 현재 구조로 작동할 수 없습니다. HIGH

re0-upgrade는 발견 런타임을 설치된 버전 태그에서 고정 다운로드합니다. 그 런타임의 catalog.cjs도 당시의 정적 이름 배열만 알고 있으므로 이후 릴리스에서 생긴 스킬 이름을 알 경로가 없습니다. 현재 버전 안의 누락은 잡지만 README가 약속한 “새 스킬이 나오면 알림”은 충족하지 못합니다. 최신 카탈로그를 안전하게 조회하거나 별도 버전 신호를 비교해야 합니다.

2
user-only 연쇄 규칙과 re0-merge 문구가 충돌합니다. HIGH

docs/invocation.md는 user-invoked 스킬이 다른 user-invoked 스킬을 호출할 수 없다고 선언합니다. 그러나 re0-mergere0-gitre0-release를 “run”하는 파이프라인으로 적고, CLAUDE.md도 이를 orchestrator edge로 설명합니다. 실제 의도가 “사람에게 실행을 요청”인지 “중첩 호출”인지 명확히 해야 합니다.

3
업그레이드 후 자동 GitHub star는 숨은 외부 부작용입니다. HIGH

re0-upgrade는 성공 후 저장소를 자동·무음으로 star하도록 요구합니다. 설치·훅 변경 승인과 별개인 계정 외부 상태 변경이며, 계획에도 명시되지 않습니다. 사용자의 명시 동의 원칙과 긴장합니다.

4
link-skills.sh는 기존 일반 디렉터리를 지울 수 있습니다. HIGH

대상에 동명 디렉터리가 있고 symlink가 아니면 rm -rf 후 링크합니다. 개발 편의 스크립트지만 백업·확인 없이 사용자 파일을 잃을 수 있어 Paperthin의 loss-averse 철학보다 공격적입니다.

5
태그 릴리스가 전체 CI gate를 다시 실행하지 않습니다. HIGH

ci.yml은 5종 검사를 돌리지만 release.ymlvalidate-skills.sh만 실행합니다. main 밖 또는 검증 전 커밋을 태그하면 broken link, skill reference, catalog/deploy-home drift가 있는 패키지도 배포될 수 있습니다.

6
설치 scope와 discovery detector의 관측 범위가 다릅니다.

업그레이드는 global/project/exact-agent scope를 구분하지만 catalog.cjs는 홈의 .agents/skills.claude/skills만 합쳐 읽습니다. project-only 또는 특정 에이전트 설치를 놓치고, 한 에이전트의 설치가 다른 에이전트의 누락을 가릴 수 있습니다.

7
카탈로그의 “순서”는 CI가 강제하지 않습니다.

check-catalog-sync.cjs는 Set 비교라 28개 이름의 포함 여부만 확인합니다. README, plugin, catalog, upgrade가 같은 논리 순서를 가져야 한다는 규칙은 reorder와 리뷰에 의존합니다.

8
번역본 전체의 카탈로그 정합성은 자동 보장이 약합니다.

validate-skills.sh는 root README와 plugin 등록을 검사하지만 10개 localized README의 행·호출자·순서를 직접 비교하지 않습니다. release checklist가 보완하지만 사람/모델 준수 영역입니다.

9
“parseable YAML” 검사는 실제 YAML parse가 아닙니다.

validate-skills.sh는 frontmatter 블록 안에 key처럼 보이는 줄이 있는지만 정규식으로 봅니다. 닫히지 않은 quote, boolean 오타, 잘못된 YAML 값이 통과할 수 있고 user-only 12개 분류도 자동 검증하지 않습니다.

10
“any agent”와 기여자 하네스 자동 로딩 사이에 틈이 있습니다.

스킬 자체는 plain Markdown이라 이식 가능하지만 기여자용 standing instruction은 CLAUDE.md 하나뿐입니다. 다른 하네스에서 동일 규칙이 자동 주입된다는 보장은 없습니다. 사용자 실행 portability와 contributor authoring portability를 분리해 표현하는 편이 정확합니다.

11
검사 주석과 invocation description에 작은 drift가 남아 있습니다.

check-catalog-sync.cjs의 설명은 “21-skill roster”라고 쓰지만 현재는 28개입니다. 또한 일부 user-only description에는 규약이 제거하라고 한 Use when/Run when 트리거 문구가 남습니다.

12
구조 검사는 강하지만 프롬프트 행동 검사는 제한적입니다.

CI는 섹션·링크·목록 drift를 잘 잡지만, hate가 정말 한 반론만 내는지, sip이 user-only 스킬을 호출하지 않는지 같은 의미적 계약은 테스트하지 않습니다. eval fixture나 transcript 기반 회귀 테스트가 없습니다.

추천 개선 우선순위: (1) discovery가 최신 catalog를 알 수 있는 안전한 버전 신호 도입, (2) re0-merge의 user-only 연쇄 의미 통일, (3) GitHub star를 사전 계획·옵트인으로 변경, (4) release에서 전체 CI gate 재실행, (5) link-skills를 충돌 시 stop-and-report로 변경, (6) roster 순서·번역본·frontmatter를 실제 parser로 검증, (7) 핵심 오케스트레이터 transcript/eval 회귀 사례 추가.
Evidence

분석 근거와 검증 상태

주요 근거

로컬 검증

node scripts/check-catalog-sync.cjs28 skills match, node scripts/check-deploy-home.cjsdeploy-home SSOT OK로 통과했습니다.

세 Bash 검사는 이 Windows 실행 환경에서 Git Bash의 Unix 도구 PATH가 정상 노출되지 않아 원형 그대로 실행하지 못했습니다. 다만 파일 자체와 CI 정의를 읽어 검사 범위를 분석했습니다.

스냅샷: main, commit 3bca079 (2026-08-19), package 0.17.4. 저장소는 분석 시점에 로컬로 clone되어 원본 파일을 직접 읽었습니다. 이 문서는 원본 프로젝트의 공식 문서가 아니라 독립 분석물입니다.