zukai-creator

name	zukai-creator
description	テキスト・メモ・記事・スライド・説明文から、要素・関係性・グループ・ラベルを抽出し、図解パターンとスタイリングルールを選んでわかりやすい日本語の概念図解を作る。図解・概念図・説明図・スライド用ビジュアル・ビジュアル要約を作るときに使う。定量データのグラフ、本格的なインフォグラフィック制作、画像生成、装飾的なイラストには使わない。

Zukai Creator

手順

Step 1: 図解の役割を定義する

1. 想定する媒体を特定する: スライド、記事の図版、SNS投稿、ホワイトボードのラフ、ドキュメントの図、レビュー用の成果物など。
2. 目的・読者・たった一つの主メッセージを抽出する。これらが欠けている場合は、設計に入る前に簡潔な確認質問を一つだけ投げる。
3. 観察と解釈を分ける。ソースの主張は保ち、プロセス・指標・因果関係を勝手に創作しない。
4. 入力が長い、または曖昧な場合は、図解の前に短いソース要約を作る。

Step 2: ソースを図解の部品に分解する

1. 構造化されたブリーフが役立つ場合は、スキル同梱の assets/diagram-brief-template.json を読む。
2. 要素の候補を抽出する: 人、チーム、製品、概念、状態、ドキュメント、ステップ、入力、出力など。
3. 重要なテキストは、概念的に図形で囲んで要素に変換する。素のテキストラベルは補助的なものとして扱い、要素とはみなさない。
4. 要素間の関係性を抽出する。提案する・変換する・依存する・比較する・含む・分岐する・統合する のような短い動詞を優先する。
5. 要素がフェーズ・カテゴリ・所有者・レイヤー・境界を共有するときはグループを抽出する。
6. 不確かな点は図の中に隠さず、未解決の問いとして列挙する。

Step 3: パターンを選ぶ

1. 図解パターンを選ぶために、スキル同梱の references/pattern-catalog.md を読む。
2. メッセージをパターンに対応づける:
   • 時間・ステップ・プロセス・変化には、シーケンスやタイムラインを使う。
   • 原因・結果・流れ・影響には、矢印・分岐・収束を使う。
   • 分類・構造・構成要素には、階層・包含・表形式を使う。
   • 比較・選択・優先順位には、対比やマトリクス形式を使う。
   • 交換・交渉・相互影響には、双方向のコネクタを使う。
3. 構造が自明でない場合は、少なくとも2つの候補パターンを生成する。
4. 余計な解読なしにメッセージを伝えられる、最もシンプルなパターンを優先する。

Step 4: 低忠実度の図解仕様をラフに描く

1. 仕上げに入る前に、まずラフなテキストレイアウトから始める。シンプルな図形・短いラベル・方向付きコネクタを使う。
2. 描く前に図形の意味づけを決める: 例として、矩形はアクター、円は概念、角丸矩形はプロセスなど。
3. コネクタのラベルは、それが説明する線や矢印の近くに置く。
4. グループ化は主たる方法を一つに絞る: 背景色、囲み枠、余白、区切り線、ブラケットなど。すべての方法を重ねがけしない。
5. 図が密になりすぎたら、複数の図に分割するか、詳細を表へ移す。

Step 5: 理解のためにスタイリングする

1. 仕上げの前に、小さなスタイリングルール一式を定義する: フォントの太さ、塗り色、線の太さ、矢印の種類、強調ルール。
2. 同じ意味には、図全体で同じビジュアル表現を使う。
3. 通常の図では、ブランドルールが要求しない限りフォントの太さは最大2種類にとどめる。
4. 暗い塗りの上の白文字は、コントラストが十分に高い場合だけ使う。白抜き文字には太字のサンセリフを優先する。
5. アイコン・絵文字・ロゴ・イラストは、それらなしで構造が成立してから初めて追加する。
6. 意味的な理由なく見た目の重要度を変えるような、装飾的なスタイリングは避ける。

Step 6: 図解ブリーフを検証する

1. JSONブリーフを作成したときは、スキルディレクトリから python scripts/check-diagram-brief.py path/to/brief.json を実行するか、絶対パスでスクリプトを指定する。
2. 報告された欠落フィールド・無効な要素参照・重複した要素IDをすべて修正する。
3. JSONブリーフを作らない場合は、出力に目的・読者・メッセージ・要素・関係性・採用パターン・スタイリングルールが揃っているか手動で確認する。

Step 7: レビューと改訂

1. 最終納品の前、または別ツールへ図を渡す前に、スキル同梱の references/review-checklist.md を読む。
2. 図が一文で何を語っているかを問うてテストする。その答えが意図したメッセージと違うなら、スタイリングより先に構造を改訂する。
3. 線の向き・グループ化・ラベルが、口頭の説明なしで理解できるか確認する。
4. 図がクライアント向け・教育用・意思決定文書で使われる場合は、外部からのフィードバックを求める。
5. 最終成果物を要求された形式で納品する: テキストの図解仕様、Mermaid、SVG/HTMLの指示、スライド向けガイダンス、デザインツール向けの実装プロンプトなど。

出力フォーマット

ユーザーが特定のファイル形式を要求しない限り、次の構成を使う:

1. 図解の目的: 一文。
2. 主メッセージ: 一文。
3. 抽出した要素: 要素と役割の箇条書き。
4. 関係性: 向きとラベル付きのコネクタの箇条書き。
5. 採用する型: パターン名と理由。
6. ラフ構成: テキストレイアウト、Mermaid、または簡潔な作図指示。
7. スタイリングルール: 図形・色・線・フォント・グループ化の意味づけ。
8. 確認事項: 未解決の問いとレビューチェックリストのメモ。

エラーハンドリング

• ソースの主張が多すぎる場合は、すべてを1枚のキャンバスに詰め込まず、メッセージやフェーズごとに図を分割する。
• 関係性が不明確な場合は、矢印なしの要素マップを作り、不足している関係性の根拠を列挙する。
• 定量的な比較が中心になる場合は、このスキルの使用をやめ、チャートやデータ可視化のワークフローを使う。
• ユーザーが完成イラストや生成画像を求める場合は、まず図解ブリーフを作り、その後に画像生成やWebデザインのワークフローへ引き継ぐ。
• スキル同梱の scripts/check-diagram-brief.py が失敗した場合は、JSONを修正して再実行し、ブリーフが整ったと判断する前にパスさせる。