agently-design

Agently Design

オーナーをまたぐ設計と監査には、この Skill を使用します。オーナーシップと引き継ぎの契約を作成しますが、スケジューラー、TriggerFlow の定義、TaskDAG、再試行エンジン、RuntimeEvent プロトコルにはなりません。

反復的な設計やレビューでは、現在の項目と、タイムスタンプ付きのバージョン管理された変更ログを回答の冒頭に示し、決定事項と適用済み・検証済みの変更を区別します。 複数ラウンドのコラボレーションを読んでください。

プロジェクトの段階と範囲

利用可能なアセットと証拠から、タスクが新規設計、部分的な実装、本番環境のレビューのいずれに該当するかを推定します。その判断の根拠を簡潔に説明し、該当する質問と成果物についてプロジェクトの段階を読んでください。設計を大きく左右する不足情報だけを尋ねます。ビジネス目標、制約、必要十分な最もシンプルな解決策から始め、正確なクエリや決定的なプログラムで対応できる場合にモデルを導入しないでください。ただし、これは意味的な判断をキーワードルールで置き換えることを許可するものではありません。

モデル、SDK、フレームワークがすでに選定されていると仮定しないでください。スタックが未選定の場合や、明示的に別のスタックが指定されている場合は、まず中立的な役割で契約を表現し、そのスタックに従います。Agently が対象範囲に含まれる場合に限り、Agently のオーナー／API マッピングを適用します。この設計レビューだけでは、フレームワークの移行は許可されません。製品やプロジェクトの形が未解決の場合は、引き続き agently が担当します。オーナーをまたぐ設計はここで扱い、単一リクエストやランタイムに関する解決済みの問題は、既存の担当メカニズムに委ねます。

コアワークフロー

1. ビジネス上の決定事項と完了時の不変条件を示します。
2. 各決定を、モデルが担う意味的な作業、ホストが担う決定的な作業、またはハイブリッドな列挙型／キーの決定に分類します。
3. すべての決定、状態、効果、待機を、既存のオーナーに割り当てます。
4. API を選ぶ前に、リクエスト時の値の依存関係と実行時のイベント依存関係を図示します。
5. 後続フィールドがディスパッチ後に作成される観測結果を必要としない場合に限り、順序付けられたフィールドを 1 つの ModelRequest にまとめます。後続のモデル判断に必要な Actions、システムアクセス、承認、アーティファクトの読み戻し、ホスト側の計算の後は、分割します。
6. 各プロンプト／出力フィールドを、許可された利用者に基づいて導き出し、その型、制約、可視性、保持期間、障害時の動作を宣言します。
7. 実装の前に、証拠、正準 ID の結合、ライフサイクル、収束、負荷、観測性を設計します。
8. 監査では、観測されたトポロジーを再構築し、最終出力から根本原因を推測するのではなく、最初に逸脱したノードまたはエッジを特定します。可観測性と検証にある順序付き診断ゲートに従います。実行の到達可能性、実行ロジック、実際のモデル入力、制約付き Prompt 実験、調整が失敗した場合の許可された上位モデルとの比較、の順です。DevTools の証拠やレビュアーのコメントが利用できる場合は、レビューワークフローを通じて確認し、元の証拠を検証して、再実行の結果を元のレビューに返します。
9. 具体的な実装を、担当メカニズムを所有する Skill に引き渡します。

必須トポロジ契約

実験レポートや設計ドキュメントでは、タスク指示が英語でない場合、その指示言語で完全なドキュメントを作成することを優先します。バイリンガル版も許容されます。明示的に要求された出力言語が優先されます。これはチャットの要約だけでなく、ドキュメント自体に適用してください。コード、識別子、生のプロンプト、および証拠は必要に応じて保持してください。それらの言語は、周囲のレポートの言語を決定しません。

モデルノードの定義、実行効果、データの完全性/冗長性、またはモデル/Host の作業分担について開発者の質問に答えられる場合は、協調レビューを使用してください。「Prompt review」というフレーズを必須にしてはいけません。まずスコープ内のフロー全体を示し、モデルノード、その責務、および入出力のハンドオフを Host の作業と並べて強調してください。質問から証拠へのチェックについては references/model-request-topology.md を読んでください。別の台帳ではなく、既存のトポロジを使用してください。図だけでは実行時の正確性や品質を証明できません。比較のために関連するノードテーブルを ../agently-request/references/prompt-management.md の下にグループ化してください。最大 3 つの論理ノードが 1 つの返信を共有でき、密結合されたより大きなグループも許可されます。明確なスコープは、その詳細と同じ返信内に示すことができます。重要な変更の確認を保持し、改訂後は影響を受ける責務/ハンドオフのみを再検討してください。

自明でない線形、分岐、並行、またはループするアプリケーションには、すべて次が必要です:

• オーナー/不変条件の台帳。
• 各 ModelRequest または host ステージとその境界理由を含む、計画されたノード台帳。
• 正確なプロデューサー、検証、およびコンシューマーを含む、値/イベントエッジの台帳。
• 要求されたすべてのノード、フィールド、および成果物に対する生産必要性の台帳。

独立したコンシューマー、並行開発、リプレイ、ローカル検証、または障害の局所化を可能にする場合にのみ、ハンドオフでプロジェクト定義の小さな参照データを使用してください。シミュレートされたデータを正直にマークし、実際のプロデューサー出力がそれを置き換えられることを証明してください。普遍的なハンドオフパケットを発明してはいけません。

非終端のモデル結果は、ステージスコープの貢献として扱ってください。それはローカル契約を満たし、観測可能な進捗を生み出す必要がありますが、タスク全体の完了を主張する必要はありません。不明または延期された作業は明示的に残します。終端結果と不可逆的な効果には、依然として完全な受け入れが必要です。

設計上の質問別に読む

• オーナーマトリクス、プロジェクト層、用語、状態/ストレージ、および安定したフロー対提出された DAG: references/system-boundaries.md。
• モデルノードの定義、効果のチューニング、データフローの正確性/冗長性、フロー優先レビュー、プロンプト/出力契約、同一レスポンス消費、ファンアウト、結合、および instant: references/model-request-topology.md。
• 計画対観測の完全な値/シグナル監査: references/execution-topology-validation.md。
• TaskContext パッケージ、TaskWorkspace/RecordStore の証拠、信頼された選択キー、refs、引用、スナップショット、およびフェイルクローズド結合: references/information-and-evidence-design.md。
• 並行性、リトライ、修復、再計画、承認、一時停止/再開、キャンセル、クローズ、プレッシャー、および計画された長文セクション生成: references/lifecycle-and-pressure-design.md。
• RuntimeEvents、リネージ、リクエストテレメトリ、モデル品質レビュー、および実験比較: references/observability-and-validation.md。

オーナーシップが明確になった後:

• 1 つのリクエストファミリーは agently-request にルーティングされます。
• AgentExecution プラグイン/最終ポリシー、Action、MCP、ExecutionResource、TaskWorkspace、RecordStore、サービス、またはテレメトリの仕組みは agently-runtime にルーティングされます。
• 開発者所有の実行可能なオーケストレーションは agently-triggerflow にルーティングされます。
• 明示的に提出された TaskDAG データは、スタンドアロンのデフォルト Skill ではなく、低頻度の agently 上級リファレンスとして残ります。
• ソースフレームワークのマッピングは agently-migration にルーティングされます。

譲れない境界

• モデルの関与だけでは、別のリクエストを正当化できません。分割するのは、実際の 意思決定、エビデンス、コンシューマー、認可、リトライ、ライフサイクル、または 並列性の境界がある場合だけにしてください。
• ModelRequest はディスパッチ時のスナップショットです。暫定的な instant 出力は UI を更新したり、キャンセル可能／冪等な準備を開始したりできますが、その準備の 結果を実行中のリクエストに注入することはできません。
• モデルには、ホストが発行する選択キーを 1 つと、関連するファクトを渡してください。ホストコードが提示されたキーを検証し、正規の id とメタデータを再構築します。
• 選択がキャッシュ、キュー、リトライ、永続化、またはリプレイをまたぐ可能性がある場合は、ホストが所有するセマンティックリクエストの系統に結び付け、参照前に鮮度を検証してください。
• モデルが満たすことができるすべてのビジネスルールは、最初の試行の前にプロデューサーへ到達させてください。意図的に隠されたセキュリティまたは整合性のゲートはホストが所有したままとし、明示的な失敗／終端ポリシーが必要です。
• 隠された思考の連鎖を要求しないでください。明示的なコンシューマーと保持契約を持つ、境界付けられたタスク固有のプロセスフィールドのみを保持してください。

完了ゲート

実装前に、すべての不変条件に 1 つのオーナーがあること、すべてのリクエスト境界に理由があること、すべての出力フィールドに認可されたコンシューマーがあること、すべての暫定パスに無効化の振る舞いがあること、すべてのループに進捗と終端のルールがあること、すべての境界をまたぐアイデンティティに鮮度／相関があること、すべての検証ルールに宣言されたプロデューサーまたは意図的に隠されたホストゲートがあることを確認してください。

セマンティックルーティング、関連性、計画、または品質判断を、キーワード、正規表現、トークン化、またはローカルスコアテーブルで置き換えないでください。TriggerFlow または TaskDAG の傍らに並列の実行トポロジーを追加しないでください。