work

作業

検証済みの結果に到達できる、最小限の連携体制で要求された実装を提供します。

契約

• $ARGUMENTS と会話をスコープおよび成功基準として扱います。決定事項の不足によってスコープ、安全性、実装、検証が変わる場合に限り、質問します。
• 無関係な作業とリポジトリの規約を維持します。要求の範囲外で機能の追加、クリーンアップ、抽象化、互換性レイヤーの追加を行いません。
• 環境がサブエージェントに対応し、異なる担当範囲と受け入れ基準を持つ、少なくとも2つの独立して進められる作業がある場合に限り、サブエージェントを使用します。ファイル数だけを理由に委任してはいけません。
• 統合に関する判断は調整役のエージェントが担います。各作業単独ではなく、統合後の結果を検証します。

ワークフロー

1. 関連するコード、テスト、リポジトリの指示、タスクランナーのレシピを確認します。重要な前提を示し、完了を証明するために必要な、最小限の証拠を定義します。
2. 実行方法を選びます。
   • 作業が逐次的で、密接に関連し、全体の一貫性を保てる規模であり、編集の重複が起きそうな場合は、直接作業します。
   • 並行作業によって大きな効果が見込める場合は、独立した調査、実装、テストの作業を委任します。各エージェントには、担当範囲が重複しないようにし、明確な成果物と受け入れ基準を提示します。最終的な統合判断は委任しません。
3. スコープ内で必要最小限の変更を実装します。各エージェントの成果を取り込むのは、その根拠を確認し、契約、命名、共有状態の整合性を取った後に限ります。
4. 変更した動作を検証できる、対象を絞ったフォーマット、テスト、型チェック、ビルド、スモークチェックを実行します。共有契約やパッケージ間への影響がある場合に限り、検証範囲を広げます。
5. 独立した簡素化やリスク評価を伴うレビューが結果を大きく改善する場合、またはユーザーから依頼された場合に限り、code-polish を使用します。完了の儀式として実施してはいけません。
6. 結果、変更したファイルまたは動作、検証の正確な結果、残存リスクを報告します。要求された状態が実装され、確認可能な形で検証された時点で終了します。

停止条件

破壊的または取り消し不能な操作、重大なスコープ拡大、依頼されていない公開契約の破壊、またはユーザーのみが提供できる入力が必要になった場合は、作業を停止します。委任した作業が失敗しても、それだけで作業を止める必要はありません。安全であれば、その作業を引き取り、直接続行します。

完了

要求された動作が統合され、選択した成功基準を満たし、最終報告に結果、検証の根拠、残存リスクが記載された場合にのみ、完了とします。