agents-md-generator

AGENTS.md 生成機能

このスキルを使うと、エージェントがコードベースで作業する際のコントリビューターガイドとなる AGENTS.md ファイルを生成できます。

主な機能

• 機能：リポジトリの境界を分析し、標準化された AGENTS.md ドキュメントを生成または更新します
• 出力形式：セクションを構成した Markdown ファイル
• 執筆目標：ISO 24495-1:2023 の平易な言葉の原則に基づく、読者を中心としたガイダンスです。コントリビューターが該当するガイダンスを見つけ、確認済みの契約を理解し、次の変更に活用できるようにします
• 文字数制限：リポジトリの LOC（コード行数）に応じて変動します
• モノレポのサポート：モノレポの構造を自動検出し、階層型ドキュメント（ルート + パッケージ）を生成します
• 更新のサポート：管理対象であることを示すマーカー付きの AGENTS.md では、標準セクションのみを更新し、ユーザーが定義したカスタムセクションを保持します。マーカーのないファイルでは、具体的な変更プレビューと初回の採用確認が必要です。一致する標準見出しがないファイルを更新するには、明示的な全体再生成の依頼が必要です

出力セクション

単一リポジトリ／パッケージのドキュメント（4～5 セクション）

単一リポジトリ、またはモノレポ内の個別パッケージ向けです。

• 概要：プロジェクトを説明する 1～2 文（抽象的な説明とし、ツールやフレームワークの一覧は含めません）
• 所有関係マップ：任意。根拠に基づくマップを、安定した所有境界と活発な変更経路に分けます。対象は、エントリーポイント、状態の所有者、動作の判断箇所、外部インターフェース、契約／副作用、検証の基点、最近の履歴に基づく経路です。リポジトリに記録する価値のある安定した境界や活発な経路がない場合、このセクションは省略します。テンプレートを埋めるためだけに所有関係を作り上げないでください
• 主要な動作とパターン：エラー伝播の連鎖、状態ライフサイクルの遷移、境界をまたぐ配線の仕組み、レジリエンス／復旧戦略、共有リソースの管理など、複数の箇所に共通するパターンを全体のフローを追って記述します。複数フェーズの分析を通じて発見します。まず表層のイディオムを検出し、次にレイヤーをまたいで詳細に追跡します
• 規約：命名、コードスタイル、API／インターフェースの設計規約（コールバックの命名、戻り値の形式、メソッドの責務分割）、設定／登録の構成、境界の規約（エラーの単純化、スキーマのずれの吸収、封じ込めのルール）、コンポーネントの構成パターンです
• 作業上の合意事項：エージェントの振る舞いとコミュニケーションに関するルールです

モノレポのルートドキュメント（2～3 セクション）

モノレポ構造のルート向けです。

• 概要：モノレポの目的を説明する 1～2 文
• 所有関係マップ：任意。安定したパッケージレベルの責任境界と、活発なパッケージ横断の変更経路に分けたマップです。モノレポのルートでは、パッケージ名に加えて、マニフェスト、公開エクスポート、README の記述、依存関係の方向、最近確認された変更のまとまりから、十分な根拠を得られる場合があります。ルートに情報量の少ないパッケージ一覧しかない場合は、このセクションを省略します
• 作業上の合意事項：すべてのパッケージに適用される共通の作業上の合意事項です

動作モード

生成と更新

• 生成：新しい AGENTS.md を一から作成します（AGENTS.md が存在しない場合のデフォルト）
• 更新：既存の管理対象 AGENTS.md の標準セクションを更新し、カスタムセクションは保持します。有効な管理マーカーがある場合、このワークフローの対象であることが確認できます。一致する見出しは置換候補を特定するものであり、作成者を示すものではありません。マーカーのないファイルでは、具体的なプレビューを確認した後、初回の採用確認が必要です。一致する見出しがない場合は、明示的な全体再生成の依頼が必要です。マーカーの仕様と採用ワークフローについては、./references/update_strategy.md を参照してください。

エージェントは、対象の場所に AGENTS.md ファイルがすでに存在するかどうかに応じて、適切なモードを自動的に選択します。

生成モード（モノレポ）

3 つのモードをサポートしています。All（ルート + すべてのパッケージ、デフォルト）、Root Only、Single Package です。詳しい戦略とモード選択基準については、./references/monorepo_strategy.md を参照してください。

実行ワークフロー

以下の手順を順番に実行してください。各手順には次の手順が依存する固定の出力があります。先に進むと、文字数の予算を誤ったり、更新対象のセクションが一致しなかったり、モノレポ内のパッケージを見落としたりします。./scripts/ に含まれるスクリプトを使うと、決定論的な手順を再現できます。実行のたびにロジックを再導出せず、スクリプトを呼び出してください。

Step 1 — モードを決める

1. 対象の場所に AGENTS.md が存在するか確認します。存在する場合は 更新候補 です（後述の管理状況の確認が必要です）。存在しない場合は 生成 です。

2. リポジトリのルートでモノレポを検出します。

   python ./scripts/detect_monorepo.py <repo_root>
   

   出力：{is_monorepo, markers}。結果が true の場合は暫定的な判定です。./references/monorepo_detection.md に従って、実際のパッケージを特定してください。見つかったパッケージが 2 つ未満の場合は、マーカーの有無にかかわらず、リポジトリを単一ドキュメントとして扱います。それ以外の場合は、./references/monorepo_strategy.md に従って All / Root Only / Single Package を選択します。is_monorepo が false の場合は、リポジトリを単一ドキュメントとして扱います。

3. LOC の測定や詳細な分析の前に、既存の各対象について python ./scripts/parse_sections.py <path/to/AGENTS.md> --doc-type <single_repo|monorepo_root> を実行します。management_status は managed、unmarked、または invalid です。generated_doc_type には、有効なマーカーに記録された元のドキュメントタイプ、または null が入ります。マーカーが無効な場合、自動更新を停止します。見出し数の判定を適用する前に、次の項目で元のタイプを確認します。標準の見出しが一致する未マークのファイルは、採用プレビューの準備に進めますが、書き込みはできません。元のタイプで一致する見出しが 0 件の場合は、全体を再生成する明示的な依頼が必要です。見出しが一致するだけでは、書き込みは許可されません。

4. 有効な generated_doc_type と現在の対象タイプを比較します。異なる場合は、元のタイプを指定してパーサーを再実行し、全体を再生成する前に、元の管理対象セクションとカスタムセクションを特定します。未マークのファイルの場合は、特徴的な標準見出し（## 3. Working Agreements と ## 3. Core Behaviors & Patterns / ## 5. Working Agreements）から元のタイプを推定します。これらの見出しが矛盾する場合や、判断に不十分な場合は、どの元のタイプを使うか確認してください。元のカスタムセクションを保持し、上書きする前に、具体的なタイプ変更プレビューの承認を得てください。

5. パッケージのドキュメントの場合は、リポジトリルートの AGENTS.md が存在するか確認します。存在する場合は、実際の相対パスを参照してください。存在しない場合は、共通の作業上の取り決めと、見つかったパッケージローカルの検証コマンドをパッケージのドキュメントに直接記載します。Single Package の依頼ではルートファイルを作成しないでください。All モードでは、ルートの処理後にもう一度確認してください。

Step 2 — LOC を測定して予算を割り当てる

各対象ドキュメント（単一リポジトリ、またはルート + 各パッケージ）について、以下を実行します。

python ./scripts/loc_to_limit.py <target_directory>

出力：{loc, scale, character_limit}。スクリプトが tokei が見つからないと報告した場合は、そのインストール方法のメッセージを提示して停止してください。LOC を手作業で推定してはいけません。./references/loc_measurement.md の比率をセクションごとの初期割り当てとして使い、確認済みの内容に応じて容量を再配分します。厳格な文字数制限が適用されるのは、前文と管理対象セクションを合わせた文字数のみです。セクションごとの比率は、それぞれ独立した上限ではありません。

Step 3 — スタックのコンテキストを構築する

パターンや規約を分析する前に、./references/read_only_commands.md > Dependency Discovery に従い、ドキュメントの対象範囲（ルートまたは各パッケージ）にあるパッケージマニフェストを読みます。ロックファイルは対象外です。このスタックのコンテキストを使って、関連するフレームワークに絞り、Step 4 でやみくもに検索しないようにします。

Step 4 — リポジトリを分析する

分析の前に./references/content_quality.mdを読んでください。判断に関係する事実、その時点での根拠資料、および記載先を、簡潔な内部記録にまとめてください。Generate モードでは、これらの事実をソースから見つけてください。Update モードでは、ソースから事実を見つけるだけでなく、古い分析由来の管理対象セクションから重要な事実を確認の手掛かりとして抽出し、現在のソースで再確認したうえで、古い文書に欠けていた内容も見つけてください。古い文書は現在の動作を示す根拠ではありません。また、作業用の記録は新たな出力セクションではありません。

重要な動作を選んだら、該当する選択肢、ガード／バイパス経路、回復時の結果、状態の存続期間、所有権／クリーンアップの条件、実際の受け手を確認できるまで、直接実装しているヘルパーを調査してください。ドラフトの作成前に、この簡潔な関係記録を対象リポジトリの外にある一時的なスクラッチファイルに保存してください。機能名やヘルパー名だけでは、ソースの追跡を終えたことにはなりません。最近の履歴は、アクティブな経路の分類に影響しますが、現在確認済みの安全性に関する契約を記録に残すかどうかには影響しません。

履歴に基づいて優先順位を決める前に、文書化された機能と、信頼できる登録情報／公開サーフェスからカバレッジ表を作成してください。Update モードでは、古い管理対象の Stable 境界、Active 経路、コアフローもすべて確認してください。各行について、現在の所有者／利用者と、選定するか、根拠に基づいて対象外とするかを確認してください。選定した行は、実際に実装しているファイルとシンボルを使ってopenからclosedまで追跡し、パイプラインの動作を変える各段階も含めてください。変更がない履歴期間を根拠に、稼働中のフック、マイグレーション、安全性に関する条件を除外してはいけません。

Update モードでは、ソースを詳しく追跡する前に、所有権の調査手掛かりとして git の履歴を使用してください。

1. 対象文書のAGENTS.mdをスキルが最後に更新した時点以降の変更を優先してください。信頼できる更新時点がわからない場合は、リポジトリの活動状況に応じて調整しつつ、直近およそ3か月を既定としてください。

2. git 履歴を手動で広げて調査する前に、同梱の高変更頻度シグナル用ヘルパーを実行してください。

   python ./scripts/git_ownership_signals.py <target_directory>
   

   信頼できる更新時点がある場合は、--anchor <commit-ish>を指定してください。このスクリプトは、コンテキストの消費を抑えるため、簡潔な Markdown-KV を出力します。

3. まずコミットのメタデータと変更されたパスだけを確認してください。既定では、差分全体を読まないでください。

4. 変更パスのまとまり、繰り返し同時に変更されるパターン、名前変更／移動、削除されたパス、変更頻度の高い境界ファイルを確認してください。

5. 履歴は次に調査する場所を決めるために使い、何を文書化するかを決めるためには使わないでください。現在のコードまたは文書化された契約によって確認できる場合に限り、Ownership Mapの境界を追加してください。

6. AGENTS.mdに「以前の注力点」や「現在の注力点」といった時系列の要約を記載しないでください。移行または互換性の境界として現在のコードに表れている場合を除き、そのような内容はユーザー向けの要約でのみ報告してください。

トークンを節約できる git コマンドと展開ルールについては、./references/read_only_commands.md#git-history-signals-update-modeを参照してください。

./references/agents_md_template.mdで定義されている多段階分析を実行してください。

1. Phase 1 — スタックとサーフェスの把握（3つ以上のファイルに見られる繰り返しのイディオム、プロジェクト固有の抽象化）。
2. Phase 2 — レイヤーをまたぐ詳細な追跡（エラーの伝播、配線、状態のライフサイクル、失敗経路、集中化された委譲）。
3. Phase 3 — 検証（レイヤーをまたぐフローを考慮しつつ、3か所以上に存在するパターンを優先します。また、安全な作業を左右する、単一でも検証済みの重要な境界は保持してください）。

Serena MCP が利用できる場合は、rg／grep／findよりも、読み取り専用のシンボルツール（find_symbol、find_referencing_symbols、get_symbols_overviewなど）を優先してください。呼び出し元の追跡やレイヤーをまたぐフローの把握に、シンボル検索のほうが正確です。詳しくは./references/read_only_commands.md#symbol-level-analysis-optional-requires-serena-mcpを参照してください。 この分析は現在のコンテキスト内でのみ実行してください。サブエージェントに委任しないでください — Phase 3 のパターン横断検証とセクション単位の予算追跡には、統一された視点が必要です（Scope Boundaries > Single-Context Execution を参照）。

実際に確認できたパターンや規約のみを記録してください。必要なエントリーポイント、動作を変える代替手段、例外／フォールバック条件、ライフサイクル上の義務、互換性への影響は保持してください。セクションに当初の割り当て以上の容量が必要な場合は、これらの事実を削除するのではなく、総上限の範囲内で未使用の容量を再配分してください。内容品質のリファレンスに記載された圧縮順序を適用してください。

任意の ## 2. Ownership Map に根拠のある内容がない場合は、そのセクションを省略し、後続のセクション番号は変更しないでください。セクション番号は更新モードの識別子です。間を埋めるために、Core Behaviors & Patterns、Conventions、Working Agreements の番号を変更しないでください。根拠がある場合、Ownership Map の内容は、従来の単一リスト形式の Ownership Map に記載されていた永続的な安全境界を扱う Stable Ownership Boundaries と、現在のコードに照らして確認された、直近の履歴に基づくルートを扱う Active Change Routes に分けてください。Active Change Routes は更新モードの補足コンテキストとして追加するものであり、安定した境界の代替やフィルターとして扱わないでください。Stable の箇条書きは変更先を定める完全なルールとし、Active の箇条書きは親に関連付けられた差分ルート、または境界をまたぐ差分ルートとしてください。Active では、親となる Stable 境界の広範な担当範囲、契約、検証を繰り返さないでください。継承された Stable の詳細を取り除いたあとに意味のある差分が残らない場合は、その Active ルートを省略してください。セクションの文字数上限を超えない範囲で、箇条書きの数に上限を設けないでください。

Step 5 — 組み立て（生成）または差し替え（更新）

草稿を作成する前に、./references/plain_language.md を読んでください。プロジェクトのプログラミング言語は知っているものの、ローカルの担当者、用語、契約はまだ知らないコントリビューターを想定して、生成するセクション本文を作成します。Update モードで新たに管理対象となる本文にも同じ執筆ガイダンスを適用し、更新時の契約に従ってカスタムセクションと既存のプリアンブルのバイト列を保持します。これは出力を書き込む工程であり、新たなセクションでも、今後のエージェントの応答に適用される新たな常設ルールでもありません。

確定した、意思決定に関わる契約は、セクション間で重複させず、まず Ownership Map／Core Behaviors に記述します。残りの容量はリポジトリ固有の規約に使います。対象となる契約を差し置いて、一般的な命名、役割、ログ記録、リソースの一覧で埋めないでください。Active ラベルの削除やセクションの統合を行う場合も、すべてのカバレッジ行を漏れなく扱ってください。

• Generate： ./references/agents_md_template.md の構成に従ってドキュメントを出力します（単一のリポジトリ／パッケージでは 4～5 セクション、モノレポのルートでは 2～3 セクション。Ownership Map に根拠に基づく内容があるかどうかによります）。最初の ## 見出しより前のプリアンブルに、単独の `` 行をちょうど 1 行追加します。モノレポのルートには monorepo_root を使用します。Working Agreements セクションと、ルートが存在しない場合の代替策には ./references/working_agreements.md を使用します。

• Update：既存ファイルに対してセクションパーサーを実行します。

  python ./scripts/parse_sections.py <path/to/AGENTS.md> --doc-type single_repo
  

  （モノレポのルートには --doc-type monorepo_root を使用します。移行の準備中は、Step 1 で指定された元のタイプを使用します。）出力では、各 ## 見出しが is_standard（管理ゲートの対象となる置換候補）かどうかが示され、根拠が必要な見出しには optional_standard が設定され、一致した任意セクションには is_optional_standard が設定されます。従来の ## 2. Folder Structure セクションでは canonical_title: "## 2. Ownership Map" と報告されるため、承認済みの更新で移行できます。置換するのは標準セクションの本文のみとし、カスタムセクション、ファイルタイトル、プリアンブルは、承認済みのマーカー挿入またはタイプ移行のための置き換えを除き、変更しないでください。必須の見出しが欠けている場合は、番号順の位置に挿入します。任意の見出しが欠けている場合は、新たな分析で根拠に基づく内容が得られたときに限り挿入します。完全な再構成のルールは ./references/update_strategy.md を参照してください。

  管理ゲート：is_standard だけで判断せず、Step 1 の管理判定結果を使用します。マーカーのないファイルでは、置換、挿入、削除、マーカー挿入の具体的なプレビューを完成させたうえで、一度限りの採用確認を得ます。承認された場合は、採用とマーカーを同時に書き込みます。拒否された場合は、元のファイルを変更しません。一般的な更新依頼は採用確認にはあたりません。明示的に承認されたマーカー挿入を除き、標準外の内容と既存のプリアンブルはすべて保持します。無効なマーカーは、黙って修正せず、報告してください。詳細は更新戦略を参照してください。

  既存のドキュメントタイプがリポジトリの実態と合わなくなった場合（例：単一リポジトリがモノレポになった場合）は、更新ではなく完全な再生成を強制します。すべてのカスタムセクションを元の順序のまま一字一句変更せず、再生成したドキュメントに引き継ぎ、上書きする前にユーザーの確認を得てください。

Step 6 — 検証と書き込み

書き込む前に、次の点を確認します。

• 前文と標準（管理対象）セクションを合わせた長さが character_limit の範囲内です。再配分後はセクションごとの割り当てを超えてもかまいませんが、各セクションの役割は維持し、埋め草を追加しないでください。カスタムセクションは予算の対象外であり、予算を満たすために削ってはなりません。
• 前文には有効な管理マーカーがちょうど1つあり、文書の種類は出力と一致しています。マーカーは前文の予算に含めます。承認されたマーカーの挿入または種類変更に伴う置換を除き、前文はそのまま維持してください。マーカーのないファイルは、具体的な適用プレビューが承認された後にのみ作成します。
• アンチパターンに該当するものが含まれていません（共通コマンド、実行／テスト／ビルド／デプロイの手順、IDE／ツール設定など）。例外として、Working Agreementsで見つかった型チェックコマンドは必須の内容であり、ビルド／実行手順には該当しません。
• Update モードの場合：すべての標準セクション本文を管理対象ソースから再構成しており、以前の表現が問題ないように見えたことを理由に流用していません。
• どちらのモードでも：最終的な圧縮後、./references/content_quality.mdに従い、組み立てた文書と作業用ファクトレコードを照合します。確認済みの重要な事実はすべて、伝達するか、現在の動作に合わせて修正するか、根拠に基づく理由を示して除外する必要があります。構成と長さを満たしていても、説明のない欠落や歪曲があれば検証不合格です。再確認済みの識別子や意味は、新たに書き直したセクションでも繰り返してかまいません。新鮮な表現にするために有用な事実を消す必要はありません。再配分と圧縮を行っても重要な事実を収められない場合は、レビュー可能な候補を作成したうえで、スコープまたは全体の上限について確認してください。
• 圧縮後、./references/plain_language.mdの読者タスク確認に照らして、生成した文章をレビューします。コントリビューターが略語を解読しなくても、変更箇所と担当者、適用条件を特定し、記載された契約と検証対象を利用できる必要があります。確認済みの意味を保ちながら、不明瞭な管理対象の文章を修正してください。このレビューは、カスタムセクション、維持する前文、正規の見出し、文字数制限を変更する許可にはなりません。
• 一時レコードと最終出力を一緒に読み、重要な事実ごとに、最終出力の該当する文を特定して、適用関係の各フィールドを確認します。復旧、移行、復元、再利用、ガード、リソース所有権に関する広範な主張は、実装しているヘルパーと照らし合わせて逆方向にも確認してください。レコードと文章の両方に条件が記載されていない場合は、ヘルパーを再調査します。両者が一致しているだけでは合格になりません。この監査はAGENTS.mdの外で行い、重要な修正点または制約のみをユーザーに報告してください。
• 深さだけでなく網羅性も確認します。以前の管理対象の境界／ルート／フロー、および文書化または登録された機能候補すべてについて、現在の扱いが決まっており、openの行が残っていないことを確認してください。履歴がないこと、「価値が低い」という一般論、スペース不足は、現在の安全契約を除外する理由にはなりません。パイプラインの一般的なステージ名だけでは、実際の選択内容や復旧条件を説明したことにはなりません。
• Update モードの場合：管理対象の標準セクションのみを対象に、継続的に適用される古い作業合意の表現がないか確認します。管理対象の内容にKeep edits minimal、Minimal changes、preserve public APIs、existing plugin behavior、avoid unnecessary abstractionが残っている場合、検証は不合格です。カスタムセクションには、ユーザーが所有する任意の表現を残してかまいません。
• Update モードの場合：維持するカスタムセクションはすべて、元の内容とバイト単位で完全に一致しています。
• Update モードの場合：管理対象の標準セクションから削除する表現があるときは、その内容を上書きする前にユーザーへ報告します。管理対象セクションにユーザーが追加した内容は維持されないため、削除される項目を列挙し、ユーザー所有の内容はカスタムセクションに移すよう提案してください。
• Update モードの場合：既存の管理対象Ownership Mapまたは従来のFolder Structureセクションを、現在の根拠がないため省略する場合は、そのセクション全体を削除することを報告し、上書き前に確認を得てください。
• 単一リポジトリ文書の場合：管理対象のWorking Agreementsセクションに、パッケージ単位のAGENTS.mdに関するガイダンスなど、モノレポに限定される表現が含まれていません。
• パッケージ文書の場合：ルートへの参照先が既存ファイルに解決されます。そうでない場合は、パッケージに共通の作業合意を直接含め、存在しないルートへの参照を含めません。以前の更新でフォールバックを使った後にルート文書が作成された場合は、通常の管理対象セクションの置換と削除表現の報告を行い、継承方式に切り替えてください。 その後、Edit/Write ツールで書き込みます。Monorepo のモードが All の場合は、ルートの処理後、対象パッケージごとに手順 2～6 を繰り返します。各パッケージについて、手順 1 の生成／更新の判断、管理状況の確認、ルートの存在確認を再実行してください。ルートが Update でも、AGENTS.md がないパッケージは Generate になります。

ツール

このスキルでは、リポジトリの分析に以下の読み取り専用ツールを使用します。詳しい使用パターンについては、./references/read_only_commands.md を参照してください。

• Serena MCP のシンボルツール（利用可能な場合に優先）：find_symbol、find_referencing_symbols、find_referencing_code_snippets、get_symbols_overview、search_for_pattern、list_dir、find_file、read_file。シンボルの検索、呼び出し元の追跡、構造分析では、rg／grep／find よりこれらを優先してください。一覧に記載された読み取り専用ツールのみを使用し、書き込み／編集用のシンボルツールや execute_shell_command は呼び出さないでください。./references/read_only_commands.md#symbol-level-analysis-optional-requires-serena-mcp を参照してください。
• tokei：LOC の測定（必須）
• rg（ripgrep）：コンテンツ検索（Serena MCP が利用できない場合の代替）
• grep／Select-String：コンテンツ検索（Serena と rg のどちらも利用できない場合の OS ごとの代替）
• sed -n／Get-Content \| Select-Object：OS ごとのページ単位のファイル読み取り
• tree：ディレクトリ構造の可視化
• find：ファイルとディレクトリの検出（Linux／macOS で、Serena の find_file が利用できない場合の代替）
• ls、pwd：基本的なディレクトリ移動
• git log、git show --stat、git show --name-only：Update モードでの所有範囲の特定に使うシグナル。まず付属スクリプトを使用し、次にメタデータと変更パスを確認します。デフォルトでは広範な差分を確認しないでください。

バンドル済みスクリプト

決定論的な手順は ./scripts/ 配下のスクリプトにまとめられており、呼び出しやプラットフォームを問わず同じように実行されます。自然言語でロジックを再構築するより、これらを優先してください。

• scripts/loc_to_limit.py：指定された除外条件で tokei を実行し、Total 行を解析して {loc, scale, character_limit} を返します。tokei が見つからない場合は、インストール方法を表示してゼロ以外の終了コードで終了します。
• scripts/detect_monorepo.py：マーカーファイル（pnpm-workspace.yaml、lerna.json、nx.json、turbo.json、rush.json、.moon/workspace.yml、go.work、Cargo.toml [workspace] members、package.json の workspaces、Gradle の settings.gradle*、Maven の pom.xml <modules>、Bazel、Buck2、Pants、Hatch／uv／rye）を確認します。Gradle の照合では、複数行形式を含むリテラルの include 宣言全体を読み取り、コメントや文字列の例を無視し、プロジェクトパスの重複を除去します。動的な Gradle 式は評価しません。{is_monorepo, markers} を返します。true の結果は暫定的なものであり、パッケージの検出で 2 つ以上のパッケージが見つかるまでは確定しません（手順 1）。
• scripts/parse_sections.py：Update モード用。標準見出しの候補、カスタムセクション、欠落している見出しを含むセクションマップに加え、management_status と generated_doc_type を返します。既存の JSON フィールドと --doc-type の照合方法は変更されません。利用側は書き込みの前に管理状況のゲートを適用する必要があります。フェンス付きコードブロック内の見出しやマーカーは無視されます。パーサーは内容を書き換えず、行範囲を報告します。行末と末尾の空白を保持するため、保持する範囲は元のバイト列から切り出してください。
• scripts/git_ownership_signals.py：Update モード用。対象ディレクトリの git 履歴をトークンセーフな方法で集約し、変更頻度が高いパスを示す簡潔な Markdown-KV シグナルを出力します。この出力は調査の手がかりにすぎません。Ownership Map の境界を記述する前に、現在のコードと照らし合わせて確認する必要があります。

ドメイン知識

• LOC の測定：リポジトリの規模を測定し、文字数の上限を判定する機能です。./references/loc_measurement.mdを参照してください。
• リポジトリ分析：コードベースの構造を調査し、理解する機能です。./references/read_only_commands.mdを参照してください。
• 出力テンプレート：標準化された AGENTS.md の構造仕様です。./references/agents_md_template.mdを参照してください。
• コンテンツの品質：意思決定に役立つ事実の発見、根拠に基づく情報の保持・修正、圧縮の順序、最終的な意味の比較です。./references/content_quality.mdを参照してください。
• 平易な表現：読者のニーズ、見つけやすいラベル、明確な技術文書、ISO 24495-1:2023 に基づく最終的な読者タスクのレビューです。./references/plain_language.mdを参照してください。
• 作業上の合意事項：生成するドキュメントに関するエージェントの動作ルールです。./references/working_agreements.mdを参照してください。
• モノレポの検出：モノレポの構造を特定する機能です。./references/monorepo_detection.mdを参照してください。
• モノレポ戦略：モノレポでドキュメントを生成するための戦略です。./references/monorepo_strategy.mdを参照してください。
• 更新戦略：セクションを選択して更新することで、既存の AGENTS.md ファイルを更新する戦略です。./references/update_strategy.mdを参照してください。

適用範囲の境界

• 読み取り専用分析：リポジトリの調査に、破壊的変更を伴わないコマンドを使用します。
• 出力範囲：ドキュメントの内容のみを生成し、実行・テスト・ビルド・デプロイの手順は含めません。リポジトリの分析で具体的かつ安定した内容が見つからない場合は、任意のセクションを省略します。
• 対象外の入力：ロックファイル（pnpm-lock.yaml、package-lock.json、yarn.lock など）は分析対象外です。
• 単一コンテキストでの実行（サブエージェント禁止）：このスキルは、いかなる段階でもサブエージェント（Agent / Task ツール、Explore、general-purpose、または委任されたエージェントなど）を起動してはなりません。AGENTS.md の生成には、リポジトリ全体を一貫して把握する必要があります。蓄積されたスタックのコンテキスト（ステップ 3）、セクションごとの文字数予算（ステップ 2）、3 か所以上にわたるフェーズ 3 の検証、Update モードでのカスタムセクションのバイト単位での完全な保持は、すべて単一のコンテキストに依存します。作業をサブエージェントに分割すると、この状態が失われ、一貫性のない出力や予算超過につながります。親エージェントがこのスキルを呼び出すことは問題ありませんが、スキルの内部実行は単一のコンテキスト内で行う必要があります。