complete-work

作業を完了する

この呼び出しで指定されたタスクについて、新しいブランチの作成から、検証済みの実装、PR レビューサイクルの完了まで進めます。

1. 作業範囲を確定し、ブランチを作成する

付随する指示と会話から、依頼された作業と受け入れ基準を確認します。指定された作業が Linear の課題またはチケットの場合は、参照資料を含め、作業範囲を確定するために必要な要件と受け入れ基準をすべて確認します。タイトルや概要だけでは不十分です。Linear のチケットがない場合は、ユーザーの依頼と会話全体を作業範囲とします。該当する AGENTS.md ファイルとリポジトリの要件を確認します。タスクが指定されていない場合は、ブランチを作成する前にユーザーに確認します。

タスクの実行にあたり、重大な曖昧さ、要件の矛盾、未解決のトレードオフ、実装リスクなど、ユーザーの判断が必要な問題がある場合は、ブランチ作成や実装の開始前に $grilling を呼び出し、そのインタビューを完了します。共通認識についてユーザーの確認を得てから作業を進めます。これは条件付きの支援機能であり、必須の工程ではありません。依頼と受け入れ基準が明確で、実行可能な場合は省略し、運用上の障害は通常のワークフローで対処します。

作業ツリー、現在のブランチ、リモートを確認します。既存の変更を保持し、新しいブランチと PR には無関係なコミットを含めないようにします。対象となるベースリポジトリのリモートを特定し、GitHub のメタデータまたはリモート HEAD（git ls-remote --symref <base-remote> HEAD）から、そのリポジトリのデフォルトブランチを確認します。編集前にデフォルトブランチをフェッチし、フェッチした最新のコミットから --no-track を指定して、説明的な名前の新しいブランチを作成します。ブランチ名は agent/ で始めてください（例：agent/add-login-validation）。サフィックスにはリポジトリの命名規則を使用し、PR のベースには確認したデフォルトブランチを指定します。新しいブランチの初期 HEAD が、フェッチしたデフォルトブランチのコミットと一致することを確認します。古いローカルのデフォルトブランチや現在のフィーチャーブランチからブランチを作成してはいけません。既存の作業を保護する必要がある場合は、分離された worktree を使用します。リモートまたはデフォルトブランチが特定できない場合、デフォルトブランチが存在しない場合、またはフェッチに失敗した場合は、作業を中止して問題を報告します。

create-pr と finish-pr のスキルが利用可能であること、GitHub CLI の認証が対象リポジトリをサポートしていることを確認します。前提条件が不足している場合は、必須の工程を黙って省略せず、その旨を明示して報告します。

編集前に、対象の head リポジトリ（フォークの場合、ベースリポジトリとは異なることがあります）へのプッシュ先リモートを特定します。続いて、git push --set-upstream <head-remote> HEAD:refs/heads/<branch-name> を実行して、同じ名前のリモートブランチを作成します。git rev-parse --abbrev-ref "@{upstream}" の結果が <head-remote>/<branch-name> であることを確認し、さらに git ls-remote --exit-code --heads <head-remote> refs/heads/<branch-name> から返される SHA と git rev-parse HEAD の結果を比較して、リモートブランチがローカルの HEAD と一致することを確認します。ブランチの準備が完了するのは、同名のローカルブランチとリモートブランチの両方が存在し、ローカルブランチがそのリモートブランチを追跡している場合に限ります。公開または検証に失敗した場合は、作業を中止して問題を報告します。

2. 段階的に実装してコミットする

提示されたタスクを実装し、変更をその範囲内に収めてください。まとまりのある部分が完成して検証できた時点で、意味のある区切りごとにコミットしてください。複数段階にわたるタスクのすべてのコミットを最後まで先送りしないでください。小規模なタスクであれば、コミットは1つで十分な場合があります。このタスクに属する変更だけをステージし、ステージした各差分を確認して、内容が分かるコミットメッセージを付けてください。

確定したタスクの簡潔なレビューコンテキストを維持してください。要件、判断事項、対象外の事項、検証の証拠を記載します。PR の作成から finish-pr まで、この情報を引き継いでください。会話全体を繰り返すのではなく、要件の不足を明らかにするために活用してください。

公開前に追加の検証を行う場合は、具体的な失敗リスクに基づいて選んでください。認証、テナント分離、課金、マイグレーション、レビューコントローラーの変更では、通常のハッピーパスを超える関連チェックが必要です。たとえば、実際の利用者を対象としたテスト、ブラウザーでの動作確認、未解決の疑問に答えるための範囲を限定した新しいコンテキストでのレビューなどがあります。既存の証拠がそのリスクをカバーしている場合は再利用してください。通常の変更では、既存の検証・レビューパスを使用します。追加の AI レビューは任意であり、対象を限定し、公開前に最大1回までとします。すべての PR に対してデフォルトで2回目のレビューを行うものではありません。選択したチェックで見落とす可能性がある点を明記してください。実行は実装に認められたテスト環境で行ってください。これは、ソースコードのみをレビューするレビュアーに対し、レビュー対象のコードを実行する権限を与えるものではありません。

実装のコミットを公開する前に、意図したベースとの差分全体を確認してください。提示された Linear チケットの各要件と受け入れ条件、または Linear チケットが提示されていない場合はユーザーリクエストのすべての項目について、それを満たす実装と検証の証拠を示してください。関連するテストとリポジトリで必須のチェックを実行し、この作業によって発生した失敗を修正して、意図しない変更や抜け漏れがないか確認してください。

作業がスコープを完全に満たし、関連する検証に合格し、タスクの変更がすべてコミットされた場合にのみ、ステップ3に進んでください。先に進む前に、スコープ内の未完了の作業をすべて終えてください。必要な情報、アクセス権、判断、検証が不足している場合は、具体的に不足している点を説明し、必要なものをユーザーに求めてください。それを受け取るまで先に進まないでください。ブロッカーや制限を報告しても、このゲートを満たしたことにはなりません。一部だけの作業について PR を作成したり、既存の PR を再利用したりしないでください。ドラフト PR も同様です。PR 作成に進むことは、依頼された内容をすべて把握し、完了していることを表明するものです。

3. プッシュして PR を作成する

完了したコミットを、強制プッシュを使わず、明示的な宛先 git push <head-remote> HEAD:refs/heads/<branch-name> でプッシュしてください。PR の本文を書く前に、test-changes を読み、その指示に従って完了した作業の手動検証の引き継ぎ情報を作成してください。続いて $create-pr（SKILL.md）を読み込み、その指示に従って、意図したベースブランチに対する PR を作成するか既存の PR を再利用してください。Linear チケットのタイトル接頭辞、テンプレートの選択、分類、平易な言葉による簡潔なユーザーストーリー、提出前の検証に関するルールに従ってください。元のストーリーを調整する場合も含め、技術的な背景のない読者にも理解できるストーリーにしてください。タスクの意図、元のユーザーストーリー（ある場合）、タスクに関係し PR で完全に対応する Linear チケットの ID、最終的な差分、検証結果、ベース／ヘッドのリポジトリとブランチ、引き継ぎ内容の全体を提示してください。引き継ぎ内容は必ず ## Test changes という見出しの節に含めてください。テンプレートにその節がある場合はそこに記載し、ない場合は、別のテスト用セクションが存在していてもテンプレートの後に追加してください。

このワークフローを要求する呼び出しは、コミット、プッシュ、PR 作成、レビューへの返信を許可するものです。重ねて確認を求めず、これらの手順を最後まで実行してください。

4. finish-pr で PR を完了する

同じ実行内で、新しく作成した PR に対して $finish-pr を読み込み、その指示に従ってください。タスクの意図、決定事項、検証内容、既知の制限を引き継いでください。完了の定義を満たすか、停止条件に該当するまで、競合、CI、フィードバック、レビュー収束のワークフローを続けてください。PR を作成しただけでは、このワークフローは完了しません。

マージを別途依頼されていない限り、ユーザーがマージできるよう PR はオープンのままにしてください。PR の URL、変更内容と検証結果の簡潔な概要、残っているブロッカーや保留中の必須チェックを報告してください。その際、finish-pr の最終監査を正としてください。