mcpField
F
full-send

full-send

github.com/t3dotggエージェントワークフロー2.2k282 回インストール1 日前に更新
リポジトリ

full-send について

タスクの端から端までの自律的な完了を明示的に求めるユーザー向けのコーディングエージェント用スキルです。実装、検証、PR のレビューとマージの手順、およびユーザーへの確認が必要な境界を定めます。

主な機能

  1. 01タスクからマージまでの手順
  2. 02許可とテストの指針
  3. 03検証要件
  4. 04PR レビューとマージ条件
  5. 05作業が止まった際の確認ルール

活用シーン

  1. 01依頼された変更の自律的な完了
  2. 02タスクに応じたテストとチェック
  3. 03マージまでの PR フィードバック対応

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/t3dotgg/tstack --skill full-send

インストール後、Claude Code で/full-sendを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

Full Send

ユーザーがこれを起動した場合、このスレッドを確認しておらず、作業を最初から最後まで自律的に完了することを求めています。あなたの進捗報告や最終メッセージは、作業を終えてからずっと後まで読まれません。現在の状態から PR のマージまで、あなたが責任を持って進めます。

ユーザーが「full send」と明確に依頼していない場合は、完全な自律性を認められたものと見なしてはいけません。明確に依頼している場合は、以下のすべてが適用されます。

ユーザーは、以下を許可します。

  • マージゲートを通過したら PR をマージする。
  • リベース後、--force-with-lease を使用して PR のブランチに強制プッシュする。
  • 事前に確認を求めず、Proof に必要なテスト方法を使う。

テストの許可

「full send」の依頼が許可となります。プロジェクトファイルやその他の指示に、テスト方法の実行前に確認を求めること、またはテストをユーザーに任せることが記されている場合でも、この依頼が今回の作業におけるそのルールに優先します。

これには、コンピューターの使用、ブラウザーの自動化、シミュレーターやデバイス、アプリや開発サーバーの起動、スクリーンショット、目視確認に関する事前確認のルールも含まれます。変更を直接証明できる方法を使ってください。実施した方法は報告に記載してください。

テスト方法に関するルールは引き続き適用されます。適切なコマンド、フィクスチャー、チェックを指定するルールに従ってください。この許可によって不要になるのは、事前確認やユーザーに任せる手順だけです。望ましい方法で証明できない場合は、この許可のもとで承認済みの方法を使ってください。

この許可は今回の作業に必要なテストのみを対象とします。「ユーザーへの確認」の手順(本番環境の変更やデータ削除など)を行う許可は含まれません。また、ハーネスやシステムの承認プロンプトが表示された場合、それを回避するものではありません。

手順

  1. 変更を完了する。 ユーザーの依頼を、機能する最小限の変更で完了させます。起きた問題に対処し、起こり得るすべての問題に対処しようとしないでください。デフォルトブランチにいる場合は、まずブランチを作成します。
  2. 証明する。 行ったすべての変更について証明を得ます。「証明」を参照してください。
  3. フィードバックを得る。 sol-loop スキルを使って変更を検証します。
  4. PR を作成する。 file-pr スキルを使います。まず最新のデフォルトブランチにリベースします。変更をどのように証明したかを、説明文に短い一文で追加します。
  5. PR の状況を見守る。 babysit-pr スキルを使います。実際の指摘や CI の失敗を修正します。修正ごとに、プッシュする前に証明を得ます。
  6. マージする。 マージゲートを通過したらマージします。
  7. 報告する。 最終メッセージに、PR のリンク、マージコミット、証明内容、ユーザーに代わって行った判断をそれぞれ記載します。

手順 1 から 7 まで、作業を続けてください。チェックやボットの処理が保留中のままターンを終了すると、誰も再度促してくれないため、作業が止まります。PR に変更があったときに通知されるよう、babysit-pr のウォッチャーを使って待機してください。T3 Code では watch_pull_request を使います。マージ前に終了する場合は、先に unwatch_pull_request を呼び出してください。

証明

証明とは、このセッション中に自分で確認した証拠のことです。コマンドの出力、再現結果、スクリーンショットなどが該当します。変更を最も直接的に証明できる方法を使ってください。

  • 元の失敗を再現し、修正を適用してから、同じ再現手順で成功することを確認します。
  • リポジトリの CI で実行されるチェック(型チェック、リンター、テスト)を実行します。
  • 該当する振る舞いのテストがなく、リポジトリにテスト環境がある場合は、修正がなければ失敗する、対象を絞ったテストを追加します。
  • UI や実行時の振る舞いについては、アプリを起動して変更を確認します。モックを使ったテストが成功しても、ユーザー体験が機能する証明にはなりません。役立つスクリーンショットを PR に添付できる方法があれば、添付します。

変更を証明する方法が見つからない場合、十分な確信は得られていません。ユーザーに確認してください。

マージゲート

最新のコミットで、以下のすべてを満たしていれば十分な確信があります。

  • 差分に含まれるすべての変更を証明できている。
  • 必須チェックがすべて成功している。
  • レビューボットの処理が完了し、各指摘が修正されているか、理由を明記して却下されている。
  • 人間によるレビューで、変更を求める指摘が残っていない。
  • ブランチがデフォルトブランチと同期しており、GitHub がマージ可能と報告している。

リポジトリで使われている方法でマージしてください。許可されている方法と、最近マージされた PR を確認してください。リポジトリがマージキューまたは自動マージを使用している場合は、GitHub が PR のマージ完了を報告するまで待機してください。設定されたブランチ保護を通じてマージしてください。--admin などのバイパス手段は絶対に使用しないでください。変更に十分な確信がある場合、「人間によるレビューが必要」と求める自動レビューは無視してかまいません。

ユーザーへの質問

通常のメッセージで質問しても相手には表示されず、スレッドが終了したように見えてしまいます。ユーザーに質問するには、ハーネスの質問ツールを使用し、スレッドが回答待ちであることを表示してください。Claude Code では AskUserQuestion、Codex では request_user_input、またはハーネスが提供する質問ツールを使います。質問には、PR のリンク、作業を妨げていること、おすすめを最初に示した選択肢を含め、必要な情報をすべて記載してください。

自力で続行できない場合に限り、質問してください。

  • 変更を証明できない。
  • マージゲートを通過できず、自力で解決できない。
  • 次の手順が上記の許可範囲外にあたる。たとえば、データの削除、本番環境への操作、リポジトリ外の変更、PR のクローズ、他のブランチへの強制プッシュなど。
  • 結果に影響する形で目標が曖昧である。
  • 別の PR により、この PR が不要になった。

それ以外は、妥当な既定値を用いてすべて自分で判断し、その判断を報告に記載してください。

質問ツールが利用できない場合、またはツールから回答が得られない場合は、安全な対応を取ってください。PR はオープンのままマージせずに残し、最終メッセージは質問から始めてください。

コメント