setup-harness

ハーネスのセットアップ

/implement は、チケットをレビューからマージまで進めます。その周辺にある3つの要素は、スキルではなくリポジトリに属する設定です。

• リポジトリフック — エージェントや Git のイベントによって実行される動作
• マージの自動化 — 条件が満たされたプルリクエストをマージする仕組み。これにより、エージェントが自分の作業をマージすることはありません
• ワークツリーのクリーンアップ — マージ済みのワークツリーが削除されたときに、リポジトリが解放するもの

これはプロンプト駆動型のスキルであり、決定論的なスクリプトではありません。調査し、わかったことを提示し、ユーザーに確認してから、書き込みを行います。設定は作業ファイルそのものであり、このスキルはそれらについて説明するドキュメントを作成しません。

プロセス

1. 調査する

存在するものを読み、決めつけないでください。

• git remote -v — GitHub リポジトリですか？どのリポジトリですか？デフォルトブランチはどれですか？
• .codex/hooks.json と .cursor/hooks.json — このリポジトリですでに実行されているフックを確認します。ハーネスが管理するものに限りません。
• .mergify.yml — 存在しますか？すでに何を条件にマージしていますか？
• 直近のプルリクエスト数件をマージしたのは誰ですか：gh pr list --state merged --limit 5 --json number,mergedBy。Bot のログイン名があれば、マージの自動化はすでに導入され、稼働しています。自分のアカウントだけなら、自動でマージする仕組みはありません。
• .github/workflows/ — チェックとして報告されるジョブ名を確認します。これらが、名前付きマージ条件の候補です。
• .agents/hooks/cleanup — このスキルが以前に出力した内容を確認します。
• git worktree list とリポジトリ独自のスクリプト — リンクされたワークツリーは、データベース、ポート、生成された環境ファイルなど、独自のリソースを受け取りますか？core.hooksPath の下にあるチェックアウトフックが何かをプロビジョニングする場合は、それが最も明確な兆候です。
• AGENTS.md、CLAUDE.md、package.json のスクリプト、Makefile、または scripts/ を参照して、リポジトリでチェックを実行する方法を確認します。/implement はこのコマンドから開始するため、どこかに記録するのではなく、見つけられることを確認してください。

2. フックを設定する

このスキルの scripts/install_hooks.py を実行します。このスクリプトがエージェントフックと Git フックのインストール全体を管理し、冪等なので、ここでは何も尋ねず、呼び出しのたびに実行してください。フックの構成と接続はインストーラーで管理します。フックが進化しても、この手順は変更しません。

3. 調査結果を提示して質問する

存在するものと不足しているものを要約します。その後、各セクションを順番に 取り上げます。1つのセクションにつき回答は1つ提示し、次に進みます。各セクションの 最初に推奨する回答を示して、ユーザーが一言で承認できるようにします。調査によって すでに決着している場合は、そのセクションを丸ごと省略します。

再実行時は、リポジトリにすでに設定されているものを推奨する回答とします。それを 維持することを提案し、ユーザーが変更を求めた場合にのみファイルを書き込みます。 このスキルを再実行しても、手動で調整した設定はそのまま維持されます。

セクション A — マージの自動化。

説明：/implement はすべてのマージ条件が満たされるようにし、その状態を待ちます。 実際にマージを行うのは別の仕組みです。ここでは Mergify がデフォルトです。非公開 リポジトリで GitHub 独自の必須チェックと自動マージを使うには、有料プランが必要なためです。

推奨：このリポジトリで実際に必須となっているチェックを条件とする Mergify。 .github/workflows/ にあるジョブ名を確認し、パスする必要のあるものを提案します。 通常はテストやインテグレーションのジョブであり、一部の変更でしか実行されないジョブ ではありません。デフォルトブランチを置き換え、必須チェックごとに check-success 行を 1つ追加して、mergify.yml を作成します。

次の代替案も提示します。

• チェック数で判定する — check-success 行を #check-failure = 0 と #check-pending = 0 に置き換えます。ワークフローの名前が変更されても影響を受けませんが、 競合状態が生じます。チェックがまだ作成されていないプルリクエストは、両方のカウントを 満たしてしまいます。必須チェックの構成が実際に変わる場合にのみ提案してください。
• 自動化なし — /implement が待機する間、レビュアーが手動でマージします。

.mergify.yml がすでに存在する場合、このスキルが管理するルールだけを変更し、 ファイルの残りの部分はそのままにします。

Mergify の GitHub App がリポジトリにインストールされるまでは、マージは実行されません。 調査でボットによるマージが確認できなかった場合は、その旨を伝え、 https://github.com/apps/mergify を案内します。

セクション B — ワークツリーのクリーンアップ。 調査でワークツリーごとのリソースが 見つからなかった場合は、このセクションを丸ごと省略します。/implement はマージ済みの ワークツリーとそのブランチをすでに削除するため、ほかに管理対象がないリポジトリには フックは不要です。

それ以外の場合は、次の質問を1つだけします。

ワークツリーがなくなった後、ワークツリーが所有していたものを解放するコマンドは何ですか？

回答を RELEASE_COMMAND プレースホルダーに置き換え、実行可能な .agents/hooks/cleanup として記述します。出発点として cleanup を使います。 /implement はマージ済みのワークツリーを削除した後にこのコマンドを実行し、その出力を 報告します。したがって、コマンドは何を解放したかを明示し、何も報告せずに動作しない ようにしてください。

4. 確認して書き込む

書き込む各ファイルをユーザーに示し、先に編集してもらいます。その後、ファイルを書き込み、 .agents/hooks/cleanup を実行可能にします。

5. 完了

生成されたファイルをコミットして、ツール設定をリポジトリの一部として維持するよう ユーザーに伝えます。また、Codex ではプロジェクトのフックを信頼するために /hooks を 一度実行する必要があり、Cursor では保存時に .cursor/hooks.json が再読み込みされることも 伝えます。ツール自体の更新には npx skills@latest update を使います。このスキルは、 リポジトリのマージ方法や解放する対象を変更する際に再実行する価値があり、どのような 理由で再実行しても安全です。