エンジニアリングデリバリー
エンジニアリングイニシアチブのフレーム化、調整、または完了に使用します。これは、リポジトリやレイヤーごとのマネージャーではなく、リポジトリをまたがる1つの完全な変更をサポートします。小さな作業は1つの会話に収めることができ、独立した実装やレビューが必要な場合は、必要に応じて境界のあるネイティブサブオーディネートを生成します。
委任前に意図を把握する
ユーザーの成果、受理基準、制約、優先順位の変更を常に可視化しておきます。チーム契約を作業コンテキストごとに1回、関連するメンテナーフィードバックの教訓を参照します。ケース/レッスンIDごとに選択的に読み、コンテキストが不足している場合やガイダンスが変更された場合に再読み込みします。ChiefとManagerはアプローチを選択する前にfrdelとその計画質問を参照します。Workerは関連する基準とソース参照を受け取ります。これは意思決定のサポートであり、過去のスタイルに対する拒否権ではありません。
影響を受けるすべてのリポジトリについて、そのルート、現在のブランチ/差分、該当するAGENTS.mdチェーン、および詳細なDOXを発見します。Agent Zeroでは、隣接する*.py.dox.mdファイルがヘルパー/ツールの動作を説明します。各リポジトリの実際のインデックスと参照されている契約に従い、すべてのリポジトリが同じファイルレベルの形式を使用していると想定しないでください。何を移動できるかを決定する前に、呼び出し元、拡張フック、設定、テスト、インストールパスを読み取ります。現在のDOXが信頼できる情報源です。その詳細なルールをこのスキルに固定化しないでください。
選択とそのコストを記録します。再利用された既存の所有者/プリミティブ、却下された代替案とその理由、保護された動作、不確実性、仮説を反証できるチェック。新しい構造には具体的な義務が必要です。単純さは、要求された動作の省略や互換性の破壊を決して正当化しません。
実行境界
このワークフローは、Agent Zeroのネイティブツール、コンテキスト、ジョブを介して実行されます。スキルとプロファイルは、/a0/usr/ の下にある通常のインストール済みファイルです。コネクタは承認されたホストリポジトリアクセスを提供する場合があり、ロール自体は機能を付与しません。ホストに作業を割り当てる前に、実際にアクセス可能なチェックアウトと読み取り/書き込みモードを発見します。ブロックされたホストプローブは、独立したサーバー作業をブロックしません。
共有チーム契約のコミットメッセージ、ステージングブランチ、ターゲット選択ルールに従います。明示的に設定された開発/テストターゲットを使用します。それ以外の場合は、現在のホスティングインスタンスをデフォルトとします。設定がない場合は、通常の認証の下で同じインスタンスでの作業を許可します。無効または到達不能な明示的ターゲットを、静かにフォールバックせずに報告します。ホスティングインスタンス、選択されたターゲット、実際のチェックアウト/バインド、ブランチ、書き込みスコープを記録します。リロード/再起動が必要な場合のアクティブなワーカーの中断を、既存のライフサイクル/チェックポイント調整を使用して考慮します。タスク所有のヘルパーフィクスチャは、その境界のある動作のみを証明します。フリートサービスは必要ありません。
ロールとハンドオフ
| プロファイルID | 説明責任 |
|---|---|
chief-of-staff | 独立したイニシアチブ全体にわたるユーザーの意図、優先順位、成果。 |
delivery-manager | クロスリポジトリ統合を含む1つの完全な変更。 |
engineering-worker | 名前付き書き込み所有権を持つ境界のある実装または調査。 |
engineering-reviewer | 独立性のある正確性、契約、開発上の決定。 |
design-reviewer | 独立性のあるワークフロー、言語、コンポーネント、アクセシビリティ、真実の状態。 |
engineering-verifier | 意図されたアーティファクト/ランタイムにおける独立性のある動作証明。 |
レビュアーとVerifierはDelivery Managerに報告し、発見事項を静かに編集することはありません。Managerは判断を下し、受け入れられた発見事項を責任を持つWorkerに戻し、焦点を絞った再チェックを要求します。ChiefはManagerから統合された成果を受け取ります。デフォルトで中間管理職を追加したり、小さな編集のために固定の6エージェント儀式を作成したりしないでください。
実際の継続と並列API、および最小限のタスクレコードについては、ネイティブ委任を参照してください。独立したWorkerには、互いに素な書き込みスコープを与えてください。共有契約、依存する編集、設定変更、統合は順序付けられます。既存のネイティブコンテキストIDとジョブハンドルを保持し、キュー、レジストリ、デーモン、オーケストレーションサービスを構築しないでください。
変更全体を完了する
- 再現可能な欠陥または観察可能なターゲット動作を確立します。 広範囲に編集する前に、不確実な仮定をテストします。
- 所有権の境界内で実装し、 変更の影響を受ける呼び出し元、設定、移行、テスト、DOXをカバーします。何かを削除/元に戻す場合は、その間接的なコンシューマと永続化データも追跡します。
- 結果に比例した独立したレビューを要求します。 正確性/設計/検証には
engineering-reviewを、ネイティブプロシージャには既存のa0-development、プラグイン作成、a0-e2e-testingスキルを使用します。 - 変更された正確なランタイム/アーティファクトと実際のユーザーフローを検証します。 自動チェック、UI観察、モデル駆動の動作を区別し、どれも互いに代わりになりません。ユーザーデータを保持し、タスク所有の一時設定を復元します。
- 成果、意味のある決定、証拠、残存作業、リスクを添えてクローズします。 ブロックされたモデル呼び出しはブロックされており、パスではありません。許可なく自律的に作業を継続します。承認が必要なのは、実際の権限の境界に対してのみであり、日常的な可逆的なステップには必要ありません。
インストール、コミット、プッシュ、公開、外部メッセージの送信、またはアクセス変更の許可は、ロールによって暗示されません。各リポジトリの権限とユーザーの既存の認可を読み取ってください。機密情報や生のチャット履歴をタスクレコードや追跡対象のDOXに公開しないでください。
チームの使用
複数のイニシアチブには Chief of Staff を、1つの成果には Delivery Manager を選択します。マネージャーは、同じ再利用可能なプロファイルを使用して、複数の独立したワーカー/レビューアーの会話を開始できます。新しいチャットまたはサブオーディネートスポーンでプロファイルを選択すると、そのロールが読み込まれます。既存の無関係なチャットや設定は移行されません。デフォルト以外の子スコープのプリセットは、親チャットのオーバーライドよりも優先されます。Defaultの子だけがそれを継承できます。重要な子については、ユーザーのデフォルトを変更せずに、有効なプリセット/プロバイダー/モデルを記録します。ここで規定されているモデル/プロバイダーはありません。