aelena/llms-txt

llms-txt は何をしますか？

リポジトリのルートに高品質な llms.txt ファイルを作成します。llmstxt.org で提案されている標準に従い、プロジェクトの厳選された機械可読なインデックス、すなわち「LLM用目次」を生成します。このファイルはモデルのコンテキストウィンドウに収まるよう設計されています。

存在理由

LLMがリポジトリを盲目的に読む場合、何が重要かを推測する必要があります。llms.txt はプロジェクト側から 明示的に伝える ことを可能にします。すなわち、プロジェクトの概要、要約、優先順位順の公式ドキュメント、コンテキストが不足している場合にスキップしてよい二次リソースを提供します。これはモデル時代の robots.txt であり、モデルの作業を妨げるのではなく、より良く行えるように支援します。

呼び出し方法

トリガー	動作
/llms-txt または /llms-txt-gen	リポジトリルートに llms.txt を生成
/llms-txt full	さらに llms-full.txt（全ドキュメントを連結、切り詰めなし）も生成
/llms-txt validate	既存の llms.txt を仕様に対して検証
/llms-txt update	現在のリポジトリ状態で既存の llms.txt を更新、手動編集を保持
自然言語: "llms.txt を作成して"、"このリポジトリを LLM フレンドリーに"、"llm インデックスを生成" など	同上

停止 / 無効化

該当しません — これはセッションモードではなく、1回限りの生成ツールです。単に呼び出さないでください。

実行フロー

1. 候補を発見。 scripts/discover.sh を実行して以下を列挙します:

   • プロジェクトメタデータファイル: README*、package.json、pyproject.toml、Cargo.toml、Gemfile、go.mod など
   • ルートレベルのマークダウン: README.md、CHANGELOG.md、CONTRIBUTING.md、LICENSE、ARCHITECTURE.md など
   • docs/ ディレクトリの内容（.md、.mdx、.rst）
   • 深さ2〜3のその他のマークダウン（node_modules、.git、vendor を除く）

2. 読み取りと統合。 README と主要なメタデータファイルを読み取り、以下を抽出:

   • プロジェクト名（package.json:name、pyproject.toml:[project].name、または README の H1 から）
   • 1文の要約（README の最初の段落または package.json:description から）
   • より長いコンテキスト（README 導入部から1〜2段落、見出しなし）

3. 候補を H2 セクションに分類。 妥当なデフォルト:

   • Docs — 主要なユーザー向けドキュメント
   • Examples — サンプルコード、チュートリアル、クイックスタート
   • API Reference — 生成または手書きの API ドキュメント
   • Optional — 二次リソース（CHANGELOG、貢献ガイド、RFC、内部メモ）

   ## Optional セクションは仕様上特別な意味を持ちます。コンテキスト予算が限られている LLM はこれをスキップすべきです。重要でないものはすべてここに配置します。

4. llms.txt を生成。 format.md の形式に従います。厳格な構造:

   # プロジェクト名
   
   > ブロッククォート内の1文の要約。
   
   任意の1〜2段落のコンテキスト（見出しなし）。
   
   ## セクション
   - [タイトル](相対または絶対URL): 1行の説明
   - [タイトル](URL): 説明
   
   ## Optional
   - [タイトル](URL): 説明
   

5. 検証。 scripts/validate.sh で検証。エラーがあれば修正して再検証。

6. プレビュー。 書き込む前に生成されたファイルをユーザーにプレビュー表示。確認を求める。

7. 書き込み。 ./llms.txt に書き込み。ファイルが既に存在する場合は 差分を表示 し、上書き前に確認 — ユーザーが追加した手動セクションは保持。

8. オプションの llms-full.txt（full 引数が指定された場合のみ）: リンクされたすべてのドキュメントの全文を1つのファイルに連結し、各ドキュメント間に # File: <パス> ヘッダーを挿入。これは「全てをよこせ」バリアントです。

安全ガードレール

• プレビューと確認なしに既存の llms.txt を決して上書きしない。 手動で整理された内容が含まれている可能性があります。
• 生成ファイルにシークレットを含めない。 .env*、*.pem、*key*、credentials*、*.secret に一致する候補ファイルはすべてスキップ。見つかった場合はユーザーに警告。
• プライベートパスへのリンクを決して作成しない（.git/、node_modules/、vendor/、target/、build/、dist/ 内部のもの）。
• URL をでっち上げない。 すべてのリンクはリポジトリ内の実在するファイル（相対パス）か、README に明示的に存在する URL を指している必要があります。プロジェクトのホームページを推測しないでください。
• .gitignore を尊重する。 候補ファイルが gitignore されている場合は、インデックスに含めない。

生成ファイルのスタイルルール

• H1 はプロジェクト名のみ。 それ以外は何もなし。スローガンやタグラインは不可。
• ブロッククォートの要約は1文。 現在形で、事実に基づく。マーケティング用語は不可。
• リンク項目の説明は1行、最大約12語。 LLM にこのファイルが なぜ 重要かを伝える。内容を逐語的に伝えるのではない。
• セクション内の順序は重要 — 最も重要なものを最初に。モデルは途中で読むのをやめる可能性がある。
• 絵文字なし、装飾的なマークダウンなし、ネストされたリストなし。形式は意図的にフラットに。
• リポジトリ内のファイルには相対パスを優先（docs/getting-started.md）、絶対 URL は外部リソースのみに使用。

このスキルに含まれるファイル

• SKILL.md — このファイル
• format.md — llmstxt.org のフォーマットリファレンス（要約版）
• scripts/discover.sh — インデックス対象の候補ファイルを列挙
• scripts/validate.sh — 生成された llms.txt を仕様の基本に照らしてチェック