mcpField
A
awesome-ai-ppt

awesome-ai-ppt

github.com/ningzimuドキュメント17339 回インストール今日更新
リポジトリ

awesome-ai-ppt について

awesome-ai-ppt は、AI プレゼンテーションツールのキュレーションリストを調べる Agent スキルです。リモートの索引で候補を把握し、要件と各プロジェクトのリポジトリに基づく評価を案内します。

主な機能

  1. 01リモートのプロジェクト索引を読む
  2. 02要件に沿って候補を絞り込む
  3. 03候補の元リポジトリを確認する
  4. 04リストへの貢献手順を案内する

活用シーン

  1. 01要件に合うプレゼンツールの選定
  2. 02候補の出力形式と連携方法の比較
  3. 03リストへの報告や貢献の準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ningzimu/awesome-ai-ppt --skill awesome-ai-ppt

インストール後、Claude Code で/awesome-ai-pptを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
contribution-workflow.md
curation-rules.md

詳細

Awesome AI PPT

このスキルは、厳選リスト awesome-ai-ppt を扱うために使用します。このリストは、AI を活用したプレゼンテーションツールを見つけるためのインデックスとして扱い、元のプロジェクトを読む代わりにはしないでください。

最初のステップ

リモートの awesome-ai-ppt リストから始めます。

  • https://github.com/ningzimu/awesome-ai-ppt または GitHub の Raw URL から、公開されている docs/projects.json を読みます。
  • ユーザーに質問する前に、候補となるツールの全体像を把握できる程度に、すでに掲載されている PPT ツールの項目と説明を読みます。
  • ユーザーのニーズを尋ねる前に、すべての候補の元のリポジトリを開かないでください。元のリポジトリを詳しく調べるのは、ユーザーの要件によって候補が絞り込まれてからにしてください。

ツール選定のワークフロー

ユーザーが PPT ツールの推薦、比較、選定のサポートを求めている場合は、このワークフローを使用します。

  1. まず、リモートの docs/projects.json にあるツールの項目と説明を読み、候補となるツールの全体像を把握します。
  2. 選定する前に、ユーザーの実際のニーズについて詳しく質問します。対象読者、希望する出力形式、編集可能性、ビジュアル品質、自動化の範囲、エージェントとの連携、入力資料、ローカル/クラウドの制約、予算や時間の制約、セットアップの複雑さに対する許容度を確認します。
  3. ユーザーの回答をもとに docs/projects.json を検索し、条件に合う候補を3〜6件に絞り込みます。
  4. 有力な候補ごとに元のリポジトリを確認します。awesome リストの説明、タグ、スター数だけに頼らないでください。
  5. 具体的な根拠に基づいて候補を比較します。
    • 主なワークフローと出力形式
    • 生成されるスライド資料の編集可能性
    • エージェントスキル、MCP、API、CLI、ライブラリとの連携方法
    • インストール/セットアップの複雑さ
    • サンプル、ドキュメント、メンテナンス状況を示す情報
    • 既知の制限や、ユーザーのニーズとの不一致
  6. 人気だけでなく、ユーザー固有の制約に基づいて推薦します。回答では、リスト上の概要情報と元のリポジトリから確認した内容を分けて示します。ユーザーが手早く大まかに絞り込むことを明示的に希望した場合は、十分な検証は行っていないと伝えます。

コントリビューションのワークフロー

ユーザーが問題の報告、Issue の提出、プロジェクトのコントリビューション、リストの更新、メタデータの修正、PR の準備または提出を明示的に依頼した場合に限り、コントリビューションモードに入ります。

リンク切れ、プロジェクトの掲載漏れ、説明の不備、分類の誤りの可能性に気づいたからといって、先回りして Issue や PR を作成しないでください。ユーザーが単にツールを選んでいるだけの場合は、必要に応じて、リストの問題は GitHub Issues から報告できると伝えるにとどめます。

サードパーティのコントリビューターを支援する場合:

  1. references/curation-rules.md を読みます。
  2. references/contribution-workflow.md を読みます。
  3. 編集する前に、そのプロジェクトや問題がリストに適合しているように見えるかを説明します。
  4. 元のリポジトリを参照し、ワークフロー、入出力形式、編集可能性、スキル/MCP のサポート、ライセンス、スター数、メンテナンス状況の根拠を集めるよう、コントリビューターを案内します。
  5. PR を準備する場合は、更新が必要なファイルと実行すべきチェックを具体的に説明します。
  6. Issue を準備する場合は、簡潔にまとめ、根拠となるリンク、想定カテゴリ、希望する変更を含めます。
  7. リポジトリで求められているバイリンガル対応や README 生成の要件を、コントリビューターが省略できると示唆しないでください。

出力スタイル

  • 推薦は簡潔にし、根拠に基づいた実用的な内容にします。
  • 正式な GitHub リンクを優先します。
  • 結論が元のリポジトリを確認したうえでのものかどうかを明記します。
  • プロジェクトを宣伝せず、実際の機能を説明します。
  • ユーザー向けの変更を提案または実施する際は、リポジトリが求めるバイリンガル対応を維持します。

コメント