repomix

Codex 互換性に関する注意：

• Codex では、リポジトリのスキルを $skill-name で呼び出します。このミラー版では、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーに関する必須事項：ワークフローまたはスキルの手順を実行する前に、すべての手順のタスク追跡を作成または更新し、進捗に応じて同期を保ってください。
• ユーザーへの質問を促す指示がある場合は、Codex でユーザーに直接質問してください。
• Claude 固有のモード切り替え指示があっても無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合は、そのスキルのプロトコルに記載されているとおりに実行してください。
• サブエージェントの使用許可：スキルがユーザーによって呼び出された場合、または AI によって検出された場合に、そのプロトコルでサブエージェントが必要とされていれば、そのスキルの有効化によって、そのタスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが逸脱を事前に明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
• ワークフロー型のスキルでは、記載されている各子スキルの手順を明示的に実行し、各手順の証拠を順を追って報告してください。
• 必須の手順またはツールをこの環境で実行できない場合は、適応策を講じる前に停止し、ユーザーに確認してください。

Codex でのプロジェクト参照資料の読み込み（フックなし）

Codex では、Claude のフックによるドキュメント挿入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テストの設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体へのルート）
• docs/project-reference/lessons.md（常時適用するガードレールとアンチパターン）

状況に応じて読むドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画、または TC のマッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：変更したファイルに応じて、code-review-rules.md と上記のドメイン関連ドキュメント

ドキュメントを無差別にすべて読まないでください。まず docs-index-reference.md を確認し、タスクに関連するファイルだけを開いてください。

概要

目標： Repomix を使用して、コードリポジトリを LLM 分析に適した単一のファイルにまとめます。

ワークフロー：

1. 評価 — 対象リポジトリ（ローカル／リモート）、出力形式、機密情報に関する懸念事項を特定します
2. 設定 — 対象に含める／除外するパターン、コメントの削除、出力スタイルを設定します
3. 実行 — オプションを指定して repomix を実行し、トークン数を確認します
4. 検証 — 出力に機密データが含まれていないか確認し、対象 LLM のトークン上限を確認します

重要なルール：

• 共有する前に必ず出力を確認してください（API キーや認証情報のセキュリティチェック）。
• LLM のコンテキスト上限を超えないよう、--include パターンを使用してください。
• デフォルトの出力形式は XML です。読みやすい出力には --style markdown を使用してください。
• パッケージ化の前にトークン数の多いファイルを特定するには、--token-count-tree を使用してください。

批判的思考とシーケンシャルシンキングを適用し、すべての主張に追跡可能な証拠と信頼度を示してください（アイデアは 80% を超える必要があります）。

Repomix スキル

Repomix は、リポジトリ全体を AI が扱いやすい単一のファイルにまとめます。Claude、ChatGPT、Gemini などの LLM にコードベースを渡すのに最適です。

使用するタイミング

次のような場合に使用します。

• AI 分析用にコードベースをパッケージ化する
• LLM コンテキスト用のリポジトリスナップショットを作成する
• サードパーティーのライブラリを分析する
• セキュリティ監査に備える
• ドキュメント用のコンテキストを生成する
• 大規模なコードベース全体にわたるバグを調査する
• AI が扱いやすいコード表現を作成する

クイックスタート

インストールの確認

repomix --version

インストール

# npm
npm install -g repomix

# Homebrew (macOS/Linux)
brew install repomix

基本的な使い方

# Package current directory (generates repomix-output.xml)
repomix

# Specify output format
repomix --style markdown
repomix --style json

# Package remote repository
npx repomix --remote owner/repo

# Custom output with filters
repomix --include "src/**/*.ts" --remove-comments -o output.md

主な機能

リポジトリのパッケージ化

• 明確な区切りによる、AI に最適化されたフォーマット
• 複数の出力形式：XML、Markdown、JSON、プレーンテキスト
• Git 対応の処理（.gitignore を尊重）
• LLM のコンテキスト管理のためのトークン数カウント
• 機密情報のセキュリティチェック

リモートリポジトリのサポート

クローンせずにリモートリポジトリを処理します：

# Shorthand
npx repomix --remote yamadashy/repomix

# Full URL
npx repomix --remote https://github.com/owner/repo

# Specific commit
npx repomix --remote https://github.com/owner/repo/commit/hash

コメントの削除

サポートされている言語（HTML、CSS、JavaScript、TypeScript、Vue、Svelte、Python、PHP、Ruby、C、C#、Java、Go、Rust、Swift、Kotlin、Dart、Shell、YAML）のコメントを削除します：

repomix --remove-comments

一般的なユースケース

コードレビューの準備

# Package feature branch for AI review
repomix --include "src/**/*.ts" --remove-comments -o review.md --style markdown

セキュリティ監査

# Package third-party library
npx repomix --remote vendor/library --style xml -o audit.xml

ドキュメントの生成

# Package with docs and code
repomix --include "src/**,docs/**,*.md" --style markdown -o context.md

バグの調査

# Package specific modules
repomix --include "src/auth/**,src/api/**" -o debug-context.xml

実装計画

# Full codebase context
repomix --remove-comments --copy

コマンドラインリファレンス

ファイルの選択

# Include specific patterns
repomix --include "src/**/*.ts,*.md"

# Ignore additional patterns
repomix -i "tests/**,*.test.js"

# Disable .gitignore rules
repomix --no-gitignore

出力オプション

# Output format
repomix --style markdown  # or xml, json, plain

# Output file path
repomix -o output.md

# Remove comments
repomix --remove-comments

# Copy to clipboard
repomix --copy

設定

# Use custom config file
repomix -c custom-config.json

# Initialize new config
repomix --init  # creates repomix.config.json

トークン管理

Repomix は、個々のファイル、リポジトリ全体、形式ごとの出力のトークン数を自動的にカウントします。

一般的な LLM のコンテキスト制限：

• Claude Sonnet 4.5：約200Kトークン
• GPT-4：約128Kトークン
• GPT-3.5：約16Kトークン

トークン数の最適化

コードベースのトークン分布を把握することは、AI とのやり取りを最適化するうえで重要です。--token-count-tree オプションを使うと、プロジェクト全体のトークン使用量を可視化できます：

repomix --token-count-tree

コードベースの階層表示とともに、トークン数が表示されます：

🔢 Token Count Tree:
────────────────────
└── src/ (70,925 tokens)
    ├── cli/ (12,714 tokens)
    │   ├── actions/ (7,546 tokens)
    │   └── reporters/ (990 tokens)
    └── core/ (41,600 tokens)
        ├── file/ (10,098 tokens)
        └── output/ (5,808 tokens)

また、最小トークン数のしきい値を設定して、サイズの大きいファイルに絞り込むこともできます：

repomix --token-count-tree 1000  # Only show files/directories with 1000+ tokens

これにより、次のことができます：

• AI のコンテキスト制限を超える可能性のある、トークン数の多いファイルを特定する
• --include と --ignore パターンを使ってファイルの選択を最適化する
• トークン数への影響が大きいファイルを対象に、圧縮方法を計画する
• AI による分析用にコードを準備する際、コンテンツとコンテキストのバランスを取る

セキュリティに関する考慮事項

Repomix は Secretlint を使用して、機密データ（API キー、パスワード、認証情報、秘密鍵、AWS のシークレット）を検出します。

ベストプラクティス：

1. 共有する前に、必ず出力を確認する
2. 機密ファイルには .repomixignore を使用する
3. 内容が不明なコードベースでは、セキュリティチェックを有効にする
4. .env ファイルをパッケージ化対象から除外する
5. ハードコードされた認証情報がないか確認する

必要に応じて、セキュリティチェックを無効にします：

repomix --no-security-check

実装ワークフロー

ユーザーからリポジトリのパッケージ化を依頼された場合：

1. 要件を確認する

   • 対象のリポジトリを特定する（ローカル／リモート）
   • 必要な出力形式を確認する
   • 機密データに関する懸念がないか確認する

2. フィルターを設定する

   • 関連ファイルの include パターンを設定する
   • 不要なファイルの ignore パターンを追加する
   • コメント削除を有効または無効にする

3. パッケージ化を実行する

   • 適切なオプションを指定して repomix を実行する
   • トークン数を確認する
   • セキュリティチェックの結果を検証する

4. 出力を検証する

   • 生成されたファイルを確認する
   • 機密データが含まれていないことを確認する
   • 対象の LLM のトークン制限を確認する

5. コンテキストを提供する

   • パッケージ化されたファイルをユーザーに提供する
   • トークン数の概要を添える
   • 警告や問題があれば伝える

リファレンスドキュメント

詳細については、以下を参照してください：

• 設定リファレンス - 設定ファイル、include／exclude パターン、出力形式、高度なオプション
• 使用パターン - AI 分析のワークフロー、セキュリティ監査の準備、ドキュメントの生成、ライブラリの評価

追加リソース

• GitHub: https://github.com/yamadashy/repomix
• ドキュメント: https://repomix.com/guide/
• MCP サーバー: AI アシスタントとの統合に利用できます

---

[IMPORTANT] 作業を始める前に、タスク追跡を使って、ファイルの読み込みごとのタスクも含め、すべての作業を小さなタスクに分割してください。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合、AI は必ず、スキップするかどうかをユーザーに尋ねてください。

AI のミスを防ぐ — すべてのタスクで避けるべき失敗パターン： 削除する前に、下流の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードが古くなる連鎖的な影響が生じます。削除する前に、参照しているすべてのファイルを特定してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係を最後まで追跡してください。 定義を変更しても、そこから派生する下流の変数や利用箇所を見落とすことがあります。必ず依存関係を最後まで追跡してください。 正しさを検証するときは、すべてのコードパスを追跡してください。 コードが存在することを確認しても、それが実行されることを確認したことにはなりません。通常の成功パスだけでなく、早期リターン、エラー分岐、条件によるスキップも必ず追跡してください。 デバッグ時は、修正する前に「どの層の責任か」を確認してください。 バグが呼び出し元（誤ったデータ）にあるのか、呼び出し先（誤った処理）にあるのかを追跡してください。責任のある層で修正し、症状が現れる箇所だけを修正しないでください。 既存の値は意図的に設定されていると考え、変更する前に理由を確認してください。 定数、上限値、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 複数のスタックに影響する変更では、すべての出力を検証する必要があります。1つのチェックが成功しても、すべてのチェックが成功したことにはなりません。 全体像を先に見るデバッグ — 目についた箇所だけにとらわれないでください。 失敗を調査するときは、まずすべての前提条件（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）を列挙し、コード層に原因があると考える前に、それぞれを根拠に照らして検証してください。 変更は必要最小限に — 差分テストを適用してください。 バグ修正では、変更するすべての行がバグに直接関係している必要があります。隣接するコードの書式変更や改善はしないでください。機能強化のタスクでは、改善を実装し、その内容を明確に伝えてください。 実装前に曖昧さを明らかにし、黙って判断しないでください。 依頼に複数の解釈がある場合は、それぞれの工数見積もりを提示して質問してください。全レコード対象、ファイルベース、またはより複雑な方法を決めつけないでください。

批判的思考の姿勢 — 批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な証拠が必要です。確信度が 80% を超えてから実行してください。 幻覚の防止： 推測を事実として提示しないでください。すべての主張に出典を示し、不確かさを率直に認め、出力に誤りがないか自ら確認し、独立した情報源と照合し、自分の確信にも懐疑的でいてください。証拠のない確信こそ、あらゆる幻覚の根本原因です。

必ず注意して批判的思考を適用してください。すべての主張には追跡可能な証拠が必要です。実行するのは確信度が 80% を超えてからにしてください。幻覚を防ぐため、推測を事実として提示しないでください。

必ず注意してAI のミス防止策を適用してください。全体像を先に見るデバッグ、責任のある層での修正、実装前の曖昧さの明示、コンテキスト圧縮後のファイルの再読を徹底してください。

最後の確認事項

重要：必ず注意して 作業を始める前に、タスク追跡を使って、作業を小さな todo タスクに分割してください 重要：必ず注意して 新しいコードを作成する前に、コードベースで類似するパターンを 3 つ以上検索してください 重要：必ず注意して すべての主張について file:line の根拠を示してください（実行するのは確信度が 80% を超えてから） 重要：必ず注意して 作業の品質を検証するための最終レビュー用 todo タスクを追加してください

[TASK-PLANNING] 実行する前に、タスクの範囲を分析し、タスク追跡を使って作業を小さな todo タスクとサブタスクに体系的に分割してください。

Hookless Prompt Protocol Mirror（自動同期）

ソース: .claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・厳守。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクト参照ドキュメントを開いてください。この共通コンテキストとローカルドキュメントを利用できる場合は、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップ構成のほうが適しているかどうかも評価します
3. 確認（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、かつローカルプロトコルで明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します
   • 質問："どのワークフローを有効にしますか？"
   • 選択肢 1："[最適なワークフロー] を有効にする（推奨）"
   • 選択肢 2："カスタムワークフローを有効にする：[step1 → step2 → ...]"（1 行で理由を記載）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順に実行します
5. タスクを作成： ワークフローのすべてのステップについてタスク追跡を行います
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動します。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意力に関する原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、指示の順守が長いコンテキストウィンドウでも保たれるよう、最も重要な 3 つのルールを冒頭と末尾の両方に配置します。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストで意図を検証： テストでは、現在の挙動をなぞるだけでなく、ビジネスルール／不変条件を保護し、保護対象の意図が損なわれた場合に失敗するようにします。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割し、タスク追跡を行います。最後のタスクとして「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論／前提の誤り）を特定します。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を検証します。この失敗モードは 3 つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を 1 段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを除き、どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
5. 再発判定：「この注意書きがなければ、今後のセッションで再発するか？」いいえの場合は $learn を省略します。
6. 自動修正判定：「$code-review／$code-simplifier／$security／$lint で検出できるか？」はいの場合は、代わりにレビュー用スキルを改善します。
7. 両方の判定を通過した場合： $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成／更新し、各ステップの開始時と完了時に内容を同期してください。