r3xsean/see-it-through

ユーザーのリクエストからコード変更を最終目的地まで導き、別のモデルをレビュアーとして使用します。ユーザーは2回だけ判断します：設計段階でのアプローチ、そして出荷メッセージでの結果です。それ以外のすべてはあなたの役割です。

他のモデルは、ユーザーが指定したファミリーの最新モデルで、orchestrator_capabilities に定義され、指定された努力レベルで動作します。同じモデルと努力レベルが、以下のすべてのやり取り、コードループ、レビューに使用されます。ただし、重要な判断の議論は例外です。ファミリーまたは努力レベルが不足している場合は、それを尋ね、ユーザーが回答するまでそれ以外は何もしません。

ランナーはステップ3でアプローチをあなたの代わりに議論します（back-and-forth スキルのランナー）。ユーザーがランナーを指定しない限り、新しいFableモデルを中程度の努力で使用し、他のモデルと議論します。重要な判断の場合、新しいFableモデルを高努力で使用し、他のモデルの代わりに新しいAstraモデルを高努力で議論します。重要な判断とは、design.mdの構造的質問のトリガーが発動し、その答えがアプローチを変える可能性のある質問を述べられる場合です。ランナーまたはそのパートナーのモデルが利用できない場合は、その旨を伝え、他のモデルと一緒に自分でアプローチを議論します。

1. 目的地とルール

変更の最終地点（テスト済みローカル変更、プッシュされたブランチ、オープンPR、マージ済み、またはデプロイ済み）を決定します。不明瞭で、その答えが作業を変える場合にのみ質問します。「see it through」と言うだけではプッシュ、PR、デプロイを承認しません。出荷メッセージの承認のみがそれらを承認します。

変更対象のリポジトリのルール、およびユーザーが指定したプロセスファイルがあれば、それらがこのスキルと異なる場合は優先されます。

既に構築された変更。 ユーザーが変更は既に行われていると言った場合、構築されたものがアプローチとなり、出荷メッセージが最初の承認となります：説明者を送信せず、back-and-forthも実行しません。ステップ2と3の代わりに以下を実行します：

• ベースを固定：マージされていないブランチの場合は、そのブランチがマージされるブランチとのマージベース（最後にそのブランチをマージした後のもの）。マージ済みの場合は、変更の直前のコミット。不明瞭な場合は質問します。変更が既にマージされている場合、目的地はこの実行の後続コミットの行き先となります。不明瞭な場合は質問します。
• ユーザーの言葉と、変更自体が示す内容（コミットメッセージ、PRテキスト）からリクエストを書き、推測した部分を明確にします。
• ベースのワークツリーで失敗し、変更では合格するチェックを、まず変更が既に持っているテストから開始して見つけます（ベースに変更のテストとハーネスのハンクのみを適用して実行）。約束された動作のいずれも証明しない場合にのみテストを新規作成します。失敗を示さない変更（パフォーマンス向上やリファクタリングなど）の場合は、約束された動作のチェックを作成します。ステップ2と同様にティアを設定します。ステップ4と同様に、変更が約束する各動作を証明する最小限のチェックを受け入れベースラインとして保持し、変更後に作成されたものを記録します。変更のその他のテストは simplify.md に従って開いたままにします。
• 構築されたアプローチをファイルに記述：何が変更されたか、design.mdの根拠、構築されたものに関する構造的質問の回答、およびステップ3の失敗チェック。

その後、ステップ4から続行し、再現が合格していることを示し、そのベースとそのファイルをアプローチとしてコードループを実行します。出荷メッセージには、説明者が承認されなかったこと、および構造的代替案やユーザーが得るものを変更する発見があればそれを記載します。

2. 再現

バグの場合は、修正を書く前にベースで再現します：失敗するテスト、およびユーザーがバグを確認できる場合は、それを表示している実行中のプロダクトを、capture.md の指示に従って手動でキャプチャします（検証フローがまだキャプチャできない場合）。機能の場合は、ユーザーが表示または実行できるべき内容を記述します。バグを再現できない場合は、修正を構築する前にユーザーに伝え、それについて述べることは「コードを読んだ結果（未試行）」として記述します。何も見つからないチェックは、それが存在する場合に実際に見つかることを確認した場合のみカウントされます。

再現していない失敗パスに対するガードは構築せず、代わりに説明者にフォローアップとしてリストします。

リポジトリの検証スキルを使用して再現し証明します：リポジトリ内の .agents/skills/verify/、またはリポジトリの AGENTS.md に指定された場所。存在しない場合、または必要なフローをカバーしていない場合は、手動で再現し、そのカバレッジを make-verifiable スキルで構築することをアプローチの一部とします。

次にティアを設定します。フル：変更された動作が永続性、並行性、認可、マイグレーション、公開契約、破壊的効果、または共有状態の所有権に影響する場合、または変更されたコードにどのように到達するか、テストのカバレッジがどの程度かをまだ判断できない場合。呼び出し元と状態ライターによって判断し、ファイル名ではありません。ライト：上記以外。ライト実行でこれらのいずれかが判明した場合はフルになります。

3. 設計と説明者

アプローチを選択する前に、design.md を読み、その指示に従います。フル実行では、アプローチについてモデルとやり取りします（back-and-forth スキル）。design.md の割合推定値をコンテキストの前提条件として、より小さいバージョンと変更なしをオプションに含めます。ライト実行では、design.md のトリガーが発動した場合、または強力なアプローチが実質的に異なる場合のみこれを行い、それ以外は自分でアプローチを記述します。ランナーには、コンテキストとして、参照付きの根拠、再現したものと読んだだけのもの、セッションのスクラッチパッドまたはテンポラリフォルダへのパスを与えます。質問（リクエストから記述）では、変更のランディング場所、呼び出し元と兄弟ケース、受理ケース、およびあなたに残されたものも尋ねます。設計上の質問が実行によって観察可能な事実である場合は、ユーザーに尋ねるのではなく、隔離されたチェックアウトまたはスクラッチデータで使い捨て実験を行って解決します。実験は何も出荷しません。

次に失敗チェックを記述します：code-loop スキルのブリーフヘッダーの条件をすべて確認し、さらに変更する動作に依存していたものを確認します。該当する各条件について、それをカバーするテストの名前、または受け入れる制限を記述します。

ユーザーに説明者を、平易な言葉で、以下の見出しの順に送信します。各事項は一度だけ述べます。

• 問題： 今日ユーザーが見るもの、誰がどの程度の頻度で遭遇するか（観測または推定。報告がない場合は不明、稀ではない）、なぜ重要か、あなたの再現、キャプチャがあればそれ。機能の場合は、今日不足しているもの。ユーザーが変更を依頼した場合は、その言葉で始めます。
• なぜ起こるか： 原因を平易な用語で。機能の場合は、今日妨げとなっているものがあれば。何もない場合はこの見出しを省略します。
• 何が変わるか： 完了時にユーザーが表示または確認できるもの、および範囲外のもの。作業を変更する可能性のあるものが不足している場合は、ここで質問します。
• アプローチ： コードのどこで何が変わるか、どのように証明するか（make-verifiable 作業を含む、どのチェックが変更とともに出荷され、どれが証拠として残るか）、出荷と維持のコストと、それが問題の下でのリーチと害に見合う理由、およびレビュアーが気にするであろう失敗チェックのエントリ。
• 検討した代替案： すべての強力な代替案、design.md の構造的オプション（信頼できるものが存在する場合）、それぞれが選ばれなかった理由。
• レビュアーが尋ねる可能性のあること： 可能性のある質問とその回答。

その後停止します：ユーザーが承認するまで何も構築しません。平易な承認（任意の表現）で構築を開始できます。それ以外の場合は、そのまま同じ back-and-forth にさらなる交換として（交換制限を超えて）追加し、改訂された説明者として戻します。再度停止します。ライト実行で back-and-forth がない場合は、自分で説明者を改訂し、再度停止します。

承認は説明者の記述内容をカバーします。テスト、デモ、レビューによってユーザーが得るもの（その可視動作、互換性、範囲、出荷のためのアクション、説明者が受け入れたトレードオフ）が変更された場合は、それが偽る文を引用し、モデルと解決し、変更点を説明する改訂版説明者を送信し、再度停止します。異なる内部ヘルパーの使用など、より小さな発見は、出荷メッセージの「what changed since」に記載します。

4. 構築と証明

動作を変更する前に、変更が存在する前に実行できるすべての受け入れチェックと再現を保持します：説明者が出荷するものをコミットし、残り（または何もコミットされない場合はすべて）をリポジトリ外のパッチとして保存します。これらを合わせて受け入れベースラインとし、すべてが最終候補で再実行されます。その後の編集はコードループと出荷メッセージにその差分と、約束された動作を変更するかどうかとともに送られます。

承認されたアプローチを、design.md が設定する順序で構築します。変更が検証スキルがカバーするフローを変更する場合、同じ変更でそのフローを更新します。ステップ2の再現が、検証スキルを通じて、およびユーザーが確認できる場合は実行中のプロダクトで合格していることを示します。次に、simplify.md の指示に従って差分を簡素化します。その後、モデルとフル差分でコードループを実行します（code-loop スキル）。コードループには、ユーザーのリクエスト（またはそれを代表するブリーフ）をリクエストとして、説明者をアプローチとして（ランナーの記録があればそれも）、受け入れベースラインを受け入れとして、ティアを与えます。

最終候補で、ユーザーが変更されたものを表示または実行できる場合、検証フローを通じてキャプチャします。make-verifiable でフローを拡張し、バグの場合は同じフローを通じてベース上の同じシナリオをキャプチャし、before/after が一致するようにします。capture.md の指示に従いキャプチャを選択、作成、レビューし、それが示すと言う内容を実際に示していることを確認します。キャプチャは変更を示し、チェックがそれを証明するため、ベースまたは失敗した実行のキャプチャが合格とみなされることはありません。表示するものがない変更はキャプチャ不要です。

5. 書き起こし

プロジェクトのテンプレートからPR、Issue、リリーステキストのドラフトを作成し、テンプレートにスペースがある場合はキャプチャを挿入するか、独自の見出しの下に配置します。GitHubでは、リポジトリに独自のツールがない限り、公開時に gh pr create --attach（または gh pr edit）でキャプチャを添付します。終了コードが非ゼロの場合は、PRが既に存在する可能性があるため、再試行する前にPRを確認します。事実を述べる公開テキスト（説明、返信、ステータス更新）が公開される前に、新しいモデルのレビュアーが証拠、キャプチャ（フレームとペーシングレポートを含む記録）、および差分に対してチェックします：すべての主張が真実で裏付けられ、すべてのチェックボックスが真実であることを確認します。証拠が裏付けない主張は削除します。曖昧にしません。

プッシュの前に、各チェックボックスと各主張の背後にあるチェックを再実行し、各キャプチャを再作成します。変更以降の影響を受ける可能性があるためです。

6. 出荷メッセージ

ユーザーに送信：説明者の2〜3文の要約、変更点、証拠、キャプチャ、書き起こし、差分、承認時に取る正確なアクション。コードループが未解決の論争で終了した場合は、それらを先頭に：各主張、各サイドが示したもの、承認で出荷されるもの。送信前に、design.mdの重複チェックを再実行します。ユーザーが承認するまで停止します。

7. 目的地まで

承認されたアクションを実行し、変更を目的地まで運びます：

• 各プッシュの前、および通知に基づいて行動する前に、リモートヘッドをフェッチし、変更の現在のステータスを確認します。コミットハッシュではなくツリーを比較して、他の人のプッシュの上に構築します。古いローカルバージョンで彼らの作業を置き換えないでください。変更がランディング、クローズ、または他の誰かのバージョンに置き換えられた場合、目的地に到達したものを最後に確認したヘッドと未解決の発見と比較します。何が異なるか、または含まれなかったかを報告します。彼らが意図的に削除したものを再追加しないでください。
• すべてのレビュー発見（インラインまたはレビューボディ内）は全文を読み、修正または1行の理由を付けます。ベースでも発生するものは、code-loop が既存の発見を判断する方法で判断します。動作を変更する修正はコードループを取得します。
• 事実が投稿されたテキストを間違っていると証明した場合、テキストを修正します。
• スコープまたはアプローチを変更するリクエストはステップ3に戻り、構築されたら新しい出荷メッセージに進みます。この変更を超えて適用されるリクエストは、到着時にユーザーにリンクとともに送られます。ここで行うことは、他の場所では行われません。
• デプロイの場合は、デプロイされたものに対して検証フローを実行します。

8. 教訓

ユーザー、PRレビュアー、または出荷後の何かが、コードループが見逃した問題を発見した場合、またはコードループがブロッカーを見つけた（または見つけるべきだった）場合、変更したリポジトリの .agents/lessons/log.md にエントリを追加します。ユーザーが所有していないリポジトリの場合は、そのプロセスを保持するフォルダに追加します。各エントリ：日付、変更、何が誰によって発見されたか、モジュール、バグクラス、原因。

その後ログを読みます。チェックでキャッチできる教訓が2回見られた場合、lint、型、テスト、または検証チェックになります。判断が必要な教訓が2回見られた場合、リポジトリの AGENTS.md の行になります。1つのモジュールに2つのエントリ、または任意のモジュールに1つのバグクラスの2つのエントリ（例：別の操作がawait中に変更する状態）は、リファクタリングが提案される前に、それらが共有する原因を命名する構造的質問になります。それぞれを最終メッセージのフォローアップとしてリストします。リファクタリングは独自の see-it-through として実行されます。

変更が目的地に到達したとき、または正確なブロッカーと残っているもの、および教訓エントリ（必要な場合）を報告したときに完了します。