implicit-token-savings

implicit-token-savings

実際の質問に答えるために十分な範囲で、最も短いローカルシェルコマンドを選びます。

質問に答えられる場合は、特に簡潔な出力が求められているとき、コンパクトな出力を優先します。タスクに必要なら、既知のファイル、関連する差分、または全出力を直接確認します。事前の要約は必須ではありません。

判断ツリー

今、何が必要ですか？

• リポジトリの構成、トップレベルのファイル、または候補となるパス

  • ls -1、tree -L 2、または rg --files から始めます
  • references/filesystem.md を読みます

• 特定のシンボル、文字列、スタックトレース、または TODO

  • rg -n から始めます
  • references/filesystem.md を読みます

• ファイルの抜粋または行の範囲

  • ハーネスに対象を絞った読み取りツールがあれば、そちらを優先します
  • ない場合は、sed -n 'start,endp' file、head -n 80、または tail -n 80 を使います
  • references/filesystem.md を読みます

• ワーキングツリーの状態、変更範囲、または最近の履歴

  • git status --short、git diff --stat、git diff --name-only、または git log --oneline から始めます
  • references/git.md を読みます

• ステージング、コミット、またはプッシュ

  • 意図したパスのみをステージングします
  • 許可されたコミットを行う前に、ステージングされた変更をすべて確認します。範囲の確認には要約を、意味の確認には差分の詳細を使います
  • プッシュが許可されており、意図したリモートと宛先が分かっている場合に限り、HEAD を使います
  • references/git.md を読みます

• 特定のスタックに対するテスト、リント、またはコンテナーの状態確認

  • 存在する最も範囲の狭いスタック標準のコマンドから始めます：cargo test、npm test、ruff check、pytest、go test、または docker ps
  • references/runners.md を読みます

• 推奨コマンドが使えない場合

  • フォールバック表に従います
  • references/patterns.md を読みます

デフォルトの運用ルール

1. 既知のコンテキストを使って、必要十分なコマンドを直接選びます。パスが不明な場合は一覧表示が役立ちますが、対象ファイルがすでに分かっている場合は不要です。
2. 範囲を明確にします。範囲に関する質問には --files、--name-only、または --stat を使い、意味に関する質問には内容を出力します。
3. 不明なファイルや該当する行の特定には rg を使います。関連するファイルが分かっている場合は、検索の手順を挟まずに読みます。
4. 動作を確認するときは、パスを指定した git diff を直接使います。要約は規模やファイル一覧の確認には役立ちますが、意味の確認には使えません。
5. ローカルでのフィードバックには対象を絞ったテストを使い、引き継ぎ前にはリポジトリで必須の検証ゲートをすべて実行します。範囲を絞ったテストで必須の全テストを置き換えることはできません。
6. 別のツールやスクリプトで処理する場合は、機械可読な出力を優先します：--json、--format '{{json .}}、jq -r。
7. 既知の必要性に合わせて、簡潔な出力、構造化された出力、または全出力を選びます。エラー、終了ステータス、失敗の詳細を保持し、安全な判断に必要な証拠を決して省略しないでください。
8. 推奨ツールが使えない場合は、そこで停止せず、最も近い低コストの代替手段を使います。

クイックリファレンス

質問に該当する行を選択してください。代替手段を順番に試す必要はありません。

必要なこと	簡潔な方法	役立つ代替手段	理由
リポジトリの最上位の一覧	ls -1	ls -lah または tree -L 2	全体を把握したいだけなら、装飾的な出力よりファイル名のほうが役立ちます
ディレクトリ構成	tree -L 2 path/	tree -a -L 3 path/	深さを制限すると構成を読みやすく保てます
候補パスのみ	rg --files path/	rg --files path/ | rg 'pattern'	ファイルの内容を一切開かずに済みます
テキストまたはシンボルの検索	rg -n -F 'needle' path/	rg -n 'regex' path/	リテラル検索かパターン検索かを選べます
ファイルの一部	sed -n '1,80p' file	ファイル全体のコンテキストが必要な場合は全体を読む	1 回の有用な読み取りで、十分なコンテキストを得られます
作業ツリーの状態	git status --short --branch	git status	ほとんどの判断には短縮形式で十分です
変更の範囲や意味	git diff --stat	パスには git diff --name-only、意味の確認には git diff -- path	質問に必要な詳細度を選びます
最近の履歴	git log --oneline --decorate -n 15	git log --stat -- path	コミットの見出しだけで、多くの質問にすばやく答えられます
ステージングとレビュー	git add -- path && git diff --cached --stat	git diff --cached -- path	コミットする予定の内容だけをレビューします
現在のブランチを許可を得てプッシュ	git push -u origin HEAD	宛先が不明な場合は確認する	HEAD は省略形であり、プッシュの許可を意味するものではありません
Node のテスト対象	npm test -- <runner-args>	フラグが不明な場合は npm test -- --help	プロジェクトで把握しているランナーの仕様を使います
Rust のテスト対象	cargo test name -- --nocapture	cargo test package::module::name	絞り込んだフィードバックが得られるテストフィルターを選びます
Python のリンティング対象	ruff check path/	ruff check path/ --fix	修正は明示的に行います
Python のテスト対象	pytest -q tests/test_file.py -k expr	pytest -q tests/	必要に応じて、絞り込んだフィードバックかスイート全体のカバレッジを選びます
Go のテスト対象	go test ./pkg/... -run Pattern	go test ./...	パッケージと -run のフィルターで出力を減らせます
コンテナーの一覧	docker ps --format '{{json .}}'	docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'	構造化された行は、フィルタリングや要約が容易です

読み方ガイド

タスク	読むファイル
リポジトリ構成、検索、対象を絞ったファイルの読み取り	references/filesystem.md
簡潔な Git の状態、差分、履歴、ステージング、プッシュのパターン	references/git.md
絞り込んだテスト、リンティング、コンテナーのコマンド	references/runners.md
コンテキストに応じたコマンドの選択と代替手段	references/patterns.md
結果が見つからない場合、圧縮しすぎによる誤り、コマンドの落とし穴	references/gotchas.md

注意点

1. rg は ignore ルールに従います。結果が見つからない場合は、通常、ツールを切り替えるのではなく --hidden、-u、または --debug が必要です。
2. tree は構成を確認するためのもので、正確性を確かめるものではありません。早めに深さを制限しないと、ディレクトリの見た目にトークンを費やすことになります。
3. 一部だけ必要な場合は sed -n のほうが cat より効率的ですが、必要な短いファイルが正確にわかった後では、何度も一部を読むほうが全体を 1 回読むより高コストになることがあります。
4. git diff --stat では変更の意味がわかりません。動作について結論を出す前に、パスを指定した差分で詳細を確認してください。
5. npm test が追加のランナーフラグを渡すのは -- の後だけです。
6. docker ps が成功しても、確認したいコンテナーが正常とは限りません。コンテナーの有無だけでなく Status を確認してください。
7. 1 つのファイルだけが重要な場合、git add . はトークンを節約する方針に反します。パスを明示してステージングしてください。

ヘルパースクリプト

• scripts/probe_implicit_token_savings.py は利用可能なツールを検出し、一時的なローカルフィクスチャで簡潔なコマンドの動作を検証します。
• scripts/validate.py はパッケージング、必須ファイル、構文をチェックします。
• scripts/test_skill.py は検証、評価カバレッジのチェック、相互参照のチェック、プローブスイートを実行します。
• templates/session-checklist.md は、ノイズを抑えたコーディングセッションを開始するときに使える再利用可能なチェックリストです。

ガイダンスが役に立たなくなったとき

簡潔なコマンドが失敗したり、必要な証拠が隠れたりする場合は、より詳細な出力を使い、インストール済みのヘルプまたは公式のバージョン対応ドキュメントを確認してください。失敗や不明点を、最適化のために取り除かずに残してください。例が古くなっている場合や、削減できる作業より追加される作業のほうが多い場合は、ツールとバージョンを明記し、再現手順を添えて、標準スキルの更新を提案してください。インストール済みのコピーを黙って編集したり、提案を公開したりしないでください。