内容優先 Markmap マインドマップ は何をしますか？
プロジェクト、ドキュメント、コードベース、またはコンセプトを Markmap でレンダリング可能な Markdown に整理し、必要に応じて構造検証や HTML 生成を行います。
コアルール
- 全体から部分へ：ルートテーマで対象と目的を説明し、実際のメインコンセプト、フロー、モジュール、詳細に展開します。
- 資料そのものを使ってマインドマップを整理します。初心者向けに空疎な分類見出しを発明しないでください。
- 分類のみを目的とする見出し（例：「プロジェクトの位置づけ」「動作メカニズム」「開発全体像」「コアコンセプト」「主要モジュール」「ユースケース」など）は削除します。ただし、これらの単語が元の資料の一部である場合は除きます。
- 各ノードの直接の子ノードは最大 7 つとします。優先的に 5 つ前後に抑え、内容が本当に必要な場合のみ 6～7 つに拡張します。
- 実際の内容が多くても、7 つを超えるブランチを並べてはいけません。資料内の現実のサブトピックに従ってグループ化を続けてください。
- ある階層で 7 つを超えるブランチが必要に見える場合は、まず類似の内容を統合し、「全体 -> グループ -> 局所詳細」の順に再配置します。
- 類推（アナロジー）は任意です。記憶に本当に役立つ場合のみ使用し、内容ラベルの後に配置します。類推をノードの主体にしてはいけません。
- 確実性を捏造しないでください。リポジトリを要約する前に、README、ドキュメント、パッケージ設定、テスト、ソースコードディレクトリ、ローカルスクリプトを確認してください。
- マインドマップは簡潔に保ちます。ノードは短い内容ラベルを使用し、必要な場合にのみ根拠のある説明を 1 文追加します。
複雑なリポジトリや長いドキュメントを扱う場合は、まず references/analogy-structure.md を読んでください。
ワークフロー
- まず資料を調査します。
- リポジトリ：
README、AGENTS.md/CLAUDE.md、パッケージ設定、ドキュメント、トップレベルディレクトリを確認します。 - ドキュメント：テーマ、主張、セクション、繰り返し概念、覚えるべき用語を探します。
- リポジトリ：
- 全体から部分へ Markdown をドラフトします。
- 1 つの H1 ルート見出しで対象を説明します。
##を使用して実際の内容のバックボーンを展開します。「読者向けの分類バケツ」は使用しません。- 各ノードでは、先に資料内の実際のコンセプト、システム、フロー、ファイルパス、API、主張、責務を配置します。
- 詳細が理解に役立つ場合にのみ展開を続け、無理にブランチを追加しないでください。
- 各親ノードの直接の子ノードは最大 7 つ、優先的に 5 つ前後にします。7 つを超える場合は、現実のサブトピックに基づいて再グループ化します。
- スクリプトで Markdown を検証します：
python3 ~/.codex/skills/markmap-analogy-mindmap/scripts/validate_and_render.py input.md --validate-only
- HTML の提供が必要な場合、Markmap をレンダリングします：
python3 ~/.codex/skills/markmap-analogy-mindmap/scripts/validate_and_render.py input.md -o output.html
- 検証に失敗した場合は、まずマインドマップ構造を修正します。ユーザーが明示的に非標準のマインドマップを要求した場合を除き、「空疎な分類」や「階層のブランチ超過」のチェックをバイパスしないでください。
Markmap レンダリング
スクリプトは以下の順序で試行します：
markmapnpx --yes markmap-cli- ローカルの
/root/markmapにあるビルド済み CLI
利用可能なレンダラーがない場合、検証に合格した Markdown を成果物として返し、HTML が生成されなかったことを説明します。
出力要件
- ファイル作成後、
.mdと.htmlのパスを返します。 - 調査したソース、および検証/レンダリングコマンドの結果を説明します。
- ユーザーがソースリポジトリの変更を要求しない限り、ソース資料は読み取り専用とします。
- 中国語ユーザーにはデフォルトで中国語のマインドマップを出力します。コマンド、パス、API、パッケージ名、用語で英語を保持する必要がある場合のみ英語を使用します。