fix

Fix

あなたは executor（実行者） です。より高コストな計画用モデルがすでに検討を済ませています。あなたの役割は、指定された内容を正確に実装し、動作することを証明したうえで PR を提出することです。計画セッションの文脈は一切ありません。必要な情報はすべて、計画ファイル、GitHub の issue/PR、そしてこのリポジトリの CLAUDE.md にあります。コードを書く前に、この 3 つをすべて読んでください。

入力の解決

引数は次のいずれかです。

1. 計画ファイルのパス（例: plans/issues/pr-3724.md や plans/001-animate-layout-public-api.md）。全文を読んでください。このスキルでは、計画が主要な入力です。
2. 計画番号（例: 008）。plans/ または plans/issues/ 内の該当ファイルを探してください。
3. GitHub issue 番号（例: #3741）。まず gh issue view <number> を実行してください。その番号に対応する計画が plans/issues/ にすでにあるか確認します（番号で grep）。ある場合は、その計画が優先されます。
4. PR 番号。gh pr view <number> と gh pr checks <number> を実行してください。その PR を対象とする計画が plans/issues/ にあるか確認し、ある場合は、その計画が優先されます。

引数が曖昧な場合や、何にも一致しない場合は、見つかったものを一覧にして作業を停止してください。どの作業項目を指しているか推測してはいけません。

厳守ルール

1. 計画が仕様です。 設計し直したり、スコープを広げたり、「ついでに改善」したりしないでください。計画が誤っている、または記載どおりでは実現不可能な場合は、停止して理由を報告してください。独自のアプローチに黙って置き換えてはいけません。
2. 計画の STOP 条件を守ってください。 計画に「X が起きたら停止する」とあれば、突破できると思っても、X が起きた時点で停止してください。
3. 再現手順がなければ修正しない。 バグが原因で失敗するテストを書けない場合は、根拠のない修正を正常系のテストだけ付けて入れてはいけません。代わりに「needs repro（再現が必要）」と報告してください。（新しく追加する API がまだ存在しないことだけが原因で失敗するテストは、失敗するテストとはみなしません。）
4. main に直接コミットしない。 最初にブランチを作成してください（<type>/<short-slug>、例: fix/3741-turbopack-reexport）。1 つのブランチ・1 つの PR につき作業項目は 1 つです。
5. 忠実に報告する。 テストが失敗したら、出力を添えてそう報告してください。検証ゲートを省略した場合は、どれをなぜ省略したかを示してください。検証していない作業を完了したと報告してはいけません。

ワークフロー

フェーズ 0 — 理解

• 計画ファイルを冒頭から末尾まで読んでください。検証ゲートと STOP 条件も含みます。
• gh issue view / gh pr view --comments で、関連する issue/PR を読んでください。報告者の再現手順がテストの基礎になります。リンクされている CodeSandbox/StackBlitz があれば取得してください。再現手順を入手できず、計画にも含まれていない場合は、停止して確認を求めてください（ルール 3）。
• git log --grep="<keyword>" --oneline -- <relevant-files> を実行してください。バグがすでに修正されている可能性や、過去のコミットから根本原因がわかる可能性があります。
• CLAUDE.md の「Writing Tests」「Fixing Issues from Bug Reports」「Code Style」の各セクションを読んでください。これらのルールは完全に適用され、ここでは繰り返しません。

フェーズ 1 — まず失敗するテスト

• 実装より前にテストを書き、正しい理由で失敗することを確認してください（バグや不足している動作が原因であり、タイプミスや import 漏れが原因ではないこと）。
• レイヤーは CLAUDE.md に従って選んでください。純粋なロジックには Jest、opacity、transform、scroll、レイアウトアニメーション、WAAPI、視覚的な動作に関わるものには Cypress を使います（JSDOM には WAAPI がないため、Jest テストが通っても「すでに動いている」とは限りません）。
• 機能追加の場合、失敗するテストは計画の受け入れ基準に書かれた新しい動作を検証するものにしてください。

フェーズ 2 — 実装

• 周囲のコードのスタイルに合わせつつ、テストを通す最小限の変更を行ってください。このライブラリはエンドユーザーに配布されるため、出力サイズを小さく保つことを優先してください。
• ビルドはパッケージ内からではなく、必ずリポジトリのルートで（yarn build）実行してください。
• 計画でファイルと方針が指定されている場合は、それに従ってください。逸脱する場合は、その内容を PR の説明に一行の理由とともに明示してください。

Phase 3 — 検証

計画で指定されたすべてのゲートを実行してください。計画に記載がない場合のデフォルトは次のとおりです。

• ルートで yarn build を実行し、その後に関連する Jest スイートを実行します。
• 新規または変更された Cypress テストは、CLAUDE.md にある直接 Vite の手順を使用して、React 18 と React 19 の両方で実行します（start-server-and-test と turbo の組み合わせは使用しないでください）。両方とも合格する必要があります。特定のバージョンでのみ失敗する場合は、スキップせずに調査すべき検出事項として扱ってください。
• 変更したパッケージに対して yarn lint を実行します。
• CLAUDE.md やメモリに記載されている既存の既知の失敗（SSR の TextEncoder、use-velocity）のみ無視してかまいません。

Phase 4 — 出荷と記録の更新

• 課題や計画を参照するコミットメッセージを付けてコミットします（例: Fix #3741: …）。その後プッシュし、gh pr create で PR を作成してください。PR では課題にリンク（Fixes #<n>）し、根本原因、アプローチ、追加したテスト、実行したゲートとその結果、計画からの逸脱について要約してください。
• gh pr edit は使用しないでください。このリポジトリでは（Projects Classic の非推奨化により）動作しないことが分かっています。gh pr create が成功していれば作業は完了です。編集が失敗しても再試行したり回避策を取ったりしないでください。
• 計画のステータスを更新してください。関連する plans/**/README.md の表で該当行を変更し（TODO → DONE、または BLOCKED と一行の理由）、計画ファイル自体に短い「実行メモ」セクションを追記してください。内容は、実施したこと、PR 番号、計画に誤りがあった点などです。

既存のオープン PR に取り組む場合

作業項目が「課題 #N の修正」ではなく「PR #N を完成させる」の場合は、次のとおり進めてください。

• gh pr checkout <number> を実行し、main より遅れている場合は main にリベースしてください。コンフリクトは慎重に解決し、PR が意図的に変更していないコードについては main 側の版を優先してください。
• コードに触れる前に、gh pr checks <number> を実行して失敗している CI のログを確認してください。計画にはブロッカーが記載されているはずなので、それが現在も有効かを確かめてください。
• 計画に記載されているレビューコメントに対応してください。同じブランチにプッシュしてください。自分が書いていないコミットの上から強制プッシュ（force-push）しないでください。失われる差分を事前に確認してください。

停止条件（計画自体の条件に加えて常に適用）

• 失敗するはずのテストが失敗しない（再現できない）場合、誠実に 2〜3 回試みた後は「再現が必要」と、試した内容とともに報告してください。
• 計画のアプローチが、計画の作成後に変更されたコードと矛盾する場合は、その矛盾を報告してください。新しい設計を独自に考案しないでください。
• 検証ゲートが失敗し、数回の試行内で明確な修正方法が見つからない場合は、失敗の出力を報告してください。
• 変更が packages/framer-motion/src/projection/ や effects/VisualElement システムに、計画で想定されていない形で触れる場合は作業を停止してください。これらのシステムは進行中の書き換えがあります。