Grep の先頭250行は、一致した183ファイルのうち42ファイルしか見ていませんでした
記事リポジトリで「hook」を探したところ、一致は1,312行・183ファイル。ripgrep・git grep・grep の速さは11〜35 msで差がなく、効いたのは出力の量と順番でした。先頭250行の取りこぼしを事前に見積もるスクリプトと、探索の順番を実測値つきでまとめます。
つまづき集を毎回全文読ませるのをやめて、番号で一節だけ引くようにしました — 約105KBが約1.5KBになった記録
Web サイト運用のつまづきを書き溜めたメモ（約105KB）を、番号で一節だけ引く仕組みに変えた記録です。最初の抽出スクリプトは120番号のうち30しか引けず、#70 は0バイトを返しました。直した awk と、節の大きさの実測値を残しています。
毎回読ませる指示ファイルを半分にした夜、削る前に3つの引き出しへ分けました
指示ファイルが長くなるほど、書いたはずの決まりごとが守られなくなります。毎回読ませる分を半分にするため、残す・移す・捨てるの3つに分けた基準と、見出しごとの大きさを測る小さなスクリプトをまとめます。
生成物1ファイルが手書きコード70本より重いので、Claude Code に読ませる範囲を決め直しました
運用中のリポジトリを対象に、どの領域が文脈をどれだけ食うかを数え直しました。生成物の除外・探索パターンの選び方・settings.json での固定まで、実際に決めた運用ルールとその根拠をまとめます。
Claude Code のネイティブ1Mコンテキストを、いつ使い、いつ使わないか — コストで決める判断ルール
Sonnet 5 が既定になり、Claude Code はネイティブで1Mトークンのコンテキストを扱えるようになりました。大きな窓は便利ですが、広げるほど費用は増えます。全部を窓に入れるべきか、分割して読ませるべきか。実測できる token 見積もりと、状況ごとに答えを出す判断ルールを、動くコードとつまずきどころ付きでまとめます。
何度直しても同じ間違いをするClaudeへの対処法 — 「指摘しても治らない」の正体と根本解決策
何度指摘してもClaudeが同じ間違いを繰り返すのは、会話の流れの中で修正指示が薄れていくためです。一時的な修正と永続的な修正の違いを整理し、即効性のある対処法3つと、Claude Projectsやプロフィール設定を使って根本的に直す方法を具体例とともに紹介します。
Claude の長い会話が重くなる前に — トークン消費を抑える4つの実践テクニック
Claude Pro で長時間の作業中にふと気づくと残り時間が少ない — そんな経験はないでしょうか。会話が膨らむ前に手を打つ4つの実践テクニックを、実際の開発現場で使っている手順に沿って紹介します。