Agent Skills
› NeverSight/learn-skills.dev
› zukai-creator
zukai-creator
GitHub从文本、笔记等提取要素与关系，选择图解模式并定义样式，生成清晰的概念图或说明图。适用于幻灯片、文章插图等场景。不用于定量图表、复杂信息图或图像生成。
触发场景
需要制作概念图或解释性示意图
将长文本或模糊输入转化为结构化视觉内容
为演讲或文档创建辅助理解的图解
安装
npx skills add NeverSight/learn-skills.dev --skill zukai-creator -g -y
SKILL.md
Frontmatter
{
"name": "zukai-creator",
"description": "テキスト・メモ・記事・スライド・説明文から、要素・関係性・グループ・ラベルを抽出し、図解パターンとスタイリングルールを選んでわかりやすい日本語の概念図解を作る。図解・概念図・説明図・スライド用ビジュアル・ビジュアル要約を作るときに使う。定量データのグラフ、本格的なインフォグラフィック制作、画像生成、装飾的なイラストには使わない。"
}
Zukai Creator
手順
Step 1: 図解の役割を定義する
- 想定する媒体を特定する: スライド、記事の図版、SNS投稿、ホワイトボードのラフ、ドキュメントの図、レビュー用の成果物など。
- 目的・読者・たった一つの主メッセージを抽出する。これらが欠けている場合は、設計に入る前に簡潔な確認質問を一つだけ投げる。
- 観察と解釈を分ける。ソースの主張は保ち、プロセス・指標・因果関係を勝手に創作しない。
- 入力が長い、または曖昧な場合は、図解の前に短いソース要約を作る。
Step 2: ソースを図解の部品に分解する
- 構造化されたブリーフが役立つ場合は、スキル同梱の
assets/diagram-brief-template.jsonを読む。 - 要素の候補を抽出する: 人、チーム、製品、概念、状態、ドキュメント、ステップ、入力、出力など。
- 重要なテキストは、概念的に図形で囲んで要素に変換する。素のテキストラベルは補助的なものとして扱い、要素とはみなさない。
- 要素間の関係性を抽出する。提案する・変換する・依存する・比較する・含む・分岐する・統合する のような短い動詞を優先する。
- 要素がフェーズ・カテゴリ・所有者・レイヤー・境界を共有するときはグループを抽出する。
- 不確かな点は図の中に隠さず、未解決の問いとして列挙する。
Step 3: パターンを選ぶ
- 図解パターンを選ぶために、スキル同梱の
references/pattern-catalog.mdを読む。 - メッセージをパターンに対応づける:
- 時間・ステップ・プロセス・変化には、シーケンスやタイムラインを使う。
- 原因・結果・流れ・影響には、矢印・分岐・収束を使う。
- 分類・構造・構成要素には、階層・包含・表形式を使う。
- 比較・選択・優先順位には、対比やマトリクス形式を使う。
- 交換・交渉・相互影響には、双方向のコネクタを使う。
- 構造が自明でない場合は、少なくとも2つの候補パターンを生成する。
- 余計な解読なしにメッセージを伝えられる、最もシンプルなパターンを優先する。
Step 4: 低忠実度の図解仕様をラフに描く
- 仕上げに入る前に、まずラフなテキストレイアウトから始める。シンプルな図形・短いラベル・方向付きコネクタを使う。
- 描く前に図形の意味づけを決める: 例として、矩形はアクター、円は概念、角丸矩形はプロセスなど。
- コネクタのラベルは、それが説明する線や矢印の近くに置く。
- グループ化は主たる方法を一つに絞る: 背景色、囲み枠、余白、区切り線、ブラケットなど。すべての方法を重ねがけしない。
- 図が密になりすぎたら、複数の図に分割するか、詳細を表へ移す。
Step 5: 理解のためにスタイリングする
- 仕上げの前に、小さなスタイリングルール一式を定義する: フォントの太さ、塗り色、線の太さ、矢印の種類、強調ルール。
- 同じ意味には、図全体で同じビジュアル表現を使う。
- 通常の図では、ブランドルールが要求しない限りフォントの太さは最大2種類にとどめる。
- 暗い塗りの上の白文字は、コントラストが十分に高い場合だけ使う。白抜き文字には太字のサンセリフを優先する。
- アイコン・絵文字・ロゴ・イラストは、それらなしで構造が成立してから初めて追加する。
- 意味的な理由なく見た目の重要度を変えるような、装飾的なスタイリングは避ける。
Step 6: 図解ブリーフを検証する
- JSONブリーフを作成したときは、スキルディレクトリから
python scripts/check-diagram-brief.py path/to/brief.jsonを実行するか、絶対パスでスクリプトを指定する。 - 報告された欠落フィールド・無効な要素参照・重複した要素IDをすべて修正する。
- JSONブリーフを作らない場合は、出力に目的・読者・メッセージ・要素・関係性・採用パターン・スタイリングルールが揃っているか手動で確認する。
Step 7: レビューと改訂
- 最終納品の前、または別ツールへ図を渡す前に、スキル同梱の
references/review-checklist.mdを読む。 - 図が一文で何を語っているかを問うてテストする。その答えが意図したメッセージと違うなら、スタイリングより先に構造を改訂する。
- 線の向き・グループ化・ラベルが、口頭の説明なしで理解できるか確認する。
- 図がクライアント向け・教育用・意思決定文書で使われる場合は、外部からのフィードバックを求める。
- 最終成果物を要求された形式で納品する: テキストの図解仕様、Mermaid、SVG/HTMLの指示、スライド向けガイダンス、デザインツール向けの実装プロンプトなど。
出力フォーマット
ユーザーが特定のファイル形式を要求しない限り、次の構成を使う:
- 図解の目的: 一文。
- 主メッセージ: 一文。
- 抽出した要素: 要素と役割の箇条書き。
- 関係性: 向きとラベル付きのコネクタの箇条書き。
- 採用する型: パターン名と理由。
- ラフ構成: テキストレイアウト、Mermaid、または簡潔な作図指示。
- スタイリングルール: 図形・色・線・フォント・グループ化の意味づけ。
- 確認事項: 未解決の問いとレビューチェックリストのメモ。
エラーハンドリング
- ソースの主張が多すぎる場合は、すべてを1枚のキャンバスに詰め込まず、メッセージやフェーズごとに図を分割する。
- 関係性が不明確な場合は、矢印なしの要素マップを作り、不足している関係性の根拠を列挙する。
- 定量的な比較が中心になる場合は、このスキルの使用をやめ、チャートやデータ可視化のワークフローを使う。
- ユーザーが完成イラストや生成画像を求める場合は、まず図解ブリーフを作り、その後に画像生成やWebデザインのワークフローへ引き継ぐ。
- スキル同梱の
scripts/check-diagram-brief.pyが失敗した場合は、JSONを修正して再実行し、ブリーフが整ったと判断する前にパスさせる。
版本历史
- c3c0a1e 当前 2026-07-23 07:54
