mindmap-ppt-builder

マインドマップ PPT ビルダー

目標

ユーザーが提供したソース文書を、このリポジトリ用のプレゼンテーションに適した project/source.js に変換します。ソース文書は、会話に貼り付けられたテキスト、またはユーザーが指定したローカルのテキスト／Markdown ファイルのパスです。出力は、簡潔な2行のノード、任意のノード画像、現在の明るい PPT スタイルに合ったローカルアセットで構成される、先行順のマインドマップです。

プロジェクトファイルの正確な規約や視覚上の制約が必要な場合は、references/project-format.md を読んでください。

ワークスペースの要件

このスキルは、現在の作業ディレクトリツリー（cwd 自体、またはその配下の mindmap-ppt/ サブフォルダー）内でのみ動作します。既存のチェックアウトを探すために、親ディレクトリ、兄弟ディレクトリ、ホームディレクトリを検索しないでください。

• https://github.com/agegr/mindmap-ppt を現在の作業ディレクトリ配下の ./mindmap-ppt/ にクローンし、そのディレクトリに移動してください。
• ./mindmap-ppt/ がすでに存在する場合は、停止して、どのように進めるかをユーザーに確認してください。別の場所にあるチェックアウトを探したり作成したりするために、cd ..、find、その他の方法でファイルシステムを調べないでください。
• アプリケーションのリポジトリはスキルフォルダーの外に置いてください。.agents/skills/mindmap-ppt-builder/ に index.html、src/、project/ をコピーまたはクローンしないでください。
• 通常のスキル出力で変更するのは、project/source.js と project/ 配下のローカルアセットのみです。
• ユーザーが明示的に整理を依頼しない限り、既存のプロジェクトアセットを削除しないでください。
• ユーザーが実装変更を明示的に依頼しない限り、src/、index.html、アプリケーションの動作を編集しないでください。

ワークフロー

1. ユーザーのソースドキュメントを取得します。
   • 会話内に貼り付けられたテキストがある場合は、それを使用します。
   • ユーザーがローカルファイルのパスを指定した場合は、その明示されたドキュメントファイルのみを読み込み、内容を使用します。
   • 貼り付けられたテキストも読み取り可能なローカルファイルもない場合は、project/source.js を生成する前に、ドキュメントの提供をユーザーに依頼します。
2. ドキュメントを読み、プレゼンテーションの主旨を特定します。
   • 特に指定がなければ、ソースの言語に合わせます。中国語の入力には中国語で、英語の入力には英語で出力します。
   • 英語で出力する場合も、自然なときは2行のノードにアイブロー／見出しの構造を使用します。
   • 事実を黙って訂正しないでください。ソースに明らかな矛盾や疑わしい主張がある場合は、慎重に主張を維持するか、食い違いをユーザーに伝えます。
   • 非常に長いドキュメントでは、まず元の章構成を維持します。内容が広範すぎて確信を持って要約できない場合は、概要レベルのアウトラインを作成し、仕上げる前に優先事項をユーザーに確認します。
3. 明確なロジックツリーを構築します。
   • ルート：ドキュメント／ソース名、またはプレゼンテーションのトピック
   • 主な枝：通常は2～4つのセクションとしますが、別の構成のほうがソースの論理に沿う場合はそちらに従います。
   • 子ノード：原因、結果、根拠、例、手順、対比、補足に使用します。
   • 階層：ネストによって著者の論理が理解しやすくなる場合にのみ、階層を追加します。
4. 各ノードを、箇条書き1項目と任意の続きの行で記述します。

- 副标题
  主标题

1行目には短いカテゴリラベルを、2行目には主なメッセージを記載します。各行は中国語で約30文字、英語で8語以内を目安にします。表示されるすべてのノードで2行のラベルを優先し、ラベルが非常に短く明確な場合に限り、1行のノードを使用します。 5. 画像ノードは控えめに選びます。

• ノード画像は任意です。
• マインドマップではソースの詳細の多くが省略されるため、情報量の多いノードでは、画像を使って省略された詳細を保持したり、説明したりします。
• 一般的なスライド資料では、情報量の多いノードを3～8個選びます。短い草稿では画像を0～2枚にしてもかまいません。
• プロセス、アーキテクチャ、比較、タイムライン、指標、概念モデルを要約するノードを優先します。

6. 選んだノード用のイラストを GPT Image 2 または利用可能な画像生成ツールで生成します。project/ またはそのサブフォルダーに保存します。
   • 生成したラスターイラストには PNG、図やプレースホルダーには SVG、写真風のアセットには JPG を優先します。
   • 画像生成が利用できない場合は、画像を省略するか、同じ控えめな配色で project/ にシンプルな SVG のプレースホルダー図を作成します。16:10の構図にし、必要な場合のみ短いテキストを最小限に使用します。また、project/demo-flow.svg のような内容がわかるケバブケースのファイル名を付けます。
7. Markdown のメタデータ行で画像を参照します。

  @image process-overview.png

8. project/source.js を次の内容で置き換えます。

export const sourceMarkdown = `
- ...
`;

JavaScript のテンプレート文字列にユーザー由来のテキストを書き込む前に、バッククォートと ${...} のシーケンスをエスケープします。 9. npm run check を実行します。 10. 任意の視覚的な検証：npm run dev を実行し、ブラウザーでの確認が可能な場合は、Vite が出力した URL（デフォルトは http://127.0.0.1:5173/ ですが、ポートが使用中の場合は異なることがあります）を確認します。

マインドマップ作成ルール

• すべてのデッキを、厳密な root -> level 1 -> level 2 -> level 3 の分類体系に無理に当てはめないでください。この形は便利な既定値にすぎず、ルールではありません。
• 階層には、作成者の論理構造を反映させてください。原因 A が結果 B につながるなら、B を A の子ノードにできます。さらに B が結果 C につながるなら、A -> B -> C のサブツリーを作成してください。
• 唯一の絶対的な原則は明確さです。各子ノードが親ノードの下に置かれる理由と、表現される関係性が読者に伝わるようにしてください。
• 原文の順序に従ってください。このアプリでは、ノードが先行順で表示されます。つまり、最初に親ノードが表示され、次にすべての子ノードが表示されます。後の文章にある結論を、前にある親ノードのラベルに移さないでください。
• 子ノードでルートのトピックを繰り返さないでください。ルートですでに問題やテーマを示している場合、子ノードでは話を先に進めてください。
• 内容の近いものは、1つの親ノードの下にまとめてください。背景、基準、リスク、製品やツールの一覧、推奨事項、結論は、それぞれまとまりのある独自のブランチにしてください。
• メインノードには判断を、子ノードには根拠、理由、例、補足を記載してください。あるノードが別のノードを説明する場合、兄弟ノードではなく子ノードにしてください。
• 各親ノードの子ノードは最大5つにしてください。それより多い場合は、グループ化ノードを追加してください。
• 原文でツールや製品が1つずつ分析されている場合に限り、個別のノードに分けてください。選択肢としてさらっと列挙されているだけなら、まとめてください。
• 文ごとに分割しないでください。1つのノードでは、まとまりのある小さな要点を1つ扱ってください。
• 各ノードは、原文のおよそ10～80文字に対応するようにしてください（これはノードが扱う原文の範囲であり、表示されるラベルの長さではありません）。10文字未満では細分化しすぎていることが多く、80文字を超える場合は通常、分割が必要です。
• ノードのテキストは通常のタイトルより多少長くてもかまいませんが、1つのノードに複数の独立したアイデアを含めないでください。
• 親ノードのラベルは要約と案内の役割を果たし、子ノードのラベルで具体的な内容を示してください。後の詳細を明かす親ノードのラベルは避けてください。
• 画像は、フレームワーク、比較、一覧、推奨事項、リスクモデルなど、情報量の多いノードに配置してください。ごく細かなノードへの画像の配置は避けてください。

Markdown と画像の例

ノードに表示される2行のラベルの後に、メタデータ継続行として @image を使用してください。@image 行はノードのテキストとして表示されません。

export const sourceMarkdown = `
- 产品发布
  三分钟讲清楚新功能
  @image overview.png
    - 用户痛点
      当前流程成本很高
      @image image-asset-1/pain-points.jpg
    - 解决方案
      自动整理文稿和插图
    - 演示效果
      像 PPT 一样逐步展开
      @image diagrams/demo-flow.svg
`;

画像のパスは、既定で project/ からの相対パスです。

• @image overview.png -> ./project/overview.png
• @image image-asset-1/pain-points.jpg -> ./project/image-asset-1/pain-points.jpg
• @image diagrams/demo-flow.svg -> ./project/diagrams/demo-flow.svg

画像プロンプトのパターン

GPT Image 2 には、次のスタイルプロンプトを使用してください。

Create a clean presentation illustration for a light PPT mind-map node.
Subject: <node main idea>.
Include: <2-4 concrete visual elements from the source text>.
Style: restrained vector-like editorial illustration, warm off-white background, dark teal #183a4a, muted green #eef7f3, orange accent #d8894f, simple geometric shapes, thin shadows, small 8px-radius card-like forms, no photorealism, minimal short text only when useful, no logos, no busy decorations.
Composition: centered, generous whitespace, readable at thumbnail size, aspect ratio 16:10.

原文で実際のグラフ、図、スクリーンショットが必要な場合は、正確な数値を創作するのではなく、シンプルな図解を作成してください。画像内のテキストはできるだけ避けてください。理解の助けになる場合は、1～3個の短いラベルまたはキーワードだけを使い、詳しいラベルはノードに記載してください。

SVG プレースホルダーのパターン

画像生成ツールを利用できない場合でも、イラストが有用であれば、シンプルな SVG プレースホルダーを使用できます。

• サイズ：1280x800。
• スタイル：温かみのあるオフホワイトの背景、濃いティール #183a4a、落ち着いたグリーン #eef7f3、オレンジのアクセント #d8894f。
• 内容：ノードのアイデアに基づいた抽象的なプロセスブロック、矢印、カード、またはタイムラインの形。
• 必要な場合のみ、短いテキストを最小限使用してください。ロゴ、装飾過多、フォトリアリズムは避けてください。

画像とアセットのルール

• @image は、ノードのタイトル行の後、子ノードの前にのみ配置してください。
• PNG、JPG/JPEG、または SVG アセットを使用してください。
• 画像ファイルは project/ またはそのサブフォルダーに保存してください。
• @image user-journey.png、@image diagrams/user-journey.png、@image image-asset-1/a.jpg のように、project/ からの相対パスで短い @image の値を指定してください。

検証チェックリスト

• project/source.js で sourceMarkdown をエクスポートしている。
• すべての @image に対応するアセットファイルが存在する。
• npm run check が成功する。