Step 1: AIに「ルール」を渡す
目的に合わせて、読み込ませるファイルを選んでください。
推奨:
これは「VCDesign Core（基本概念）」と「RP（判断基準）」の全てを含んでいます。
（※ これを読み込む場合、
vcdesign_core_with_rp.yamlこれは「VCDesign Core（基本概念）」と「RP（判断基準）」の全てを含んでいます。
（※ これを読み込む場合、
vcdesign_core.yaml を個別に読む必要はありません）
A. 実践的な設計判断を求める場合（推奨）
以下のURLを読み込み、設計ルールの正典として扱ってください。
https://raw.githubusercontent.com/hironobu-arakawa/vcdesign-core/main/vcdesign_core_with_rp.yaml
※ このファイルには VCDesign Core と RP (Resolution Protocol) の両方が含まれています。
読み込んだら「ルールをロードしました」とだけ答えてください。
B. 全体の構造（地図）だけを知りたい場合
以下のURLを読み込んで、VCDesign のライブラリ構造（インデックス）を把握してください。
https://vcdesign.org/library/library.yaml
読み込んだら「構造を理解しました」とだけ答えてください。
C. IDG（ゲート）の実装パターンを知りたい場合
具体的なコード例や実装ルールが必要な場合に適しています。
以下のリポジトリを読み込んで、IDG (Interface Determinability Gate) の実装パターンや定義を把握してください。
https://github.com/hironobu-arakawa/interface-determinability-gate
読み込んだら、要点を3行でまとめてください。
Step 2: 用途に合わせて相談する
構造を理解させたら、具体的な設計レビューを依頼できます。
Pattern A: API設計のレビュー (IDG)
自分の作ったAPI定義が「曖昧で責任放棄していないか」を確認します。
次のAPI設計案を、VCDesign の「IDG (Interface Determinability Gate)」の基準でレビューしてください。
特に以下の観点で厳しくチェックしてください：
1. Ownership: 責任者が曖昧ではないか
2. Explainability: 拒否理由が構造として説明できるか
3. Auditability: 後から追跡可能か
[ここにAPI定義やJSONスキーマを貼り付ける]
Pattern B: ロジックの置き場所相談 (BOA)
「この処理、どこに書けばいい？」を相談します。
あるビジネスロジックの実装場所で迷っています。
BOA (Boundary-Oriented Architecture) の Fact / Meaning / Responsibility
の境界区分に基づいて、どこに配置すべきかアドバイスしてください。
要件：
[ここに実装したい機能やデータの流れを書く]
Pattern C: 価値の継続性を問う (VCD)
「正解」ではなく「どこが風化しやすいか」を問いかけます。
VCDesign の核心（価値を継続する設計）を理解するための質問です。
私が設計しているシステムについて、VCDesign (Value Continuity Design) の観点から「未来のリスク」を指摘してください。
システム概要：
[ここに概要：例「3人で開発している社内向け在庫管理システム」]
質問：
文脈（担当者、組織、技術トレンド）が変化したとき、このシステムの「価値（Value）」と「責任（Responsibility）」が最も失われやすい箇所はどこですか？
それを防ぐために、今どこに境界を置くべきですか？
Step 3: 何が返ってくるか？
VCDesign を理解した AI は、単なるコード修正ではなく「境界の指摘」を返します。
- NG例 「このパラメータはオプションにした方が便利です」
- VCDesign的回答 「このパラメータをオプションにすると『誰が決めるか』が曖昧になり、IDGの Ownership 違反になります。必須にするか、呼び出し元を分離してください」