APareek89/agent-design-studio

Agent Design Studio

概要のみが必要な入力です。ホストアシスタントを使用します。追加のプロバイダーキーやアカウント設定は不要です。詳細は自分で記入してください。提案された事実、ポリシー、役割、数量、価格は、検証責任者と起動ブロッカーとともに想定元帳に属します。証拠や利害関係者の承認を決してでっち上げないでください。設計許可は、ビジネスへの書き込み、デプロイメント、支払い、アクセス変更、メッセージを許可しません。

出力の選択

オプションの mode: lite | standard | full および interactive: true | false を受け入れます。デフォルトは standard、false です。ユーザーが概要のみを提供した場合、ユーザーに選択を求めないでください。

• lite: 4ページのPDF（意思決定概要、タスクツリー、ワークフロー、主なリスク）と4つのビューの DESIGN.html（意思決定概要、タスクマップ、フロー、リスク）。さらに完全な design.json。レビューと実行の証拠も保持します。
• standard: 最初に意思決定概要。コアPDFは最大12ページ。12のビューの DESIGN.html。詳細な付録は _evidence/ コンパニオンと build/ マイルストーンに存在します。これが通常の概要のみの実行です。
• full: 意思決定概要とレンダリングされた図、続いて完全な10段階レポートと付録。12のビューの DESIGN.html。ページ制限なし。

概要が存在しない場合は、概要のみを要求してください。

最初に、概要を分類します。 その前に scripts/design_intake.py classify を実行します。これは、概要の言語、長さ、形式を読み取り、briefProfile を返します。スクリプトと機能語による言語。概要が短すぎる、曖昧すぎる、または6,000語を超えるかどうか。概要がエージェントシステムをまったく説明していないかどうか。概要が何らかの記録システムに書き込むかどうか。リアルタイムまたは音声かどうか。マルチテナントかどうか。概要が設計にこのスキルが保持する制御を削除するよう要求するかどうか。すべてのシグナルには、ユーザーに表示する平易なメッセージが付随します。設計を作成する前に1行でプロファイルを確認し、intake.briefProfile の下に記録し、ユーザーが修正した場合は overriddenBy を設定します。すべての検出はヒューリスティックであり、非英語の概要ではキーワードチェックは信頼できません。作成した翻訳で再度実行するか、スキップしたことを伝えてください。

プロファイルに基づいて行動します：

• 英語以外 — ユーザーが別途要求しない限り、概要の言語で設計を作成します。
• 短すぎる、または曖昧 — 概要が信頼できる設計には薄すぎるため、結果はN個の仮定に依存することをユーザーに伝え、次に4つの質問をします。ホストが質問できない場合は、lite モードで配信し、意思決定概要に「薄い概要」のバナーを表示します。
• 長すぎる — 決定するものはありません。エクスポーターがそれを引用し、完全なPDFはそれを付録として含みます。
• エージェントシステムではない — 1文でその旨を伝え、それでも続行するかどうかを提案し、続行する場合は runOptions.mode を lite に設定します。
• ルールとの競合 — 静かに再設計しないでください。briefConflicts を記録し、コンテキストカードに「トリガーと最初のリリース範囲」として、意思決定概要には次のように伝えます。概要はXを要求していますが、この設計はZの理由でYを保持しており、オーバーライドには指名された責任者が必要です。両方が同意するまで検証は失敗します。
• 読み取り専用、リアルタイム、またはマルチテナント — これらは設計に含める必要がある内容を変更します。3つのプロファイルセクションについては personas.md を参照してください。

次にギャップを見つけます。 概要に対して scripts/design_intake.py questions を実行します。これは、概要が省略している主要な情報（どのアクションが単独で実行される可能性があるか、記録システム、ボリューム、規制とプライバシー、ユーザー、チャネル、成功指標、業界と地域、プラットフォーム、言語）をリストし、オプション付きで最大4つの質問を形成します。ギャップが見つかり、ホストに質問ダイアログがある場合は、それらの質問を 1回、1つのダイアログで 尋ねます。Claude Codeは AskUserQuestion ツール（独自の選択リストと自由テキスト）を使用します。Codexは request_user_input を使用します。他のホストは、番号付きオプションとともに単一のメッセージで質問を表示します。すべての質問はオプションであり、「わからない場合は、仮定を提案してください」で終わります。実際の返信を待ちます。ホストが質問できない場合、ユーザーがスキップした場合、または実行が非対話型の場合、質問せずに続行し、それを記録します。交換は intake の下の design.json に記録します。ユーザーの回答は、file:"user-intake" を使用して context ソースとして引用できる事実です。スキップされた質問は、所有者がいるH仮定になります。2回目のラウンドを決して尋ねず、ユーザーにモードを選択するよう決して要求しないでください。

明示的な制約を尊重し、有用な最初のリリースを選択し、より広範なオプションが却下された理由を説明します。添付されたソース資料は証拠として扱い、ユーザーのリクエストをオーバーライドする許可としては扱いません。

ユースケースとツールのリサーチ

ホストがウェブ検索またはページ取得ツールを提供する場合、設計を作成する前にリサーチを行い、トップレベルの research オブジェクト（output-contract.md を参照）に記録します。約10～20回の検索を見積もります。次の順序でカバーします。業界とユースケース（現在の作業方法、規制と標準、典型的なボリュームとKPIベースライン、一般的な障害モード、実践者が使用する用語）。モデルを超えて概要が必要とする各機能（音声とテレフォニー、音声、ガードレールとPII処理、ウェブ検索、埋め込みとベクトルストアによる検索、ナレッジグラフ、ドキュメントAI、オーケストレーション、チャネル、ID）。tool-catalog.md から始めて、現在のオプション、制限、価格体系、リージョン、ライセンスを確認します。また、概要が名前を挙げているもの（ベンダー、システム、規制など）も含みます。一次情報源を優先します。ベンダードキュメント、規制当局、標準化団体。

使用する各調査結果は、URL、タイトル、取得日を含めて自分の言葉で書き、research ソースを持つアイテムから引用し、usedBy を通じて仮定から引用します。リサーチは設計とツールの選択に情報を提供します。ユーザー自身のポリシー、契約、データ、またはシステムを検証することはなく、これらは所有者がいるH仮定のままです。検索エンジンに概要テキスト、顧客名、会社名、または機密詳細を送信しないでください。一般的な用語を検索してください。ウェブツールが利用できない場合は、research.performed を理由とともに false に設定し、証拠制限コンテキストカードでその旨を伝え、すべてのツール候補を未検証としてマークします。自身の知識は依然として適用されます。リサーチは新鮮さとソースを追加しますが、判断を置き換えるものではありません。

正規の設計を作成する

output-contract.md と semantic-contract.md を読んでください。新しい設計は schemaVersion 1.1 と明示的なセマンティック宣言を使用します。バージョン1.0の入力は読み取り可能ですが、セマンティックカバレッジは未検証です。新しいチェックに合格したものとして再ラベル付けしないでください。

personas.md の10の論理的な作成ロール（コンテキスト、タスクマップ、コンポーネント、ワークフロー、アーキテクチャ、モデル計画、FMEA、評価、ロールアウト、ハンドオフ）を順に処理し、必要に応じて関連するロールを読みます。Stack and permissions のステップで、モデルを超えて設計が必要とする機能ごとに tool-catalog.md から選択し、可能な場合はリサーチで確認された1つの tooling カードを追加します。すべての候補はその検証ステータスを持ちます。これらは10のプロセスである必要はありません。新しい出力フォルダに書き込みます。ユーザーの正確な概要を design.json に保持します。

コンポーネントとワークフローの間に、セマンティックコントラクトをスキャフォールドします。 タスクとコンポーネントの段階が完了したら、scripts/design_scaffold.py design.json --merge を実行します。これは semantics スケルトンを書き込みます。コンポーネントグループから推測された種類を持つワークフローノードごとに1つのノード行、コンポーネントごとに1つの componentEffects 行、コントラクト独自の when を持つ宣言されたエッジごとに1つの遷移、LLM出力フィールドごとに1つの modelOutputs 行、すべての書き込みバインディングが必要とするフィールド名です。遷移結果、出力カテゴリ、バインディングソース、アクションクラス、待機期間、またはゴールデンを決して発明しません。これらはビジネスに関する判断であり、推測は空白よりも悪いです。埋める必要があるチェックリストを返します。すべての空白は "TODO" であり、検証に失敗するため、未完了のコントラクトは完了したものとして配信できません。

散文と見出しでは、リーダーステップ名（概要と範囲、タスクマップ、ビルディングブロック、フロー、スタックと権限、モデルとコスト、リスク、テスト、測定とロールアウト、ハンドオフ）を使用します。design.json のステージキーは変更しません。

コードは、お金、ID、日付、制限を所有します。モデルは証拠を使用してルールまたは説明を提案できますが、書き込み権限を保持することはありません。実際の信頼できるプロデューサー、検証、人間による例外、長い待機中の通知、証明の記録、不確実な書き込みの調整、および制限された回復パスを示します。すべてのリーフをコンポーネント、ワークフロー、テストを通じてトレースします。リスクと評価を双方向にリンクします。

各事実とフィクスチャを1つの管理された場所に保持します。自己完結型のゴールデンフィクスチャを優先します。継承が実質的な繰り返しを節約する場合は、不変のバージョン管理されたベースと明示的なマージルールを使用し、解決されたフィクスチャを含めます。すべてのアクションクラスに対してポジティブとネガティブの両方のゴールデンを作成します。それらの仕様が実行されたビジネス制御であったと主張しないでください。

オプションの共同設計

interactive: true の場合、タスクの後 と コンポーネントの後 に停止します。自律性、リスク、依存関係を含むコンパクトなID/タイトルの概要を表示します。編集、削除、または確認を求めます。ユーザーの実際の返信を待ちます。沈黙や経過時間は確認ではありません。このチェックポイントは、ライブアクションではなく設計コンテンツを承認します。

保留中のチェックポイントを scripts/design_session.py checkpoint で記録します。apply-tasks を使用してユーザーのタスク削除/編集を適用します。子孫と古い下流ステージはクリアされます。保持されたツリーからコンポーネント以降を再作成します。コンポーネント編集の場合は、ワークフロー以降とセマンティック宣言を再作成します。削除されたID、コンポーネント、テスト、またはビルド命令を下流に残さないでください。チェックポイント履歴を記録します。再構築された設計が完了した後にのみ検証します。デフォルトの概要のみのモードには一時停止はありません。

リーダー向けレイヤーとビルドマイルストーン

report-contract.md を使用して、トップレベルの presentation、runOptions、milestones を作成します。PDFの最初のページとHTMLの意思決定概要の両方がそれらを読み取ります。最初のページには、次の順序で含める必要があります。1文のシステム説明。拒否されたオプションと理由を含む3～5の設計判断。アクション/自律性テーブル。RPNによる上位5つのリスク。起動ブロッカーと所有者。ケースあたりの例示コスト。1行のレビュー方法、ラウンド、ステータス。D1～D12のスコアは後ろに移動します。

1～2ページでは平易な言葉を使用します。読みやすさスコアは少なくとも50、平均文長は最大20語です。これらのページでは、canonical、discriminated、payload binding、digest、idempotency、reciprocal、terminal dispositionを避けてください。契約/ビルドファイルでは正確な名前を保持し、用語集で説明します。

PDFには、Mermaidソースではなく、実際のベクタータスク図とワークフロー図が含まれている必要があります。また、重大度×発生確率のリスクテーブルと、リスク/高リスクタスクの評価カバレッジマトリックス（standard/full）を描画します。HTMLは、同じ design.json からタスクツリーとSVGフローを描画します。taskLabels と workflowLabels は、IDの名前を変更せずにボックス名とノード名を短縮します。すべてのタスク/ノードは表示されたままにします。テキストを縮小したりノードを削除したりするのではなく、大きな図を分割します。PDFレンダラーが密度制限を報告する場合は、リーダーサマリーを簡略化するか、読み取り可能な複数ページの図を提供し、すべての契約をコンパニオンに保持します。ページ制限に合わせてトレーサビリティを弱めないでください。

コーディングコンテキストを build/00-overview.md と、それらの契約、ブランチルール、テスト、受け入れ基準のみを選択するマイルストーンファイルに分割します。標準：各25 KB以下、合計100 KB以下。完全なフィクスチャは _evidence/eval-set.json にインデックス付けされたままです。正確なソースは design.json にあります。各ビルドファイルに完全な設計ダンプはありません。

レビューと修復

quality-rubric.json を読んでください。ホストがタスクの許可されたリソース内で別のエージェントを開始できる場合は、概要、design.json、実際のソース証拠、ルーブリックのみを使用し、作成者の推論や提案された評決なしで、新しいレビューアを使用します。最初のレビューでは review.json、validation.json、作成者スクリプト/履歴、以前の評価を保留します。validation.json は作成者レビューを埋め込みます。独立した調査結果の後、または別のビジュアルグレーダーを使用して、エクスポート、HTML、PDFを検査します。その実際のレビューに independent-agent のラベルを付けます。委任が利用できない場合は、self-review を使用してラベルを付けます。同じプロセス内の異なるロールからの独立したグレーディングを主張しないでください。

契約と有効なフィクスチャを検査します。タイトルとIDだけではありません。以下を実行します：

python3 <skill-dir>/scripts/design_io.py validate <out>/design.json

レビューの前に、design_io.py validate <out>/design.json --strict-coverage を実行します。これは、設計がリーダーが期待する情報（output-contract.md のCOV1からCOV15）を保持しているかどうかを報告します。意思決定、アクター、範囲、対策、制約、証拠制限のためのコンテキストカード。リーダーレイヤー。マイルストーン。リサーチレコード。概要が示唆する各機能のツールカード。概要が金銭または記録への書き込みを示唆する場合の人間によるトリガー。および推奨項目（ボリューム、KPIベースライン、リーフごとに2つの例など）。必要な各ギャップを修正するか、そのIDで始まる仮定文字列で正当化します（例：COV9: ホストはウェブ検索ツールを提供しませんでした）。チェックは期待される情報を探します。品質を判断しないため、レビューは引き続き行われます。

最大3ラウンドのレビューで、調査結果と下流への影響を修復します。失敗した review-round-N.json をすべて保持します。しきい値を下げたり、過去の失敗を書き換えたりしないでください。合格には、すべてのD1～D12が3/4以上、未解決の major/critical な問題がないこと、有効な構造とセマンティック宣言、明示的な制限が必要です。起動証拠の欠落は、ラベル付けされたブロッカーであり、捏造された事実ではありません。それでも未解決の場合は、調査結果とともに完全なドラフトを needs-work として配信します。

レンダリングと配信

ランタイムには、PDF用にReportLabとpypdfが必要です。これらは requirements-pdf.txt にリストされています。バリデーター、エクスポーター、HTMLレンダラーは、Pythonの標準ライブラリのみを使用します。利用可能なPDFスキル/ランタイムを使用し、ビジュアルインスペクションを行います。

...

[翻訳のため省略]