AILatest-Studio/ailatest-skill

プロセスフローチャート

このスキルは、任意の順序付きプロセス、意思決定フレームワーク、エビデンスチェーン、または実装ワークフローを、明確で出版可能なフローチャートに変換します。提供される参照画像はスタイルリファレンスであり、固定の4カラムテンプレートではありません。コンテンツに応じて段階数と方向を選択します。

ワークフロー

1. 意味論的な契約を定義する

描画前に実際の段階をリストアップします。デフォルトでは2～6段階を使用します。段階は、明確な決定、所有者、入出力、またはエビデンスタイプがある場合にのみ分割します。隣接するボックスに反復的な文言が含まれる場合は、段階を統合します。

読み方向を選択します:

• 2～6のコンパクトな段階とワイドページには水平シーケンスを使用します;
• 長いラベル、多くの段階、または狭い縦長ページには垂直シーケンスを使用します;
• 2つの独立した次元が分析的に必要な場合にのみ、二次元マトリックスを使用します。

メインシーケンスを1行で記述します。例:

入力/観察 → 分析/設計 → 実行/配信 → フィードバック/レビュー

個別のハンドオフやライフサイクルを追加する場合にのみ、オプションの二次実装バンドを追加します。そのラベルを対応するメイン段階に揃えます。メインパネルのテキストを繰り返さないでください。

各段階に対して1つの質問を定義します:

• プロセスを開始するエビデンスや入力は何ですか?
• 次にどのような分析、検証、または分類が行われますか?
• 次にどのようなオプション、アクション、または決定が続きますか?
• 実装、配信、フィードバック、またはレビューはどのように完了しますか?

ユーザーの用語と因果論理を保持します。空のスペースを埋めるために統計、標準、コスト、または因果関係の主張をでっち上げないでください。

2. コンテンツを構造化する

段階ごとに2～4つの短いコンテンツグループを使用します。各グループは以下を持ちます:

1. 短い色付きラベル（太字）;
2. 簡潔な説明行1つ;
3. 別のグループが続く場合、グループの下に薄い破線の区切り線。

ユーザーが明示的にマトリックス、カード、または比較レイアウトを要求しない限り、すべての段階で同じ内部構造を維持します。複数のオプションがあるという理由だけで、1つの段階に追加の内部カードを与えないでください。代わりにテキストの階層と区切り線を使用します。

説明メモは短く控えめに保ちます。定義、サンプル境界、または注意事項は、プライマリラベルではなくメモ行に配置します。図のタイトルとキャプションは、ドキュメントが既に提供している場合は原稿に残します。画像内にそれらを複製しないでください。

3. ビジュアルシステムを適用する

正確なトークンと適応ルールについては、references/style-spec.md を参照してください。参照スタイルは以下を使用します:

• 白背景、等しいステージモジュール、細い灰色の外枠;
• 濃いネイビー → ティール → グリーンのパレット。より多くの段階が必要な場合は、明るい色合いで拡張;
• 段階間の暗い塗りつぶし矢印;
• 段階の意味に合わせて選択された、段階ごとに1つの小さな白いラインアイコン;
• グラデーション、シャドウ、ハッチ塗りつぶし、クリップアートの混在、または装飾ループはなし。

ユーザーがMicrosoft YaHeiを要求する場合は、実際のMicrosoft YaHeiファイルを使用します。通常体と太字のフォントファイルをMatplotlib FontProperties(fname=...) で明示的に登録します。ファミリー名のルックアップやシンセティックボールドに依存しないでください。エクスポートされたSVGでフォントを検証し、別のCJKフォントにサイレントに代替するのではなく、フォントの問題を報告します。

ヘッダー、グループラベル、プライマリ説明、アクションテキスト、ライフサイクルラベルには太字のタイポグラフィを使用します。セカンダリノートには通常体またはミュートテキストのみを使用します。不必要な境界線を追加するのではなく、サイズ、色、空白を通じて階層を表示します。

4. 決定的に描画する

再現可能なMatplotlib/SVGワークフローを優先します。scripts/draw_flowchart_template.py から開始し、orientation と stages を設定し、例のラベルをユーザーのコンテンツに置き換えます。ヘルパーは以下に対して別々に保持します:

• 段階のジオメトリとヘッダーバンド;
• ヘッダーラインアイコン;
• 整列された区切り線;
• 塗りつぶされたポリゴン矢印;
• オプションのライフサイクル/実装バンド;
• マルチフォーマットエクスポート。

4段階水平レイアウトの場合は、references/style-spec.md の参照ジオメトリを使用します。他の段階数の場合は、等しいモジュール幅を計算し、ラベルが収まる場合は同じ外側マージン、ギャップ幅、ヘッダー高さ、およびコンテンツベースラインを使用します。タイポグラフィを縮小する前に、文言を短くします。

少なくとも300 dpiのPNGに加えて、編集可能なSVGとPDFをエクスポートします。テキストを検索可能/編集可能にするために、可能な場合は svg.fonttype = "none" を設定します。スタンドアロンの図を検査した後にのみ、PNGまたはPDFを原稿に埋め込みます。

5. 配信前にQAを実行する

スタンドアロンの図を100%で検査し、次にレンダリングされた原稿ページを検査します。以下のすべてを確認します:

• 選択された段階数と読み方向が明確である;
• ヘッダーが選択されたレイアウト内で一貫したベースラインと高さを共有している;
• テキストグループが割り当てられた領域内で垂直方向に中央揃えされている;
• 破線の区切り線が1つのダッシュパターン、線幅、色、インセット、バランスの取れたギャップを使用している;
• すべての段階が同じ内部カードポリシーを使用している;
• 塗りつぶし矢印がギャップ内に配置され、境界線に触れておらず、意図した方向を指している;
• オプションの下部ラベルが親の段階に揃えられ、十分なサイズである;
• アイコンがストローク幅、色、スケール、および光学的位置合わせを共有している;
• テキストが色付きヘッダー、区切り線、外枠、または出力バーに触れていない;
• 原稿のスケーリング後にラベルの折り返しやクリッピングがない;
• 図番号/キャプションの順序が埋め込み後も変更されていない;
• エクスポートされたSVGに、意図しないフォールバックではなく、Microsoft YaHeiの通常体/太字が含まれている。

DOCX配信の場合は、ドキュメントレンダリングスキルのレンダー → 全ページ検査ループを使用します。ジオメトリまたはフォントを変更するたびに再レンダリングします。元の原稿を保持し、修正したファイルを新しい出力パスに書き込みます。

視覚的な例

同梱の画像 assets/research-evidence-flow.png は、再構築された5段階の研究エビデンスチェーンの例です。これは合成デモンストレーションコンテンツであり、ユーザーが提供した図やプロジェクトデータではありません。

呼び出し例

• 「$draw-process-flowchart を使用して、この研究方法を5段階のジャーナル図に変換してください。」
• 「$draw-process-flowchart を使用して、このワークフローを同じ色、矢印、アイコン、Microsoft YaHeiタイポグラフィで垂直方向に再設計してください。」
• 「$draw-process-flowchart を使用して、この2段階の比較図を標準化し、PNG/SVG/PDFをエクスポートしてください。」