[{"data":1,"prerenderedAt":298},["ShallowReactive",2],{"content-/skills-due-diligence-context-diet":3,"all-pages-for-dir":276,"related-/skills-due-diligence-context-diet":277,"og-image-/skills-due-diligence-context-diet":297},{"id":4,"title":5,"body":6,"category":256,"concepts":257,"description":258,"extension":259,"meta":260,"navigation":261,"ogImage":257,"path":262,"project_name":263,"published":264,"publishedAt":265,"seo":266,"source":267,"stem":268,"tags":269,"todo":257,"unpublished":264,"updatedAt":257,"__hash__":275},"pages/2026-09/2026-09-05/skills-due-diligence-context-diet.md","Claude Code のスキル56本を棚卸しした。記事1本ごとに10万字の必読連鎖が走っていた",{"type":7,"value":8,"toc":244},"minimark",[9,13,21,24,28,37,40,43,46,49,52,55,58,62,65,68,75,78,82,85,88,92,95,162,165,168,171,175,178,185,192,195,198,209,215,222,225,228,238],[10,11,12],"p",{},"朝いちばんに、バックグラウンドで走らせていた dev サーバーが勝手に止まった。\nビルドが壊れたわけではなく、実行環境のメモリが足りずに落とされたという。",[10,14,15,16,20],{},"「これ Node のプロセス52個やばすぎるんで、ちょっと掃除してほしい」と投げて ",[17,18,19],"code",{},"/procs"," を走らせたら、実際には55個あった。\n掃除後は16個。\n空きメモリは 6.0GB から 10.2GB に戻った。",[10,22,23],{},"プロセスを落とせばメモリは戻る。\n戻らないのは、毎朝の記事づくりが1本あたりどれだけの指示を読み込んでいるかのほうである。\nこちらは掃除しても1字も減らない。",[25,26,27],"h2",{"id":27},"記事を1本書くのに何を読ませていたのか",[10,29,30,31,36],{},"Eric Provencher の「GPT-6 Astra 時代に向けてスキルとプロンプトを考え直す」というポストを読んで、",[32,33,35],"a",{"href":34},"/rethinking-skills-for-gpt-6-astra","翻訳記事","を1本書かせた。\nそのとき起動したスキルは、content-management、japanese-tech-writing、doc-communication、svg-diagram、honda-sakubun の5本である。",[10,38,39],{},"図は1枚も入れていない。\nそれでも svg-diagram が入っている。",[10,41,42],{},"自分のスキルが今どういう状態になっているのか、そういえば一度も数えたことがない。\nそこで、このリポジトリ直下のプロジェクトレベルと、全リポジトリ共通のユーザーレベルの両方を対象に、デューデリジェンスをさせた。",[25,44,45],{"id":45},"一覧に常時載っている量",[10,47,48],{},"対象はユーザーレベル42本とプロジェクトレベル14本の計56本。\nあわせて、同じ一覧に載るコマンド46本の説明文と、Codex 用に置いてあるコピー9本も見た。",[10,50,51],{},"一覧に常時載る説明文は、スキル56本で合計10,110字。\n平均181字で、最長は488字あった。\n200字を超えるものが18本ある。\nコマンドぶんを足すと、約14,000字がこのリポジトリで開く全セッションの冒頭に毎回載っていることになる。",[10,53,54],{},"長い説明文の中身を見ると、原因は2つしかなかった。\n1つは、本文に置くべき運用ルール（アカウントの使い分け、経路の選択、テーブルの仕様）を説明文に書いていること。\nもう1つは、発動しそうな言い回しを思いつく限り並べていることである。",[10,56,57],{},"ついでに、102本の frontmatter を PyYAML で読み直させたら、2本が構文エラーで落ちた。\nどちらも、引用符なしの説明文に「TRIGGER: 」のような「コロンと空白」が入っていた。\nこれだと YAML の mapping として読めない。\n一覧での見え方も違っていて、片方は説明文の代わりに本文の H1 が表示され、もう片方は名前だけが並んでいた。\n説明文を書いたつもりで、いつ使うかをモデルに伝える手段を失っていたわけだ。",[25,59,61],{"id":60},"doc-communication-が連れてくるもの","doc-communication が連れてくるもの",[10,63,64],{},"報告書が上がってきた時点で、私は doc-communication が犯人だと思っていた。\n呼ばれる回数が多いうえに、中身も大きいのだろうと。",[10,66,67],{},"結論を聞いたら、半分外れていた。\ndoc-communication の本文は4,486字で、むしろ小さいほうだった。\n問題は、そこから無条件に svg-diagram（36,333字）と grid-alignment.md（16,570字）を連れてくる指示が書いてあったことである。\n合わせて52,903字。",[10,69,70,71,74],{},"さらに content-management が必ず doc-communication を呼ぶ。\nつまり記事や日記を1本書くたびにこの連鎖が走る。\n「必ず読む」と指示された量だけを合計すると、記事1本あたり101,884字になり、その52%が図解ルールだった。\n5週間のログでは、content-management が151回、honda-sakubun が134回、doc-communication が112回呼ばれている。\n毎朝の ",[17,72,73],{},"/make-diary"," が27回走った結果である。",[10,76,77],{},"犯人が本文の大きさではなく連鎖の張り方だとわかったので、修正案は項目ごとに Before と After の形で書いてほしいと頼んだ。\nどこをどう書き換えるのかが文面で見えないと、承認したあとで何が起きるか判断できない。\n報告書には8項目ぶんの Before と After が並んだ。",[25,79,81],{"id":80},"codex-レビューで出た指摘","Codex レビューで出た指摘",[10,83,84],{},"決裁フォームを出す前に、報告書を Codex で3回レビューさせた。",[10,86,87],{},"効いたのは2回目で、指摘は2つだった。\n1つは、決裁2と決裁3が同じ4本のスキルを二重に扱っていたこと。\nもう1つは、Mac 側の集計をどの条件で行うかと、説明文の変更を誰が担当するかが、決裁の間で食い違っていたことである。\nどちらも書いてある内容の誤りではなく、決裁の切り分けが重なっているという指摘だった。\n自分で読んだときは、判断する項目が4つあるとしか見ていなかった。",[25,89,91],{"id":90},"_4件の決裁と実際に減った量","4件の決裁と、実際に減った量",[10,93,94],{},"判断が必要な項目は4件で、いずれも推奨案が示されていた。\nローカルに立てた決裁フォームの3択ボタンで答えて、4件とも推奨案 A にした。",[96,97,98,114],"table",{},[99,100,101],"thead",{},[102,103,104,108,111],"tr",{},[105,106,107],"th",{},"決裁",[105,109,110],{},"選んだこと",[105,112,113],{},"結果",[115,116,117,129,140,151],"tbody",{},[102,118,119,123,126],{},[120,121,122],"td",{},"1. 記事執筆の連鎖",[120,124,125],{},"作図時だけ svg-diagram を読む。本文もルーター化",[120,127,128],{},"本文を36,333字から12,153字へ。切り出した7節（25,634字）は参照ファイルへ移動",[102,130,131,134,137],{},[120,132,133],{},"2. 呼ばれていない13本",[120,135,136],{},"Mac の実績と突き合わせてから性質ごとに分ける",[120,138,139],{},"未着手。両機で同じ数え方をする集計スクリプトだけ用意した",[102,141,142,145,148],{},[120,143,144],{},"3. Codex 用のコピー",[120,146,147],{},"正本から生成して同期する",[120,149,150],{},"同期スクリプトを新設し、pre-commit に検査を追加",[102,152,153,156,159],{},[120,154,155],{},"4. 説明文の短縮",[120,157,158],{},"200字超の18本を直す",[120,160,161],{},"18本を59字から136字に。56本の合計は10,110字から7,175字、最長は488字から195字へ",[10,163,164],{},"決裁1の分割では、節の本文を一字も変えずに参照ファイルへ移させた。\n本文には要点と参照先だけを残す。\n文章を書き直すと、あとで「効きが変わったのは分割のせいか、書き換えのせいか」が切り分けられなくなる。",[10,166,167],{},"決裁2だけは実施していない。\n「5週間で0回」はあくまで Windows 機の話だからである。\n8月からの主機は Mac のほうで、そちらのログは数えていない。\n片方の機の記録だけを根拠に13本を退避させたら、向こうで毎日使っているものを消しかねない。",[10,169,170],{},"Codex 用に置いてあった9本のコピーは、8本が正本と食い違い、2026年5月15日の状態で止まっていた。\n古い指示が読まれる状態を放置していたことになる。",[25,172,174],{"id":173},"_1ヶ月後に戻せる形にする","1ヶ月後に戻せる形にする",[10,176,177],{},"コミットする前に、戻し方を先に決めさせた。\n1ヶ月後に「やっぱり前のほうが書きやすかった」と思ったとき、どこを叩けば元に戻るのかがわからない変更は、実質やり直せない。",[10,179,180,181,184],{},"そこで決裁ごとに独立したコミットに分けた。\n戻したい決裁のハッシュを ",[17,182,183],{},"git revert"," するだけで、他の決裁に影響を与えずに打ち消せる。\n報告書にも、どのコミットを戻すと何が消えるのかを書かせてある。\nたとえば svg-diagram の分割を戻すと、参照7本が消えて本文が36,333字に戻る。",[10,186,187,188,191],{},"学習ゲートはこの日の作業では ",[17,189,190],{},"LEARN_SKIP=1"," で通した。",[25,193,194],{"id":194},"残した2つのルール",[10,196,197],{},"作業のあとで、教訓を2つ、ルールとして書かせた。\nどちらも今日の事故がそのまま根拠になっている。",[10,199,200,208],{},[201,202,203,204,207],"strong",{},"説明文（",[17,205,206],{},"description","）は必ず二重引用符で囲む","。\n引用符なしで「コロンと空白」を含むと YAML として壊れ、一覧に説明文が出ない。\n102本を検証して2本が該当した。",[10,210,211,214],{},[201,212,213],{},"説明文には「何をするか」と「いつ使うか」だけを120字前後で書く","。\n運用ルールも仕様も発動語の羅列も、本文へ移す。\n本文自体も要点と索引にとどめる。\n手順と作例と事故記録は参照ファイルへ置き、その作業をする日にだけ読ませる。",[10,216,217,218,221],{},"締めゲートに引っかかった副産物として、もう1つ規則が増えた。\n以前書いた計画書が、対象として ",[17,219,220],{},".claude/skills/"," という置き場全体を宣言していたのである。\nそのせいで、無関係なスキルを直しただけのコミットが止まった。\n作る予定のスキルは、置き場ごと掴まずにスキル単位まで絞って書く。",[25,223,224],{"id":224},"残っているもの",[10,226,227],{},"Mac で同じ集計を取る手順は報告書に書かせて、Windows 側の結果と一緒にコミットしておいた。\n向こうで pull したセッションが同じスクリプトを走らせれば、両機で0回のものだけを取り出せる。",[10,229,230,231,233,234,237],{},"コマンド側の棚卸しは別の機会に回した。\nこちらは46本あり、",[17,232,73],{}," が32,408字、",[17,235,236],{},"/update-korea-chip-exports"," が24,235字と、スキルより太いものが混じっている。\nスキルを削った直後に同じ作業を続けると、どちらが効いたのかがわからなくなる。",[10,239,240,241,243],{},"朝に消した39個のプロセスは、放っておけばまた増える。\n連鎖のほうは、図を描くと決めた日にだけ svg-diagram へ伸びる形になった。\n明日の ",[17,242,73],{}," が最初の実測になる。",{"title":245,"searchDepth":246,"depth":246,"links":247},"",2,[248,249,250,251,252,253,254,255],{"id":27,"depth":246,"text":27},{"id":45,"depth":246,"text":45},{"id":60,"depth":246,"text":61},{"id":80,"depth":246,"text":81},{"id":90,"depth":246,"text":91},{"id":173,"depth":246,"text":174},{"id":194,"depth":246,"text":194},{"id":224,"depth":246,"text":224},"dev",null,"朝の Node プロセス掃除から始まって、ユーザーレベル42本とプロジェクトレベル14本のスキルを棚卸しした。記事を1本書くたびに10万字の指示が必読になり、その半分が図解ルールだった。決裁4件で連鎖を切り、説明文を短くした記録。","md",{},true,"/skills-due-diligence-context-diet","claude-code-tools",false,"2026-09-05T00:00:00.000Z",{"title":5,"description":258},"make-diary","2026-09/2026-09-05/skills-due-diligence-context-diet",[270,271,272,273,274],"Claude Code","スキル","コンテキスト","Codex","リファクタリング","8KEdDf_dGaRTVX0scV8TYfot_qkF9fqj3IoNulV0Ep4",[],[278,281,285,289,293],{"title":279,"path":280,"publishedAt":265},"2026年9月5日の開発日記 - ひと月遅れで届く開示を追う仕組みと、記事1本ごとに走っていた10万字の連鎖","/2026-09-05-diary",{"title":282,"path":283,"publishedAt":284},"OpenAIのcodex-securityは何をするツールか — 中身を読んで、このリポジトリに使えるか判断した","/openai-codex-security-overview","2026-07-29T00:00:00.000Z",{"title":286,"path":287,"publishedAt":288},"Excel差分検出スキルとCFマッピングJSON自動生成 - Codex4ラウンドで計画を磨いた1日","/excel-diff-cf-mapping","2026-04-17T00:00:00.000Z",{"title":290,"path":291,"publishedAt":292},"2026年1月14日の開発日記 - Claude Code×Codex連携とtax-assistant大規模改修","/2026-01-14-diary","2026-01-14T00:00:00.000Z",{"title":294,"path":295,"publishedAt":296},"AIレビューのモデル指定が既定値に戻る問題を、手順書に書いて止めた","/codex-review-model-pinning","2026-09-07T00:00:00.000Z","https://log.eurekapu.com/og/blog/skills-due-diligence-context-diet.png?v=2026-09-05T00%3A00%3A00.000Z&title=Claude%20Code%20%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB56%E6%9C%AC%E3%82%92%E6%A3%9A%E5%8D%B8%E3%81%97%E3%81%97%E3%81%9F%E3%80%82%E8%A8%98%E4%BA%8B1%E6%9C%AC%E3%81%94%E3%81%A8%E3%81%AB10%E4%B8%87%E5%AD%97%E3%81%AE%E5%BF%85%E8%AA%AD%E9%80%A3%E9%8E%96%E3%81%8C%E8%B5%B0%E3%81%A3%E3%81%A6%E3%81%84%E3%81%9F&author=Kei%20Komatsu&sig=ff7ca56c5090ef9e",1788821552580]