prompt-audit 1차 감사 보고서

Claude Fable 5.1 대상 프롬프트 자산 감사 · 2026-09-02 · 작업 폴더 ~/Projects/prompt-audit/

Anthropic 공식 claude-api 스킬의 prompt-audit 절차를 HC의 Claude Code 프롬프트 자산 전체에 적용했다. 전역 CLAUDE.md 1개, 스킬 정의 40개, 서브에이전트 정의 12개를 합쳐 53개 파일을 읽고, 옛 모델 세대에 맞춰 쓰였거나 이미 사실과 어긋난 지시문 78건을 찾았다. High·Medium 등급 findings와 frontmatter 정리 16건을 반영한 제안 diff까지 만들어 두었다.

1. 왜 하는가, 무엇이 좋아지나

프롬프트는 모델별 소모품입니다. 지금 ~/.claude/에 쌓인 지시문 중 상당수는 예전 모델이 지시를 잘 안 따르던 시절에 쓰였습니다. 그때는 "반드시", "절대", "CRITICAL"을 붙이고 단계를 하나하나 손으로 짜 줘야 모델이 제대로 움직였습니다.

Anthropic의 이관 지침은 지금 모델에서는 그 문장들이 거꾸로 해가 된다고 적고 있습니다. 세 가지가 문서화되어 있습니다. 첫째, 과잉 처방된 단계 안무는 Fable 5.1의 출력 품질을 떨어뜨립니다. 모델 자신의 계획이 대개 손으로 쓴 스크립트보다 낫기 때문입니다. 둘째, "중간 보고 하지 마라" 같은 옛 억제 문구가 남아 있으면 원래도 말수가 적은 5.1이 더 조용해집니다. 셋째, "불릿 쓰지 마라" 같은 서식 금지는 이미 서식을 덜 쓰는 모델에서 독자가 원하던 서식까지 깎아냅니다. 강조 표시도 마찬가지입니다. 전부 중요하다고 표시하면 표시가 정보를 잃고, 불안한 프롬프트가 불안한 답변을 만듭니다.

이번 감사에서 기대할 수 있는 것은 네 가지입니다.

• 과잉 반응이 줄어듭니다. 안 불러야 할 스킬이 불려 나오거나, 간단한 요청에 과하게 절차를 밟는 일이 줄어듭니다.
• 세션이 가벼워집니다. 라우팅용 description은 매 요청마다 컨텍스트에 실립니다. 거기 들어 있던 실적 이력이나 규칙 본문을 본문으로 옮기면 매 요청의 비용이 줄어듭니다.
• 규칙 충돌 사고가 줄어듭니다. 전역 지시가 금지한 명령을 스킬이 그대로 시키는 경우, 폐기된 서버·경로를 가리키는 경우가 이번에 여럿 나왔습니다. 지시 준수가 강한 모델일수록 틀린 지시를 그대로 실행합니다.
• 규칙마다 근거가 남습니다. 각 발견에는 왜 그렇게 판단했는지와 적용 전후로 무엇을 확인해야 하는지(probe)가 붙어 있습니다. 다음 모델이 나왔을 때 같은 절차를 다시 돌릴 수 있습니다.

감사 기준과 가정

4명의 감사 에이전트가 공통 지침(BRIEF.md)을 받고 같은 절차를 밟았습니다. 확정해 둔 가정은 아래와 같습니다.

HC 환경에 맞춰 추가한 유지(keep) 규칙도 지침에 넣었습니다. 짧게 만드는 것이 목적이 아니기 때문입니다.

1. 업무·정책 제약은 유지합니다. 삭제 금지, 아마란스 결재 금지, 인증은 HC에게, LifeVault push 금지, 산출물 전달 규약, 스피커 금지 등은 압박 표현으로 쓰여 있어도 삭제 후보가 아닙니다. HC가 실제 재발한 실패 뒤에 붙인 표기이므로 "현행 모델에서 재현되는 실패에 대한 금지"에 해당합니다. 표현 완화는 Low로 flag만 했습니다.
2. 날짜·출처 표기는 건드리지 않습니다. (2026-07-08 지시) 같은 표기는 HC의 provenance 관례입니다.
3. 환경 정보는 context입니다. 기기 이름 별칭표, 서버 표, 볼트 역할표는 저자만 아는 사실이라 유지합니다.
4. 스킬 description의 트리거 강조는 허용됩니다. 라우팅 텍스트는 예외입니다. 다만 유사어 나열과 설명 부족은 봅니다.
5. 근거를 못 대는 발견은 발견이 아닙니다. 해당 없으면 "없음"이 정답입니다. 반대로 Fable 5.1용으로 추가가 필요한 것도 발견입니다.

2. 횡단 주제 4가지

78건을 관통하는 큰 줄기가 넷 있습니다. 개별 항목보다 이쪽을 먼저 보시는 편이 낫습니다.

① 전역 지시가 금지한 명령이 스킬 7개에 그대로 살아 있다

전역 CLAUDE.md의 산출물 전달 규약 3번은 cokacdir --sendfile을 사용 금지로 못 박았습니다. status:ok를 돌려주고도 실제로는 파일이 안 가는 침묵 실패가 확인됐기 때문입니다. 그런데 스킬 7개가 여전히 이 명령만 지시하고 있습니다. 지시를 곧이곧대로 따르는 모델일수록 이 줄을 그대로 실행하고, 침묵 실패한 것을 모른 채 "전송 완료"로 보고합니다. 특히 sermon-notes의 한 곳은 "NotebookLM 재인증 필요" 알림 경로라, 침묵 실패하면 인증이 만료된 사실 자체를 전달받지 못합니다. 게다가 이 줄들에는 텔레그램 chat id와 cokacdir 키가 평문으로 박혀 있어 스킬 파일이 사실상 비밀값 보관소가 되어 있습니다.

제안: 전부 텔레그램 헤르메스 봇의 sendDocument 호출로 교체하고, 토큰은 ~/.hermes/.env에서 읽으며, 응답의 "ok":true를 확인한 뒤에만 성공으로 보고하도록 바꿉니다. 반영하면 이 파일들에서 평문 credential이 함께 사라집니다.

해당 파일 7개: server2-pages, janghase-dashboard, ytreport, sermon-notes, codex-infographic, notebooklm(한 파일 안에 5곳), agent-korea-watch. 관련 finding = A-02, A-03, B-03, B-04, C-01, C-03, D-01. incident에도 같은 키가 있으나 그쪽은 --cron-history라는 다른 CLI 계약이라 flag만 했습니다(D-12).

② frontmatter의 triggers:와 preamble-tier:는 조용히 무시되고 있다

스킬 파일 맨 위의 설정 블록에 적어 둔 triggers:는 Claude Code 2.1.258이 인식하지 않는 키입니다. 감사 에이전트 두 명이 각각 바이너리 문자열을 직접 뒤져 확인했습니다. 인식하는 키는 when_to_use, allowed-tools, disable-model-invocation, user-invocable, effort, shell, version, paths, hooks, context, agent 등이고, triggers는 없습니다. 바이너리 안의 triggers 문자열은 전혀 다른 원격 웹훅 API 경로였습니다. preamble-tier는 아예 0회 등장합니다.

즉 스킬 23개에 공들여 적어 둔 호출어들이 라우팅에 한 글자도 반영되지 않고 있습니다. "유튜브 보고서 만들어줘"라고 말했을 때 스킬이 안 걸리는 일이 있었다면 원인이 여기일 가능성이 큽니다. 라우팅에 실제로 들어가는 것은 name + description + when_to_use뿐이고, 셋을 합쳐 1,536자 상한이 있습니다.

제안: triggers: 목록을 지원 키 when_to_use:의 자연어 문장으로 옮기고 preamble-tier:는 삭제합니다. version:은 지원 키이므로 그대로 둡니다. 감사 단계에서 일부가, 통합 단계에서 나머지가 변환되어 현재 proposed/ 전체가 지원 키만 쓰는 상태입니다(7절). 관련 finding = A-04, B-05, B-21(flag) + 통합 16건.

③ 낡은 지도: 문서가 가리키는 곳에 그것이 없다

가장 건수가 많고 가장 확실하게 실패를 막는 묶음입니다. 모델 세대와 무관하게 이미 틀린 사실들입니다. janghase-dashboard 스킬은 2026-06-14에 회수된 server2로 배포하라고 하고, 존재하지 않는 로컬 경로 ~/AIVault/janghase-vault-web를 가리킵니다. 전역 지시에 "server1으로 바꿔야 동작한다"고 적혀 있지만 스킬 본문은 갱신되지 않아, 스킬을 따르면 100% 실패합니다.

agent-korea-watch가 확인하라는 LaunchAgent 라벨은 2026-08-23에 삭제되어 지금 없습니다. 스킬의 판정표가 "항목 없음 → 등록 안 됨"으로 되어 있어 정상 상태를 고장으로 오판하게 만듭니다. ebook은 삭제 경고의 근거로 스크립트 28행을 지목하는데 실제로는 38행이고, 확인하러 갔다가 아무것도 못 찾으면 경고 자체를 무효로 판단할 수 있습니다. kyobo-ebook은 같은 파일 안에서 한쪽은 "이 하위명령은 쓰지 않는다"고 폐기 선언을 해 놓고 트러블슈팅 표만 옛 명령을 가리킵니다. diagram-design은 기본 색상 hex가 실제 배포된 스타일 가이드와 달라 조건식이 항상 참이 되고, 첫 실행 질문 게이트가 영원히 안 열립니다.

해당 finding: A-01, A-08, A-20, B-01(은퇴 모델 ID 고정), B-02(옛 폴더 규약), B-08(하네스 버전 고정), B-23, C-02, C-05, C-16, D-02, D-03, D-04, D-05, D-06.

④ 전역 CLAUDE.md는 삭제 후보 0건, 추가 제안 2건

전역 지시 파일은 감사 결과 삭제할 것이 하나도 없었습니다. 업무·정책 제약, 날짜 표기, 기기·서버·볼트 표는 전부 "저자만 아는 맥락"이라 유지 판정입니다. 압박 표기도 재발 기록이 있어 완화 제안조차 하지 않았습니다.

대신 Fable 5.1용으로 추가를 권하는 것이 둘 있습니다. 하나는 "완료·성공은 도구 결과로 확인한 것만 보고한다"와 "막히면 사용자에게 넘기기 전에 다른 경로를 먼저 시도한다"입니다(A-11). 근거는 이미 CLAUDE.md에 기록된 침묵 실패 사고, 메모리의 교훈 40번, 그리고 이번 감사 중 감사 에이전트 자신이 메모리만 믿고 틀린 문장을 썼다가 실측으로 되돌린 일입니다. 다른 하나는 "서로 의존하지 않는 작업은 서브에이전트를 한 번에 여러 개 띄우고, 아직 안 온 결과를 미리 지어내 보고하지 않는다"입니다(A-12). 위임 규칙은 있지만 병렬 위임과 미도착 결과 날조 금지가 빠져 있었습니다.

3. High 22건 전체

확신도가 가장 높은 발견들입니다. 문서로 확인됐거나 대상 모델에서 실제로 오류를 내는 것들만 여기 들어옵니다. 표는 좌우로 넘길 수 있습니다.

4. HC 결정이 필요한 항목

감사 에이전트가 판단을 미뤄 둔 것들입니다. 결정하지 않으면 diff에 들어가지 않았거나 일부만 들어갔습니다.

C-11 · 유튜브 보고서 워크플로우가 세 스킬에 중복되어 있다

notebooklm 파일 뒤쪽 380행이 ytreport·sermon-notes와 같은 워크플로우를 담고 있습니다. 목적지 경로와 섹션 제목까지 그대로 겹칩니다. 그리고 이미 갈라졌습니다. ytreport 3단계에는 InvestVault 라우팅이 추가됐는데 notebooklm 사본에는 없습니다. 같은 요청이 어디로 라우팅되느냐에 따라 결과가 달라집니다. 41KB 파일이 전용 스킬로 될 일에 통째로 로드되는 비용도 있습니다.

결정할 것: 어느 쪽을 정본으로 삼을지입니다. 정본이 정해져야 나머지를 지울 수 있는데, 삭제는 HC가 직접 하는 원칙이므로 감사 쪽에서는 라우팅 description만 고쳤습니다. 본문 380행 통합은 지시가 있을 때 별건으로 처리합니다.

B-05 · 라우팅 변경은 스킬 발동 조건 자체를 바꾼다

이번 diff에서 동작을 바꾸는 유일한 변경입니다. triggers:를 when_to_use:로 옮기면 그동안 무시되던 트리거 문구가 처음으로 실제 라우팅에 들어갑니다. 안 걸리던 스킬이 걸리기 시작하는 것이 목적이지만, 반대로 너무 자주 걸릴 수도 있습니다. ontology-ask처럼 폭넓은 문구를 가진 스킬이 후보입니다.

권고: 이 항목만 먼저 반영하고 하루 정도 관찰하십시오. 과하게 걸리는 스킬이 있으면 그 파일의 when_to_use 문구만 좁히면 됩니다.

서드파티 스킬을 어떻게 고칠 것인가

53개 중 상당수가 남이 만든 자산입니다. 여기에 직접 손을 대면 다음 업그레이드에서 사라집니다.

결정할 것: 세 갈래입니다. (1) upstream에 이슈나 PR을 내고 기다린다. (2) 로컬 fork 또는 오버레이를 두어 업그레이드에도 살아남게 한다. (3) 그냥 직접 고치고 업그레이드 때마다 다시 적용한다. 자산별로 다르게 정하셔도 됩니다. 예를 들어 ego-browser는 앱 번들 안이라 (1) 외에는 사실상 방법이 없습니다.

압박 표현 완화 Low 항목들

"★중요", "반드시 지킬 것", "예외 없이" 같은 표기가 여러 스킬에 있습니다. 감사 지침상 이런 표기는 완화 제안만 하고 diff는 만들지 않았습니다. HC가 실제 재발한 실패 뒤에 붙인 표기이기 때문입니다.

권고: 유지하십시오. 재발 방지 표기는 그 자체로 기록입니다. 완화는 선택 사항이고, 하시더라도 규칙 본문은 그대로 두고 표기만 걷어내는 방식이 안전합니다. 해당 항목 = B-18, B-20, C-13(서드파티라 사정이 다름), D-15.

5. 적용 방법

먼저 백업부터 권합니다.

cp -r ~/.claude/skills ~/Projects/prompt-audit/backup-20260902
cp ~/.claude/CLAUDE.md ~/Projects/prompt-audit/backup-20260902-CLAUDE.md

파일 하나가 어떻게 바뀌는지 보기

cd ~/Projects/prompt-audit
diff -u orig/skills/<이름>.SKILL.md proposed/skills/<이름>.SKILL.md

# 예: diff -u orig/skills/ytreport.SKILL.md proposed/skills/ytreport.SKILL.md
# 전역 지시는:
diff -u orig/CLAUDE.md proposed/CLAUDE.md

한 파일을 통째로 받아들이기

cp proposed/skills/<이름>.SKILL.md ~/.claude/skills/<이름>/SKILL.md

단, ~/.claude/skills/<이름>이 심볼릭 링크면 이렇게 덮어써도 다음 업그레이드에 사라집니다. 먼저 확인하십시오.

readlink ~/.claude/skills/<이름>
# 아무것도 안 나오면 실디렉토리 → 그냥 복사해도 됨
# 경로가 나오면 심볼릭 링크 → 그 원 리포에 반영해야 살아남음

일부만 받아들이기

hunk 단위로 고르고 싶으시면 저에게 ID로 지시하시면 됩니다.

"A-03만 적용해줘"
"cokacdir 관련 7건 전부 적용하고 나머지는 놔둬"
"B-05는 빼고 나머지 High만 적용해줘"

확인 순서 권고

1. 횡단 주제 ①(전송 명령 7건)을 먼저 반영하고, 실제로 텔레그램에 파일이 도착하는지 1건 확인합니다.
2. ③(낡은 지도)을 반영합니다. 실패하던 것이 성공하는지 바로 확인됩니다.
3. ②(frontmatter)를 반영하고 하루 관찰합니다. 스킬 발동이 과해지면 그 파일의 when_to_use만 좁힙니다.
4. 나머지 Medium 항목은 급하지 않습니다. 각 finding의 사전·사후 probe가 6절 검증 메모에 한 줄씩 적혀 있습니다.

6. 감사 에이전트별 상세

감사는 4명이 파일을 나눠 동시에 진행했습니다. 각 담당분의 Medium·Low 전체 목록, 발견이 없던 파일, 그리고 적용 전후에 무엇을 확인할지 적은 검증 메모입니다. 접혀 있으니 필요한 것만 펴 보십시오.

에이전트 A · 23파일 · 21건 (High 7 / Medium 10 / Low 4)

담당: 전역 CLAUDE.md 1개 + agents/*.md 12개 + 스킬 10개(pumui, server2-pages, payroll-review, loop-design, goal-setup, humanize-korean, music, janghase-dashboard, aside, voice).

소유권: 서드파티 13개(agents/*.md 12 + humanize-korean, 전부 im-not-ai 리포), HC 작성 10개.

A는 추정 대신 실측을 여러 번 돌렸습니다. Claude Code 바이너리를 뒤져 frontmatter 인식 키 목록을 뽑았고, 초기에 "존재하지 않는 도구"라고 세운 가설을 실측으로 폐기하고 finding을 다시 썼으며, server1에 직접 접속해 배포 스크립트와 프로세스가 살아 있음을 확인했습니다. 자동 메모리에 남아 있던 "스크립트가 서버에 없음"이라는 기록이 현재는 사실이 아니었습니다. 이 경험이 A-11(진행 보고를 도구 결과로 감사하자) 제안의 직접 근거입니다.

Medium 10건

ID	위치	근거	패턴	왜	Action	소유
A-08	janghase-dashboard:199-253	독립 HTML 페이지 배포 절차 블록. scp … server2:	2	server2-pages 절차를 통째로 복제한 블록인데 원본은 server1으로 갱신됐고 복제본만 옛 서버에 남아 이미 어긋났다. 중복 절차는 한쪽만 갱신되며 계속 어긋난다	move	HC
A-09	server2-pages:220-241	「현재 배포된 페이지」 14행 표 + "새 페이지 배포 시 이 표에도 추가한다"	2	배포 목록은 매주 바뀌는 휘발성 데이터이고 이미 보관함이 정본이다. 프롬프트 안의 손 관리 대장은 필연적으로 낡는다. 규칙이 붙은 행(고정 페이지, 비번, 공개 전환 금지)은 정책이라 그대로 보존	rewrite	HC
A-10	payroll-review:43	월별 급여 파일을 수거하는 명령에 대상 월이 하드코딩되어 있다	2	매월 20일경 도는 루프인데 대상 월이 고정이라 9월 실행 시 8월 파일을 조용히 가져와 엉뚱한 달을 검증하고도 성공 보고한다. 파일이 존재하므로 실패로도 안 잡힌다	rewrite	HC
A-11	CLAUDE.md:59-66 (신규 2줄)	"완료·성공은 도구 결과로 확인한 것만 보고한다" / "막히면 넘기기 전에 다른 경로를 먼저 시도한다"	add	Fable 5.1 권고 두 가지가 전역 지시에 없다. 근거는 이미 기록된 침묵 실패 사고, 메모리 교훈 40번, 그리고 이번 감사 중 메모리만 믿고 틀린 문장을 쓴 사고. 자율 실행 경계도 메모리에만 있고 전역 지시에는 없다	add	HC
A-12	CLAUDE.md:53 (신규 1줄)	"서로 의존하지 않는 작업이면 서브에이전트를 한 번에 여러 개 띄워 병렬로 돌리고 … 아직 안 온 결과를 미리 지어내 보고하지 않는다"	add	위임 규칙은 있으나 비차단·병렬 위임과 미도착 결과 날조 금지가 없다. 5.1은 긴 턴을 유지하고 서브에이전트를 병렬로 굴리는 것이 이득인데 현재 지시는 순차 위임처럼 읽힌다	add	HC
A-13	humanize-korean:79-90	strict 모드 각 Phase 호출부	3	각 Phase가 무엇을 입력으로 넘기는지를 적지 않았다. fast 모드에는 입력 경로 블록이 있는데 strict에는 없어 서브에이전트가 경로를 추측한다. A-14와 합쳐지면 상대 경로 추측으로 실패한다	add	서드파티
A-14	agents/ai-tell-detector:13 외 2개 에이전트	"references/ai-tell-taxonomy.md를 로드하여…" 상대 경로	3	서브에이전트의 cwd는 스킬 디렉토리가 아니라 상대 경로로는 열리지 않는다. 오케스트레이터가 절대 경로를 넘겨야 한다는 계약이 어디에도 없다	rewrite	서드파티
A-15	agents/* 6개 파일의 「발신」 절	"윤문가에게 … 메시지. 리뷰어에게 메트릭 기준값 공유"	3	에이전트끼리 메시지를 주고받는 그림인데 실제 실행은 오케스트레이터가 호출하고 파일로만 주고받는다. 없는 통신 채널을 전제하면 "전달했다"고 보고하고 실제로는 아무 데도 안 간다	rewrite	서드파티
A-16	agents/ 3개 파일	"총 도구 호출 6회 이하. wall-clock 5분 이내 목표"	4	A-06·A-07과 같은 예산 카운트다운. 자기모순까지는 아니어서 Medium. 조기 종료 유인만 남는다	rewrite	서드파티
A-17	humanize-korean:9-15	"v1.5 변경 고지 (2026-04-26) …" 릴리스 노트 문단	1d + 2	과거 버전이 왜 실패했는지의 이력이 본문에 남아 있다. 모델에게 필요한 건 현재 두 모드의 계약뿐이다. 게다가 적힌 도구 호출 수가 실행 에이전트 정의와 다르다. HC의 날짜 표기와 달리 이건 서드파티 릴리스 노트라 보호 대상이 아니다	rewrite	서드파티

Low 4건 (flag만, diff 없음)

ID	위치	내용	왜
A-18	agents/ 2개 파일	리포 절대 경로가 프롬프트에 박혀 있다	이미 upstream 경로에서 로컬로 손수정된 흔적이라 git pull 때마다 되돌아온다. 근본 해결은 오케스트레이터 인자화지만 서드파티 구조 변경이라 flag만
A-19	CLAUDE.md:32	"server2가 회수되어 … server1으로 바꿔야 동작한다"	형식만 보면 이관 서술이지만 아직 참이다. A-01·A-08이 적용되기 전에는 이 문장이 유일한 안전망이다. 지금은 유지하고, 반영 후에 환경 사실만 남기는 재기술을 권한다
A-20	server2-pages:160	소제목만 "서버2"이고 아래 명령은 이미 server1으로 고쳐져 있다	도메인 이름은 정상이라 혼동 소지가 크지 않아 Low
A-21	humanize-korean:3	스킬 버전과 에이전트들이 말하는 버전이 다르다	version은 지원 키이고 버전 부여는 HC 판단이라 임의로 올리지 않았다

finding 없음 / 명시적 유지

• aside: 없음. frontmatter가 지원 키만 쓰고 절차·경로가 실측과 일치합니다.
• pumui: A-04만. 본문의 반려 사유 서술, 스크립트 경로, 외부 유출 금지는 전부 유지 판정입니다.
• CLAUDE.md: 추가 2건과 flag 1건뿐, 삭제 제안 0건.
• agents/humanize-monolith: 도구 호출 3회 캡은 이 에이전트의 존재 이유라 유지.
• loop-design, goal-setup, music, voice: A-04만. music의 "절대 병렬 금지" 반복, loop-design의 상한, goal-setup의 참조 파일(실재 확인)은 유지.
• 전역 지시의 업무·정책 제약 전부, 날짜·출처 표기 전부, 기기·서버·볼트 표, model·version frontmatter는 유지 판정.

검증 메모 (적용 전후 확인)

ID	사전 probe	사후 probe
A-01	없는 로컬 경로 확인 + server1에 배포 스크립트와 프로세스가 있는지 확인	배포 스크립트 실행 후 완료 메시지와 사이트 200 확인
A-02	원본에서 금지 명령이 몇 곳인지 grep	교체한 sendDocument 한 줄을 실제로 돌려 응답에 "ok":true가 오고 텔레그램에 파일이 도착하는지 확인
A-03	같은 grep	A-02와 같은 경로로 스크린샷 1건 전송 성공
A-04	바이너리에서 preamble-tier 0건, 인식 키 목록에 triggers 부재 확인	배치 후 claude --debug에서 unknown frontmatter key 경고가 사라지는지, when_to_use 문구로 자동 호출이 걸리는지 실호출 테스트
A-05	fast 모드 1회 실행 후 두 번째 산출물 파일이 없음을 확인	재실행 후 파일 1개만 생성되고 본문 끝 요약 블록에서 등급·변경률을 읽어 보고하는지 확인
A-06	1회 실행 로그에서 도구 호출 수와 테스트 실행 여부 기록	캡 제거 후 테스트 통과 보고가 실제 실행 결과로 나오는지 확인
A-07	실행에서 "14회 이하 자체 보고" 문구 출현 여부	캡 제거 후 산출물 길이 제한과 정의 무수정이 유지되는지 diff로 확인
A-08	복제본이 낡았음을 grep으로 확인	독립 HTML 배포 요청 시 server2-pages 스킬로 라우팅되는지 확인
A-09	보관함 목록 건수와 표 행수(14) 비교	새 페이지 1건 배포 후 보관함 스캔만으로 반영되는지 확인
A-10	대상 월을 고정한 채 실행 시 다음 달에도 지난달 파일이 수거되는지 재현	변수화 후 수거된 파일명이 대상 월인지 확인하는 단계에서 멈추는지 확인
A-11	최근 세션에서 "완료" 보고 뒤 실제로 실패한 사례 수집	추가 후 같은 상황에서 도구 결과를 인용한 보고가 나오는지, 막힌 지점에서 곧바로 넘기지 않는지 관찰
A-12	독립 작업 3건을 위임했을 때 순차로 도는지 확인	추가 후 같은 요청에서 호출이 한 메시지에 묶여 나가는지 확인
A-13	strict 모드 호출 시 서브에이전트가 경로를 되묻거나 실패하는지 재현	입력 블록 추가 후 각 단계가 절대 경로를 받아 첫 시도에 파일을 여는지 확인
A-14	서브에이전트 안에서 상대 경로 열기 실패 재현	넘겨받은 절대 경로로 로드 성공하는지 확인
A-15	실행 후 "메시지 전달했다"고 보고하는지, 실제 수신자가 있는지 확인	재작성 후 산출물 경로만 반환하고 오케스트레이터가 그 경로를 다음 단계에 넘기는지 확인
A-16	세 에이전트 실행에서 캡 근처 조기 종료가 있는지 로그 확인	캡 제거 후 산출물 완성도(항목 누락 여부) 비교
A-17	스킬 로드 시 이력 문단이 컨텍스트에 실리는 것 확인	재작성 후 두 모드 계약만 남고 숫자 오기가 사라졌는지 확인

에이전트 B · 9파일 · 24건 (High 6 / Medium 11 / Low 7)

담당 9개: new-project, ytreport, sermon-notes, threadfolio-post, ontology-ask, codex, amaranth-review, design-ref-add, last30days.

소유권: last30days만 서드파티(MIT, 별도 리포의 심볼릭 링크), 나머지 8개는 HC 작성.

B도 하네스 사실을 독립적으로 확인했습니다. 라우팅 시 모델 컨텍스트로 들어가는 것은 name + description + when_to_use뿐이고 합산 1,536자 상한이 있으며, triggers와 preamble-tier는 공식 문서 표에도 바이너리에도 없어 조용히 무시된다는 것입니다. preamble-tier는 ~/.claude/ 전역 grep에서도 소비처가 없었습니다.

Medium 11건

ID	위치	근거	패턴	왜	Action	소유
B-07	last30days:137,1042	"세 겹의 LAW 1 강화로 부족했고, 자기점검이 네 번째 겹이다"	1c	같은 규칙이 다섯 곳에서 재진술된다. 이관 가이드는 "몇 턴마다 끼워 넣은 지시 반복은 제거하고 재시험"을 명시한다. 계약 본문과 출력 직전 두 곳만 남기면 충분하다. 자기점검 자체는 검증 지시라 유지하고, 겹 수 자랑과 사고 로그만 걷어냈다	rewrite	서드파티
B-08	last30days:223	"WebSearch는 Claude Code v2.1.114에서 deferred tool이다"	2	실제 하네스는 2.1.258이다. deferred tool이라는 사실은 지금도 유효하므로 내용은 유지하고 버전 고정만 뗐다. 버전이 어긋난 서술은 옆 문장 전체의 신뢰도를 깎는다	rewrite	서드파티
B-09	last30days:1640-1664	"## CONTEXT MEMORY … 이 대화 나머지 동안 기억할 것"	1b	대화 유지용 암기 지시는 구형 스캐폴드다. 5.1은 긴 턴을 유지하고 컨텍스트 불안이 드물며, 권고는 "기억 표면을 파일로 주라"는 쪽이다. 이 스킬은 이미 원문 파일을 저장하므로 그 파일을 가리키게 바꿨다. 기능 제약(재검색 금지, 저장된 근거 인용)은 보존	rewrite	서드파티
B-10	last30days:1562-1576	"반드시 해야 할 것 / 절대 하지 말 것 / 이 지시가 강한 이유" 3중 목록	1a	지시 준수가 강한 모델에서 이중 목록과 "왜 이 지시가 강한지" 해설은 토큰만 쓰고 준수율을 올리지 못한다. 제약 5개는 전부 평서문으로 보존했다	rewrite	서드파티
B-11	amaranth-review:23	"정기예금 만기일은 이제 파이프라인이 알아서 기록한다"	1d	"이제"는 과거 동작 대비 diff 표현이다. 모델은 이전 버전을 모르므로 현재 상태 서술이면 족하다. 뒤따르는 날짜 출처 표기는 HC provenance라 손대지 않았다	rewrite	HC
B-12	amaranth-review:64	"회귀 전건(현재 8건)이 통과하는지"	2	케이스가 늘 때마다 썩는 수치다. 실제 규칙은 "전건 통과"이고 건수는 테스트 러너가 스스로 안다. 8건에서 멈춘 숫자는 9번째 케이스를 무시해도 된다고 읽을 여지를 준다	rewrite	HC
B-13	ontology-ask:6-9,10-21	라우팅 description의 규칙 문단이 본문 「원칙」과 거의 자구 그대로 중복	1c + 3	라우팅 description은 매 요청에 상주하는 텍스트다. 규칙 본체는 본문 한 곳에 두고 라우팅에는 "언제 부르는가"만 남기는 편이 낫다. 제안 모드는 트리거 성격이라 when_to_use로 옮겼고, 규칙 자체는 본문에 그대로 유지	rewrite	HC
B-14	ontology-ask:73	"관계타입 위임모드 추가 진행은 중단됨. 재개 여부 묻지 않는다"	2	중단 이력 서술. 현행 규칙으로 바꾸면 같은 행동을 지시하면서 과거 상태 설명이 사라진다	rewrite	HC
B-15	codex:7	"1호 결과물: … (2026-07-11)" 실적 이력이 라우팅 텍스트에 있다	2 + 3	라우팅 기여는 0이면서 매 요청 컨텍스트를 차지한다. 이력은 자동 메모리에 이미 있다	rewrite	HC
B-16	last30days:294,315	"## CRITICAL: …" / "**IMPORTANT: … 하지 마라**"	1a	파일 전체에 CRITICAL 13회, MANDATORY 20회, Do NOT 29회가 깔려 강조가 신호 역할을 못 한다. 지시 준수가 강한 모델에서는 접두어 없는 평서 지시가 같은 준수율을 낸다. 대표 2곳만 손댔고 서식 계약 안의 강조는 유지	rewrite	서드파티
B-17	codex:53	"몇 분 걸릴 수 있으므로 기본 백그라운드 실행 + 완료 대기"	4	5.1 권고는 진행 상황 주장을 도구 결과에 근거시키라는 것이다. 현재 스킬에는 표준 출력의 "완료" 문구를 exit code·파일 목록으로 확인하라는 지시가 없어, 시간 초과로 잘린 실행이 완료로 보고될 수 있다	add	HC

Low 7건 (flag만)

ID	위치	내용	왜
B-18	threadfolio-post:36	"★중요" 압박 표기	톤 규칙 자체는 서식 제약이라 유지 대상이고, ★가 붙은 재발 기록이 메모리에서 확인되지 않았다. 표현 완화만 제안하고 diff는 안 만듦
B-19	ytreport:70-140	보고서 프롬프트 안의 "5개 이상", "3~5개" 수량 지정	출력 형태 강제이긴 하나 수신자가 Fable 5.1이 아니라 Gemini다. 대상 모델 근거로 고칠 대상이 아니다
B-20	amaranth-review:31	"HC 지시 — 반드시 지킬 것"	보고 형식 자체는 업무 규약이라 유지. 표기만 완화 여지
B-21	4개 스킬 frontmatter	preamble-tier: 1, version: 1.0.0	인식하지 않는 키이고 소비처가 없어 죽은 화석이지만, HC 자신의 버전 관리 표기일 수 있고 무해해서 제거를 제안하지 않는다
B-22	last30days:646,1302	"각 칸을 5~15단어로"	출력 분량 지정이지만 비교 표 렌더링 제약이라 서식 고정 유지 항목에 걸린다
B-23	sermon-notes:49	기기 별칭이 구 이름이다	2026-08-26 명명 체계상 현재 이름은 gram이다. ssh config에 구 별칭이 남아 동작하므로 실패는 아니고 호칭만 어긋난다
B-24	codex:5,32	실행 모델명이 스킬에 두 번 더 적혀 있다	정본은 설정 파일인데 프롬프트에 사본이 있다. 실행 인자로는 안 쓰여 지금은 무해하지만 설정 변경 시 어긋난다

finding 없음 / 명시적 유지

design-ref-add는 발견 없음입니다. description이 한 줄에 트리거를 담은 올바른 형태이고 죽은 키가 없으며, 배포 승인 규칙의 날짜 표기는 HC provenance, "침묵 실패 금지"는 재발 기록이 있는 업무 제약입니다. 체크리스트 9항목을 본문에 나열한 것은 디자인팀 템플릿의 항목명과 정확히 일치함을 대조 확인해서, 어긋나지 않은 중복이라 유지했습니다.

그 밖에 유지 판정한 것: codex의 검수 절차와 자동배포 금지, amaranth-review의 안전 규칙 4개와 민감정보 표시 금지, ontology-ask의 즉흥 답변 금지(5.1은 낮은 effort에서 검색 대신 기억으로 답하는 경향이 있어 오히려 더 필요해졌습니다), threadfolio-post의 톤 규칙과 예시, last30days의 서식 계약 본문과 옛 복사본 자가점검, 전 파일의 날짜·출처 표기.

검증 메모

ID	사전 probe	사후 probe
B-01	스킬 1회 실행 후 커밋 메시지에 구형 모델명이 찍히는지	같은 명령으로 트레일러가 하네스 현행 규약을 따르는지
B-02	홈 루트에 이 스킬이 만든 폴더가 있는지 확인	실행 후 ~/Projects/<슬러그>/에 생성되고 홈 루트는 안 늘어나는지
B-03	현재 실행 후 텔레그램에 파일이 실제로 도착했는지(안 오면 침묵 실패 재현)	수정본 실행 후 응답의 "ok":true와 수신을 동시 확인
B-04	인증을 일부러 만료시켜 알림 경로가 도는지	같은 조건에서 재인증 안내가 텔레그램에 도착하는지
B-05	새 세션에서 로드된 라우팅 텍스트에 트리거 문구가 있는지 확인	같은 방법으로 when_to_use 문구가 포함되는지. 이어서 슬래시 없이 말했을 때 스킬이 걸리는지 A/B
B-06	3회 실행해 서식 계약 위반이 나오는지 기저율 측정	수정본으로 같은 3회. 위반율이 올라가면 되돌린다
B-07	같은 3회에서 불필요한 출처 블록이 새는지	수정본으로 같은 3회. 위반 0건 유지 확인
B-08	없음(사실 확인만). 하네스 버전 대조	도구 로드 동작이 그대로인지 1회 확인
B-09	조사 완료 후 후속 질문 3개를 던져 새 검색이 도는지	수정본으로 같은 3개. 재검색 0회 + 저장된 원문 인용이 유지되는지
B-10	저장 플로우를 태워 참조 파일을 실제로 읽는지	수정본으로 같은 요청. 읽기 발생 + 저장 경로 규약 준수 확인
B-11	파이프라인 1회 실행 후 캘린더 기록이 실제로 되는지	문구만 바뀌었으므로 동작 동일 확인(회귀 없음)
B-12	현재 테스트 케이스 수 출력	케이스를 1개 추가한 뒤 수정본 지시가 "전건" 통과를 요구하는지
B-13	새 세션에서 관련 문장을 말했을 때 스킬이 자동 호출되는지	수정본으로 같은 문장. 자동 호출이 유지되는지(깨지면 되돌린다)
B-14	없음	스킬 호출 시 중단된 모드의 재개를 되묻지 않는지
B-15	없음	"코덱스한테 맡겨"로 스킬이 걸리는지(라우팅 회귀 없음 확인)
B-16	도구 미지정 질의를 넣어 조사 전에 되묻는지	수정본으로 같은 질의. 되묻지 않고 조사를 먼저 하는지
B-17	실행을 일부러 시간 초과시킨 뒤 현재 스킬이 "완료"로 보고하는지	수정본으로 같은 조건. exit code와 git status 확인 후 "잘렸다"고 보고하는지

적용 전 주의

1. last30days는 서드파티 MIT 자산이고 심볼릭 링크 너머를 직접 고치면 다음 git pull에 날아갑니다. B-06~B-10, B-16은 모두 원 저자의 서식 계약 안쪽이라, 적용 전에 회귀 3회 A/B를 먼저 돌리기를 권합니다.
2. B-05는 라우팅 동작을 바꾸는 유일한 변경입니다. 하루 정도 관찰하십시오.
3. B-03·B-04의 대체 명령은 ~/.hermes/.env의 토큰을 읽습니다. 그 파일이 없는 세션에서는 토큰이 비어 전송이 실패하므로, 필요하면 토큰 부재 시 명시적으로 실패를 알리는 가드를 한 줄 더 넣으십시오.

에이전트 C · 6파일 · 18건 (High 5 / Medium 9 / Low 4)

담당 6개: ebook(1,028행), gstack(962행), notebooklm(976행), parallel, project-harness, agent-korea-watch. 합계 3,236행, 약 205KB.

소유권: HC 작성 4개, 서드파티 1개(gstack), 혼합 1개(notebooklm: 앞 596행 upstream, 597행부터 HC 작성 한국어 커스텀 워크플로우 2종).

C의 결론은 명확합니다. Action별로 remove가 0건이었습니다. 이 자산군의 문제는 "말이 많다"가 아니라 "세상이 바뀌었는데 문서가 안 바뀐 것"입니다. 18건 중 9건이 거기 해당합니다.

Medium 9건

ID	위치	근거	패턴	왜	Action	소유
C-06	parallel:26,71	"병렬은 토큰을 몇 배 쓰므로 정말 이득인 작업에만" / "에이전트 수는 보통 3개 이하"	1b + 1c	이관 가이드는 위임을 억누르지 말고 서브에이전트를 자주 쓰라고 권한다. 서브에이전트가 비차단이 되면서 이 게이트가 전제한 비용 모델(본 세션을 붙잡고 몇 배 토큰) 자체가 바뀌었다. 숫자 상한 3개는 작업 구조가 아니라 옛 비용 감각에서 나온 임의값이다. HC의 토큰 절약 원칙은 현행 제약이므로 게이트 자체는 유지하고 인위적 상한만 제거	rewrite	HC
C-07	parallel:60	해당 지시 부재. 발사 방법만 있고 비동기 대기 규약이 없다	4 / add	비차단 서브에이전트 환경에서 필요한 두 가지가 빠져 있다. ① 발사 후 본 세션을 붙잡고 대기하지 말 것 ② 아직 안 돌아온 에이전트의 결과를 지어내지 말 것. 미도착 결과 날조는 문서화된 실패 모드다	add	HC
C-08	project-harness:68-69	생성되는 템플릿 안의 "조사 → 계획(승인) → TDD → 코드리뷰 → 마무리" 고정 안무	1b + 1c + 2	이관된 프롬프트의 고정 단계 안무는 5.1에 과처방이라 출력 품질을 떨어뜨린다. 게다가 플러그인이 세션 시작 시 자기 방법론을 이미 주입하므로 프로젝트 지시가 같은 것을 한 번 더 못박는 중복이다. 모든 변경에 걸리는 무조건 승인 게이트는 불필요한 조기 정지와도 충돌	rewrite	HC
C-09	project-harness:50-70	템플릿에 범위 고정 블록이 없다	4 / add	이관 가이드가 명시적으로 추가를 권하는 두 항목이 빠져 있다. ① 요청을 만족하는 최소 변경, 옆 코드 리팩터 금지 ② 파일 전면 재작성 대신 표적 편집. HC의 코딩 프로젝트 지침이 생성되는 바로 그 지점이라 여기가 정확한 자리다	add	HC
C-10	notebooklm:118-127	"실행 전 물어볼 것: 생성 명령, 다운로드, 대기…"	1b	Claude Code의 권한 시스템이 이미 실행을 게이트한다. 사용자가 직접 호출한 스킬 안에서 비파괴 명령에 또 확인을 받는 것은 불필요한 조기 정지다. 대기 계열은 확인이 아니라 서브에이전트 위임이 답이고 같은 파일의 다른 절이 이미 그렇게 말한다(자기모순). delete는 HC의 삭제 금지 원칙상 게이트 유지	rewrite	서드파티
C-11	notebooklm:2, 597-976	같은 유튜브 워크플로우가 ytreport·sermon-notes와 중복. 목적지 경로와 섹션 제목이 그대로 겹친다	2 + 4	이미 갈라졌다. ytreport에는 추가된 라우팅이 사본에는 없다. 같은 요청이 어디로 가느냐에 따라 결과가 달라진다. 41KB 파일이 통째로 로드되는 비용도 있다	rewrite (라우팅만)	HC
C-12	gstack:412-413	"셸 대신 전용 도구를 선호하라"	1c + 4	HC의 현행 세션은 하네스 차원에서 정반대를 지시한다. 스킬이 하네스를 덮어쓰는 도구 선택 규범을 들고 있으면 세션마다 어느 쪽을 따를지 흔들린다. 도구 선택은 모델 판단과 하네스 소관이고 스킬이 상위가 아니다	rewrite	서드파티
C-13	gstack:523-527	"의심스러우면 무조건 스킬을 발동하라 … 언제나 더 나은 결과를 낸다"	1a	문서화된 압박 패턴이다. "언제나 더 낫다"는 검증 불가한 절대 주장이고, "의심스러우면 무조건"은 바로 위 35줄짜리 라우팅 표를 무력화한다. gstack 자신의 설정 및 HC의 "추천 먼저, 제작은 승인 후" 원칙과도 충돌한다	rewrite	서드파티
C-14	gstack:421	영어 금칙어 6단어 목록	1e + 1f	이전 세대 버릇 잡기용 금칙어다. 5.1 가이드는 문체 문제를 금칙어가 아니라 긍정 지시로 다루라고 권한다. HC 환경은 한국어가 1차 산출 언어라 영어 6단어 목록의 적중률이 더 낮고, 문체 대응은 별도 파이프라인이 담당한다. 같은 줄의 em dash 금지는 HC 지침과 일치하는 현행 제약이라 유지	rewrite	서드파티

Low 4건 (flag만)

ID	위치	내용	왜
C-15	gstack:576	특정 도구군 전면 금지, 근거는 "느리고 불안정하다"	이전 세대 성능 주장이 근거다. 자체 도구를 밀기 위한 것이라 실용적 이유는 있으나 대상 모델 환경에서 재검증되지 않았다. 서드파티이고 오작동 위험이 낮아 flag만
C-16	ebook:1021	"이 세 파일은 실패작이니 쓰지 않는다"	실측 결과 그중 하나는 존재하지 않는다. 없는 파일을 금지하는 문장이라 무해하지만, 이 절 전체가 "파일 존재"를 사실로 서술하므로 다음 점검 때 신뢰도를 깎는다. 삭제 금지 원칙상 문장 제거는 제안하지 않고 사실만 표시
C-17	ebook 구조 전반	1,028행 단일 파일이 5개 스킬의 공유 절차를 겸한다	/millie-ebook 하나만 쓰려 해도 캡처 전용 550행까지 전부 컨텍스트에 올라온다. 공유 구간을 참조 파일로 분리하는 편이 맞으나 현재 중복이 실제로 어긋났다는 증거가 없어 이번 회차 diff에는 넣지 않았다
C-18	notebooklm:78-92	본문이 발동 조건 11개를 다시 나열한다	본문은 트리거가 이미 걸린 뒤에 로드되므로 여기서 다시 나열해도 라우팅에 기여하지 않는다. 무해한 중복이라 Low, 다만 두 곳이 갈라지면 혼선이 생긴다

finding 없음 / 명시적 유지

ebook: 3대 장벽 서술, 캡처 파라미터·좌표·보정 규칙은 유지입니다. 좌표에는 이미 "절대 신뢰하지 말고 캡처로 대조"라는 자기무효화 장치가 붙어 있습니다. 「금기」 절 전체(앱 재빌드 금지, 반납·연장·삭제 버튼 금지, 비밀번호 전사 금지, 프로필 우회 금지)는 재현되는 실패에 대한 금지이자 업무 제약이라 유지하고, C-05는 그 안의 행 번호 하나만 건드립니다. 압박 표현 grep 히트는 전부 이 업무 제약에 붙어 있어 완화 제안이 없습니다.

parallel: 게이트 판정 기준, 분해 지침, 취합 규약, "침묵 실패 금지", "호출될 때만" 정책은 전부 유지입니다. 특히 "호출될 때만"은 HC가 의도적으로 고른 범위 정책입니다.

project-harness: 사전 확인, 설정 병합 절차, 학습모드 블록, 에이전트팀 스캐폴딩의 "제안만" 문구는 유지입니다. 전제도 재확인했습니다. 플러그인이 실제로 설치되어 있고 전역은 꺼져 있어 이 스킬의 전제가 현재도 유효합니다.

gstack: 신뢰할 수 없는 콘텐츠 처리 4규칙은 보안 경계라 삭제 후보가 아닙니다. plan mode 계약, 완료 상태 프로토콜(상태 경계를 명시적으로 선언하라는 5.1 권고와 일치), 명령 사전 표는 전부 유지입니다.

notebooklm: 설치·전제조건·출력 스키마·종료 코드·알려진 제약·문제해결 절은 도구 계약 상세라 유지입니다. 흔한 실패는 설명 부족이지 장황함이 아닙니다. "폴링하지 말고 서브에이전트에 맡겨라"는 비동기 위임 권고와 일치해 유지입니다.

전 파일 공통: 옛 세대 관용구 grep(think step by step, scratchpad, budget_tokens, temperature, 퇴역 모델명, 서술 억제 문구, 서식 금지 문구)이 6개 파일 전부에서 0건이었습니다.

검증 메모

ID	사전 probe	사후 probe
C-01	원본에서 금지 명령 5건 확인	보고서 1건 생성 후 실제 도착과 메시지 id 확인. 수정본에는 호출부 0건
C-02	해당 LaunchAgent가 목록에 없고 지목된 로그가 8/23 이후 정지했음을 확인	스킬 실행 시 현행 3개 로그를 읽고 "미등록" 오판단 없이 상태를 보고하는지
C-03	원본에 평문 키가 2곳(상수 + 호출) 있음을 확인	정리 문서 1건 전송 후 수신 확인. 파일 내 평문 키 0건
C-04	"교보에서 대출한 책 캡처해줘"로 어느 스킬이 뜨는지 기록	같은 문장에 전용 스킬이 뜨는지, "킨들로 보내줘"만 줬을 때는 ebook이 유지되는지
C-05	실제 스크립트에서 해당 코드가 38행임을 확인	같은 명령 재실행 결과와 스킬 인용 행 번호가 일치하는지(소스가 바뀌면 재점검 필요)
C-06	독립 3영역 과제를 던지고 실제 발사된 에이전트 수 기록	같은 과제에서 범위 수만큼 발사되는지, 게이트의 "부적합" 판정은 그대로인지
C-07	발사 직후 "결과 어때?"라고 물어 미완료 결과를 지어내는지 관찰	같은 질문에 "아직 돌고 있다"로 답하고 완료 알림 후에야 취합하는지
C-08	하네스 적용 프로젝트에서 소규모 변경 1건 요청 후 승인 게이트 횟수 세기	되돌리기 어려운 결정에만 확인이 걸리는지, 산출물 품질이 떨어지지 않는지
C-09	기존 프로젝트에서 "이 함수 버그 고쳐줘" 후 인접 코드 리팩터 발생 여부	새 템플릿 프로젝트에서 같은 요청. 변경 라인 수 비교로 최소 변경 유지 확인
C-10	오디오 1건 생성 요청 후 확인 프롬프트 횟수 기록	확인 없이 시작하고 결과 id를 즉시 보고하는지, delete는 여전히 확인을 받는지
C-11	"이 유튜브 보고서 만들어줘" 3회로 어느 스킬로 가는지 분포 기록	같은 문장 3회에 전용 스킬로 일관 라우팅되는지
C-12	스킬 실행 중 파일 읽기가 셸인지 전용 도구인지 관찰	같은 실행에서 하네스 지시를 따르는지
C-13	스킬 목록에 없는 잡담성 질문 5개로 스킬이 몇 번 발동되는지	같은 5개에 발동 0회, 목록에 있는 트리거 5개에는 여전히 발동하는지
C-14	산출 텍스트에서 em dash와 해당 6단어 빈도 측정	같은 측정 반복. em dash 0 유지, 문장 자연스러움이 떨어지지 않는지

적용 전 주의

1. gstack은 템플릿에서 자동 생성됩니다. C-12·C-13·C-14는 upstream 또는 오버레이 경로로 넣어야 살아남습니다.
2. notebooklm의 C-10은 upstream 구간이라 재설치 시 소실됩니다. C-01·C-11은 HC 커스텀 구간이라 안전합니다.
3. C-11의 본문 380행 통합은 어느 쪽이 정본인지 확정이 필요해 diff에 넣지 않았습니다. 현재 hunk는 라우팅만 바꿉니다.
4. C-01·C-03을 반영하면 두 파일에서 평문 credential이 사라집니다. 다른 스킬·스크립트에도 같은 문자열이 남아 있을 수 있으니 전수 점검을 권합니다.

에이전트 D · 15파일 · 15건 (High 4 / Medium 7 / Low 4)

담당 15개: kyobo-ebook, seoul-ebook, millie-ebook, duplus-ebook, bookshelf, book-to-skill, incident, corp-card, codex-infographic, learn, diagram-design, gpt-image, ego-browser, humanize, humanize-redo.

소유권: HC 작성 9개, 서드파티 6개. ego-browser는 심볼릭 링크가 앱 번들 안을 가리켜 어떤 수정도 앱 업그레이드 때 사라집니다. book-to-skill은 벤더 파일에 HC 블록 8줄이 삽입된 형태입니다.

Medium 7건

ID	위치	근거	패턴	왜	Action	소유
D-05	codex-infographic:6	라우팅 description에 실행기 모델명이 박혀 있다	2	메모리 기준 기본 실행기는 2026-07-11에 바뀌었다. 라우팅에 박힌 버전은 재고정 없이 낡는다. 모델명을 지워도 스킬 동작에는 영향이 없다	rewrite	HC
D-06	duplus-ebook:30,32	비교표의 kyobo 열 값이 kyobo 자신의 표와 다르다	2	세 ebook 스킬의 비교표가 서로 다른 값을 말해 "어느 스킬을 쓸까" 판단이 파일마다 달라진다	rewrite	HC
D-07	seoul-ebook:213-234	"규명 끝, 다시 파지 말 것" 아래 조사 과정 수치가 18줄	1c + 1d	결론과 운용에 쓰이는 크기 의미만 살리면 되고 조사 과정 수치는 메모리에 이미 있다. 5.1은 긴 턴을 도니 결론이 근거 나열에 묻히면 재조사를 시도할 여지가 커진다	rewrite	HC
D-08	gpt-image:137	"성공한 뒤 정중하게 리포지토리 Star를 요청하라"	1d + 1c	벤더가 사용자에게 Star를 요청하도록 시키는 지시다. 지시 준수가 강해 실제로 매번 요청 문구를 붙인다. HC 이익과 무관한 벤더 마케팅이라 요청 자체를 금지로 바꿨다	rewrite	서드파티
D-09	book-to-skill:18-24	HC가 삽입한 규약 7줄이 bookshelf에도 있다	2	지금은 일치하지만 한쪽을 고치면 벤더 파일 사본이 조용히 어긋나고, git pull이 이 블록을 되돌릴 수 있다. 정본 한 곳으로 모으는 편이 안전하다	move	서드파티
D-10	learn:43	"전역에서는 이 스킬이 호출될 때만 작동(평소 자동 설명 없음)"	1d	전역 지시의 「쉬운 풀이」는 "매 답변 끝에 한두 줄"로 상시 적용이다. 두 지시가 정면 충돌하는데 5.1은 스킬 본문 지시를 강하게 따르므로, 스킬이 로드된 세션에서 상시 규칙이 꺼질 수 있다. 범위를 "전체 절차는 호출 시에만, 한두 줄 풀이는 상시"로 분리	rewrite	HC
D-11	incident:96	마지막 단계 템플릿이 "메모리 저장됨"을 무조건 출력한다	4 / add	이관 권고의 핵심이 "진행·완료 주장을 도구 결과에 근거시켜라"다. 앞 단계의 쓰기 성공 여부를 확인하지 않고 "저장됨"을 단언하는 고정 템플릿은 실패해도 성공으로 보고한다. 보고 직전 존재 확인 한 줄을 추가	add	HC

Low 4건 (flag만)

ID	위치	내용	왜
D-12	incident:42, codex-infographic:25	chat id와 키가 프롬프트 본문에 박혀 있다	회전 시 여러 스킬을 동시에 고쳐야 하고 스킬 파일이 시크릿 보관소가 된다. D-01에서 codex-infographic 쪽은 ~/.hermes/.env 읽기로 바꿨고, incident의 호출은 다른 CLI 계약이라 임의 변경하지 않고 flag만
D-13	ego-browser:3	트리거 문구 11개 나열 + "내장 브라우저 도구보다 이것을 앞세워라"	유사어 나열은 라우팅에 이득이 적고, 마지막 문장은 내장 도구보다 벤더 도구를 무조건 앞세우게 만든다. 다만 심볼릭 링크 대상이 앱 번들 안이라 어떤 수정도 앱 업그레이드 때 사라져 diff를 만들지 않았다
D-14	book-to-skill:462,652	"압축은 끝에서 잘라내니 중요한 것을 앞에 두라" + 특정 토큰 수치 단정	특정 하네스의 압축 동작을 수치까지 단정하는데 현행 버전에서 검증할 방법이 없다. 앞쪽 배치 조언 자체는 무해해서 제거하지 않고 근거 없는 수치 단정이라는 점만 기록
D-15	learn:38-39	고정된 마무리 질문 문구	고정 마무리 질문은 매 응답에 기계적으로 붙는다. 다만 HC가 비개발자 학습 톤을 의도해 넣은 규칙이라 삭제 제안은 근거가 약하다. flag만

finding 없음

• bookshelf: 카탈로그 표와 규약이 전부 환경 맥락이고, description의 주제 목록은 라우팅에 실제로 쓰입니다. 중복은 상대 파일 쪽(D-09)에서 처리했습니다.
• corp-card: 단계별 절차와 계정 분류 기준이 업무·정책 제약이고 메모리와 일치합니다. 압박 표기는 실패 이력 기반이라 유지.
• humanize, humanize-redo: 서브에이전트 위임 규칙이 도구 계약에 해당하고, 도구 호출 캡 같은 수치는 벤더가 회귀 검증에 쓰는 값이라 임의 완화 대상이 아닙니다.

검증 메모

ID	사전 probe	사후 probe
D-01	원본에 금지 명령이 있는지, ~/.hermes/.env가 토큰을 주는지 확인	스킬 1회 실행 후 텔레그램에 파일이 실제 도착했는지. 요청이 200이면서 메시지가 보여야 통과
D-02	같은 파일 168행의 폐기 선언과 291행 표가 어긋나는지 대조	필수 인자 없이 실행해 오류를 재현한 뒤, 수정된 표 문구대로 하면 복구되는지 확인
D-03	kyobo 원본 표와 millie 비교표 값 대조	400쪽 책 1권으로 실측 시간을 재서 표 값과 맞는지 확인. 다르면 kyobo 원본 표까지 함께 갱신
D-04	실제 배포된 스타일 가이드의 hex 확인	새 프로젝트에서 첫 실행 질문이 뜨는지 확인. 여전히 안 뜨면 게이트 조건 자체를 재설계
D-05	메모리에서 현재 기본 모델 확인	실행 로그에서 실제 사용 모델 확인. 라우팅은 모델명 제거 후에도 "인포그래픽" 요청에 걸려야 한다
D-06	duplus 표와 kyobo 원본 표 대조	같은 책을 kyobo로 뽑아 결과와 소요 시간이 표 값과 맞는지 확인
D-07	결론이 메모리에 남아 있는지, 뒤 절이 크기 의미에 의존하는지 확인	압축본만 읽은 세션에서 같은 질문에 재조사 없이 "불가" 답이 나오는지, 각주·로마자 처리가 그대로 동작하는지
D-08	원본에서 Star 요청 문구 위치 확인	이미지 생성 1회 실행 후 응답에 Star 요청 문구가 안 붙는지 확인
D-09	두 규약이 지금 일치하는지 diff로 확인	새 책 1권을 돌려 인덱스로 저장되고 대상 아닌 입력은 중단되는지 확인. 실패하면 원래 길이로 되돌린다
D-10	전역 지시의 「쉬운 풀이」 절과 스킬 43행을 나란히 확인	스킬이 로드된 세션에서 새 기술 용어가 나왔을 때 답변 끝에 한두 줄이 붙는지 확인
D-11	쓰기 권한이 없는 상태를 만들고 돌려 "저장됨" 오보고가 나오는지 재현	같은 실패 상황에서 보고문이 실패 사실을 적는지 확인. 정상 상황에서는 기존과 동일한 보고가 나와야 한다

7. frontmatter 통합 16건

감사 4명이 끝난 뒤, 담당이 갈려 일부만 정리됐던 frontmatter를 proposed/ 전체에 일관되게 맞추는 작업을 한 번 더 돌렸습니다. 변환 규칙은 A가 쓴 패턴 그대로입니다. triggers: 리스트 항목을 자연어 1~3줄로 바꾸고, 내용은 기존 description에서만 뽑아 새 정보를 창작하지 않으며, 본문은 한 글자도 건드리지 않습니다.

총 16건이지만 두 파일(codex-infographic, gstack)이 두 변경을 겹쳐 받아 표는 14행입니다.

gstack은 서드파티라 when_to_use 본문도 원문 언어인 영문을 유지해 description과 톤을 맞췄습니다. 나머지 13건은 한국어입니다.

8. 파일별 hunk 수

findings/ALL.diff는 orig/와 proposed/ 전체를 비교한 스냅샷입니다. 53개 파일 중 45개에 변경이 있고, hunk는 108개, 전체 1,816줄입니다. hunk 수가 많은 파일이 손댈 곳이 많은 파일입니다.

변경이 전혀 없는 파일이 8개 있습니다. 감사 결과 손댈 것이 없었거나 Low flag만 있었던 파일들입니다. 대표적으로 aside(발견 없음), design-ref-add(발견 없음), bookshelf·corp-card·humanize·humanize-redo(발견 없음), ego-browser(앱 번들 안이라 수정이 무의미해 diff 생략)입니다.

9. 범례

패턴 코드

각 발견에는 감사 절차 문서가 정의한 안티패턴 코드가 붙어 있습니다.

Action 값

Confidence

• High: 현행 문서에 명시되어 있거나 대상 모델에서 실제로 오류가 난다. diff에 반영됨.
• Medium: 일관되게 널리 관찰되는 동작. diff에 반영됨.
• Low: 관용구로 추정한 것. 표시만 하고 편집은 제안하지 않는다. diff에 없음.

High·Medium은 총 59건이고 이것이 diff에 반영됐습니다. Low 19건은 이 보고서 안에만 있습니다.

10. 2차(wave 2) 후보

이번 회차 범위 밖이라 손대지 않은 프롬프트 자산입니다. 전부 미착수이고 HC 결정 대기 상태입니다.

1차 결과를 며칠 써 보고 문제가 없으면 그때 2차를 여는 편이 낫습니다. 1차만 해도 손볼 것이 108 hunk입니다.

11. 용어 풀이