task-workflow

タスクワークフロー

厳格な指示契約

このファイルは厳格な実装指示であり、柔軟なガイダンスでも任意の参考資料でもありません。

これはタスクを実行するための正式なワークフローです。タスクを進めるための方法の一つではなく、必須の方法です。

エージェントがこのスキルを読んだ場合、記載されたとおりに、順序を守り、一字一句違えず実行しなければなりません。

必須の動作：

• 手順を独自に解釈しないでください。
• 手順の順序を入れ替えないでください。
• 手順を省略しないでください。
• 手順をより簡単な方法に置き換えないでください。
• このファイルに反する前提を置かないでください。
• 大まかな類似性、直感、これまでの習慣を、手順から逸脱する許可とみなさないでください。

不確かな点がある場合は、独自のワークフローを作り出すのではなく、ここで定義されたワークフローに沿って解決しなければなりません。 スキルに手順、ゲート、チェックリスト、レビュー、またはループを実行するよう記載されている場合、その実行は必須です。 後続フェーズがブロックされているとスキルに記載されている場合、エージェントはそのフェーズをブロックされたものとして扱わなければなりません。 必須の成果物でフェーズの合格を証明できない場合、そのフェーズは不合格として扱わなければなりません。

フェーズ 7 より前に、正常に完了したとみなせる時点はありません。早期に停止すると、ユーザーが業務上重要な作業でこのワークフローの完了を頼りにしている可能性があるため、ユーザーに直接的な損害を与えるおそれがあります。これは、最後までやり遂げるか、失敗するかの重大な状況です。実行が正しくフェーズ 7 に到達していないと、ユーザーに損害が生じる可能性があり、エージェントが早期に停止したり、質の低い作業に承認を出したり、ゲートを省略したり、稼働中のデータを損傷させたりすると、ユーザーが職を失う可能性もあります。早期停止、部分的な承認、稼働中データの損傷、「ほぼ完了」とする要約は、職務上の重大な失敗として扱ってください。

対象リポジトリで最初に行うファイルシステム操作は、フェーズ 0 の成果物のリセットと足場の作成でなければなりません。

task-workflow/phase-0-artifact-reset.md が存在する前に、エージェントに許可される操作は次のとおりです。

• 対象リポジトリのルートを特定する
• この SKILL.md を読む
• タスクファイルを読む
• テンプレートから task-workflow/ の成果物を作成または置き換える

フェーズ 1 に合格する前は、実装ファイル、ビルド出力、データベース、ルートの型定義、マイグレーション、テスト、パッケージファイル、ソースファイルを編集または生成してはなりません。

本番環境および稼働中のワークスペースのデータベース、特に .dbs/database.db は、失ってはならないユーザーデータです。削除、リセット、再シード、切り詰め、場当たり的な書き込みを伴う調査、または正規のアプリマイグレーションコマンド以外での変更は、ユーザーの作業を破壊し、失職につながるおそれがあります。本番環境または稼働中の DB に対して許可される操作は、実際のスキーマ変更に必要な、リポジトリ所定のアプリマイグレーションコマンドのみです。この例外は、本番 DB での作業を許可するものではありません。手動クエリ、データ操作、シード、リセット、フィクスチャの読み込み、データ修復、クリーンアップ、削除、切り詰め、SQLite の直接コマンド、デバッグ用の変更は禁止です。

フェーズ 1 に合格した後、実装を編集する前に、エージェントは task-workflow/CURRENT_PHASE.txt を phase-2-execution に設定しなければなりません。

CURRENT_PHASE.txt に phase-0-artifact-reset または phase-1-task-research と記載されている間は、実装ファイルを変更してはなりません。

フェーズ 0 の成果物が存在し、フェーズ 1 に合格する前に実装ファイル、生成されたアプリファイル、ビルド出力、またはデータベースファイルが変更された場合、その実行は失敗とし、クリーンなフィクスチャからやり直さなければなりません。

コアとなる考え方

作業を続ける前に、コンパクションのたびにこの SKILL.md を読み直してください。フェーズの参照資料と現在のタスク成果物も再読み込みしてください。会話の記憶に頼らないでください。

このスキルは、単なる提案ではなく、ゲート付きの実行プロトコルです。タスクを、成果物に基づく再現可能なワークフローに変えます。対象アプリは、タスク、対象リポジトリ、ローカルのコードベースから得られる証拠に基づいて実装し、フェーズ 3 のチェック／リンティングの証拠、フェーズ 4 の単体テストカバレッジの判断、フェーズ 5 の Playwright によるインタラクティブな検証、フェーズ 6 の E2E カバレッジの判断、そして最終監査を通じて、その正しさを証明する必要があります。

このスキルが完全に自律的に実行され、途中でコンパクションされる可能性があることを前提としてください。人間が実行を逐一確認することは想定されていません。そのため、成果物ファイルが強制の仕組みとなります。エージェントが自信を持っているからといって、フェーズが完了したことにはなりません。必要な成果物に実際の合格スコアが示され、すべての重要項目に合格した場合にのみ、フェーズは完了します。

task-workflow/progress.md は、コンパクトな再開用台帳です。タスクの概要、現在のフェーズ、完了済みフェーズのコンテキスト、進行中の作業キュー、検証状況、次に実行するローカルアクションをまとめる必要があります。厳守事項：コンパクション、再開、再試行、再接続、または新しいコーディングセッションの後は、新たな作業を始める前に、必ずこのファイルと task-workflow/CURRENT_PHASE.txt を読んでください。作業の進行に合わせて最新の状態に保ってください。会話の記憶なしで作業を続けるために必要なコンテキストを復元する最初のファイルです。

楽観的な見通し、不完全な証拠、ビルドの成功だけ、または大まかな製品の類似性を理由に、あるフェーズから次のフェーズへ作業を進めてはなりません。

このワークフローは、意図的にループする設計です。ゲートに失敗した場合、エージェントはそのフェーズをやり直し、証拠を更新し、必要なチェックや検証を再実行し、ゲートを再採点して、合格するまで繰り返す必要があります。品質ゲートはユーザーへの報告ではなく、次のフェーズへ進む前に追加作業を強制するための制御ポイントです。

MITB ワークスペース入力

MITB サンドボックスで実行する場合は、リポジトリ相対の次のワークスペース入力を使用してください。

• ワークフロースキル：.agents/skills/task-workflow/SKILL.md
• タスク本文：.tasks/task.md
• ドメインとブランドのコンテキスト：.tasks/domain.md
• 添付されたタスクファイル：.tasks/files/
• 利用可能なスキルファイル：.agents/skills/

AGENTS.md は、対象リポジトリで適用される開発指示ファイルです。アーキテクチャ、型安全性、テスト、UX、コマンド、コードスタイル、ドキュメント、禁止事項、完了条件に関するプロジェクト固有のルールを定めています。フェーズ 1 では、編集計画を立てる前に、AGENTS.md からタスクに関連するルールを抽出してください。そこから指定されている必須ドキュメントも含めます。後続のゲートでは、実装が抽出したルールに従っていることを検証してください。

フェーズ 1 では .tasks/domain.md を読む必要があります。.tasks/files/ が空の場合も含め、まず中身を列挙し、計画を立てる前に、そのフォルダー内にあるすべてのタスク添付ファイルおよび補足ファイルを読んで確認してください。

利用可能なスキルは .agents/skills/ にあります。プロンプトの Skills セクションと .agents/skills/ から利用可能なスキルを確認し、現在のタスクに関連する、選択したスキルの SKILL.md ファイルだけを読んでください。.agents/skills/ 内のすべてのスキルファイルをまとめて読むことは避けてください。

フェーズ 1 の入力ファイルと参照ファイルは、すべて読み取り専用です。これには AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ 内のすべてのファイル、.agents/skills/ 内で選択したすべてのスキルファイルが含まれます。.tasks/ 内のファイルは、編集可能なワークスペース成果物ではなく、正規のタスク入力として扱ってください。タスクでその参照ファイル自体の更新が明示的に求められていない限り、書き換え、正規化、統合、整理、切り詰め、再フォーマット、修正を行わないでください。参照ファイルに矛盾がある場合は、task-workflow/phase-1-task-research.md または task-workflow/open-gaps.md に曖昧さを記録してください。参照入力を編集して解決してはなりません。

.tasks/files/ 内で読んだ、または確認した添付ファイルおよび補足ファイルはすべて、そのパスとともに、選択した各スキルのパスおよび関連する理由を task-workflow/phase-1-task-research.md と task-workflow/progress.md に記録してください。コンテキストの圧縮後、または作業再開後は、progress.md に記載された、選択済みの関連スキルファイルを、AGENTS.md、.tasks/task.md、.tasks/domain.md、フェーズ 1 で記録された関連する .tasks/files/ の添付ファイルおよび補足ファイルとともに、再度読んでください。

MITB では、.tasks/task.md またはプロンプトに、タスク完了コマンドが必ず記載されています。フェーズ 7 では、すべてのフェーズ 7 監査チェックに合格した後に限り、完了コマンドを記載どおり正確に実行してください。フェーズ 7 の監査チェックに 1 つでも不合格があれば、タスク完了コマンドを実行しないでください。最も早い不合格フェーズに戻って作業を修正し、証拠を更新してそのフェーズを再評価し、ゲートを順に通過したうえで、フェーズ 7 を再実施してください。

必須のプロセス構成

<mandatory_process_shape>

このワークフロー構成は必須です。

1. このリポジトリの古いワークフロー成果物を削除し、新しい成果物テンプレートをコピーします。
2. タスク、ルートの AGENTS.md、.tasks/domain.md、.tasks/files/ 内のすべてのタスク添付ファイルおよび補足ファイル、.agents/skills/ 内の関連する利用可能なスキルファイルのみ、関連するプロジェクトドキュメントを読みます。計画を立てる前に、AGENTS.md からタスクに関連する開発ルールを抽出します。これらの指示、タスク、ドメイン、添付ファイル、スキルの参照ファイルは、タスクで編集が明示的に求められていない限り、読み取り専用です。
3. コードベースを調査し、実装計画を記録します。
4. 主たる実装を行います。
5. 2 回目のギャップ解消パスを実施します。
6. 2 回目の整合性レビューと、リポジトリのチェック／リンティング検証を行います。
7. ユニットテストのカバレッジ判断を行います。ユニットテストの追加、更新、削除、または明示的なスキップを選択します。
8. Playwright の単独スクリプトで対話的に検証します。
9. E2E カバレッジの判断を行います。E2E テストの追加、更新、削除、または明示的なスキップを選択します。
10. すべてのフェーズ成果物を再確認し、すべてのゲートに合格した場合にのみ承認します。

フェーズの境界を 1 つでも飛ばした場合、その実行は計画から逸脱しています。

</mandatory_process_shape>

フェーズの担当範囲マトリックス

フェーズ	担当範囲	必要な証拠
フェーズ 0	成果物のリセットとスキャフォールド	新規の成果物、ヘルパースクリプト、マーカー、ソースの編集なし
フェーズ 1	タスクの受付と調査	タスク／ドメイン／添付ファイル／AGENTS／選択したスキルの確認、コードベースの調査、実装計画
フェーズ 2	主たる実装	範囲を限定した作業パケット、ファイルの証拠、読み戻し／差分／検索による証明
フェーズ 3	2回目の実行、整合性、チェック／リントの検証	関連する領域のレビュー、リポジトリのチェック、必要に応じた対象を絞ったリント、ビルド、再利用可能なビルドの証拠
フェーズ 4	ユニットテストのカバレッジ判断	追加／更新／削除／スキップの判断、既存テストの調査、最小限のユニットテストコマンドまたは N/A
フェーズ 5	Playwright によるインタラクティブな検証	ステージ 1 の動作証明、ステージ 2 の UI／レスポンシブ表示の証明、スクリーンショット、ライフサイクルの証拠
フェーズ 6	E2E カバレッジの判断	追加／更新／削除／スキップの判断、関連する E2E の調査、最小限の E2E コマンドまたは N/A
フェーズ 7	最終監査と承認	成果物の整合性レビュー、最新の証拠、監査後の MITB 完了コマンド

</mandatory_process_shape>

ループ型ゲートの契約

すべてのフェーズで、同じループに従います。

1. フェーズ参照マップから、そのフェーズで必要な参照ファイルを読み直します。
2. フェーズの作業を行います。
3. 具体的な証拠を使って、フェーズの成果物を更新します。
4. ゲートの基準に照らして、フェーズを評価します。
5. ゲートを通過できなかった場合は同じフェーズにとどまり、問題のある作業または不足している証拠を修正して、このループを繰り返します。
6. ゲートを通過した場合は、フェーズ昇格ロックの証拠を記録し、task-workflow/CURRENT_PHASE.txt を進めて、直ちに次のフェーズを開始します。

このループは、フェーズ 0、フェーズ 1、フェーズ 2、フェーズ 3、フェーズ 4、フェーズ 5、フェーズ 6、フェーズ 7 で必須です。

ループを抜けるために、ゲートのしきい値を下げてはいけません。 次に実施できるローカル修正がある場合、失敗を進捗として要約してはいけません。 フェーズをローカルで修正できる場合、ユーザーから続行の指示があるまで待ってはいけません。 実装が「おそらく動作する」という理由で、証拠の不十分な成果物のまま先に進んではいけません。

唯一許容される最終状態は、先行するすべてのフェーズに合格した状態でフェーズ 7 に合格していることです。フェーズ 7 以外で許容される唯一の停止理由は、ローカルでは解決できない実際の外部ブロッカーがあり、それが現在のフェーズの成果物と task-workflow/open-gaps.md に完全に記録されていることです。

自律実行の契約

<autonomous_run_contract>

これらのルールは常に有効なものとして扱ってください。

ゲートと成果物のルール

• 各フェーズは、客観的なゲートで終了する必要があります。
• 各ゲートは、そのフェーズが管理する成果物ファイルに記録する必要があります。
• 各ゲートには、数値のしきい値と、重要項目の合格要件の両方が必要です。
• ゲートに不合格の場合は、そのフェーズにとどまって反復を続けます。
• ゲートの不合格は「修正してループする」ことを意味し、「停止して報告する」ことではありません。
• ゲートに合格したら、次のフェーズをローカルで開始できる場合は、直ちに次のフェーズへ進みます。
• task-workflow/CURRENT_PHASE.txt は再開位置を示すポインターにすぎません。以前のフェーズに合格した証拠ではありません。
• task-workflow/progress.md は、再開に必要な情報を簡潔に記録する台帳です。ゲートに合格した証拠ではありませんが、コンテキスト圧縮後に実行を再開できるよう、最新の状態を保つ必要があります。
• 各フェーズの開始後、重要な Phase 2 作業パケットの作成後、フェーズのゲート結果の確定後、ブロッカーの発見後、フェーズの昇格後に、task-workflow/progress.md を更新し、現在のフェーズ、該当する場合は最初に不合格となったフェーズ、最後に完了したゲート、次にローカルで行うアクション、関連コンテキストの簡潔な要約を記載します。
• task-workflow/progress.md の Current Phase Pointers、Phase Artifact Index、Artifact Pointers は最新の状態に保ちます。現在のフェーズの成果物、現在のフェーズの参照資料、重要度の高いアクティブなファイルのみを示す必要があります。調査済みファイル、編集済みファイル、Playwright、スクリーンショット、ログ、テストの一覧全体をフェーズ成果物から progress.md に重複して記載しないでください。
• コンテキスト圧縮後、再開時、再試行時、再接続時、または新しいコーディングセッションの開始時には、次のアクションを選ぶ前に、この SKILL.md、task-workflow/progress.md、task-workflow/CURRENT_PHASE.txt、現在のフェーズの成果物、task-workflow/open-gaps.md、現在のフェーズで必須となる参照ファイルを読み直します。内容に食い違いがある場合は、フェーズ成果物を確認し、最初に不合格となったフェーズから続行します。
• フェーズの成果物に Decision: Pass、合格スコア、重要項目の全合格が記録され、ゲートまたは必須の証拠セクションにプレースホルダーの Pending 行が残っていない場合にのみ、そのフェーズは現在のフェーズのマーカーを次のフェーズに進めることができます。
• 現在のフェーズのマーカーは、そのフェーズの作業を始める前に記録する必要があります。このマーカーは、フェーズ作業後の単なる後処理ではありません。
• 次のフェーズのマーカーを書く前に、現在のフェーズの成果物を開き直し、昇格条件が成果物内に明記されていることを確認します。
• 新しいフェーズのマーカーを書いた直後に、そのフェーズで必須となる参照ファイルを読んでから、そのフェーズの作業を始めます。
• CURRENT_PHASE.txt が、最初に不合格となったフェーズの成果物より先を示している場合は、成果物のゲート判定を優先します。CURRENT_PHASE.txt を最初に不合格となったフェーズに戻し、そのフェーズから続行します。
• 成果物テンプレートに記入する際は、必須の意味カテゴリごとに監査可能な証拠を残します。同じ証拠が明確で採点可能な状態を保てる場合に限り、行の文言を簡潔にしてもかまいません。
• task-workflow/open-gaps.md はゲート成果物です。後続フェーズは、同じフェーズ内でギャップ台帳を更新しない限り、ギャップが解消されたと判断できません。
• 担当フェーズまたは次のアクション欄に記載されたフェーズが完了した後、ギャップを Open のまま残してはいけません。後続フェーズで作業が完了した場合は、ギャップを Resolved Gaps に移します。ギャップが実在しない場合は、証拠を添えて再分類するか、クローズします。
• Phase 0 の後、task-workflow/open-gaps.md に Pending などのテンプレート用プレースホルダー行を残してはいけません。ギャップがない場合は、プレースホルダー行を明示的な None currently recorded 行に置き換えます。
• 重要なギャップが Open のまま、古くなった状態、または他のフェーズ成果物と矛盾する状態で残っている場合、Phase 7 は合格できません。

検証ファイルのルール

• Phase 5 と Phase 6 では、合格とする前に、対話型スクリプトと E2E テストに固定待機がないか確認する必要があります。
• task-workflow/playwright または tests/e2e に固定待機がある場合は、ゲート不合格です。正当化しないでください。locator.waitFor(...)、expect(locator)...、waitForURL(...)、waitForResponse(...) などの決定的な Playwright の待機やアサーション、または永続化された状態のアサーションに置き換えてから、検証を再実行してください。
• Phase 5、Phase 6、Phase 7 は、確認した検証ファイルに固定待機がないこと、および代わりに使用した決定的な待機やアサーションを成果物に記載している場合にのみ合格できます。
• 後の作業で前のフェーズの証拠不足が判明した場合は、その前のフェーズに戻って修正し、ゲートを再通過してください。

書き込みとコマンドのルール

• ゲートに関わるファイルの書き込み、パッチ適用、生成ファイルの作成、または成果物の更新を行うたびに、それを根拠として利用する前に読み戻しチェックを実施してください。sed、rg、ls、git diff、またはリポジトリで通常使用する確認コマンドを使い、ファイルが存在し、意図した変更が含まれていることを確認してください。
• 書き込み／編集ツールが無効な書き込み、ファイルの欠落、パッチの失敗、出力の一部欠落、または結果が不確かな状態を報告した場合は、その作業単位を止め、対応している編集方法で書き込みを修復し、読み戻してから続行してください。書き込みに失敗したのに成功したものとして進めてはいけません。
• コマンドの実行時間は制限してください。長時間稼働するサーバー、ウォッチャー、対話型コマンドを、アクティブなツール呼び出しとしてフォアグラウンドで動かし続けてはいけません。
• 本番／ライブワークスペースのデータベースをテストまたは検証用の状態として使ってはいけません。このスキルでは、「本番データベース」とは .dbs/database.db、リポジトリでライブ／デフォルトのユーザーデータベースとして指定されているもの、または分離されたテスト／E2E 設定以外で通常のアプリが使用するデータベースパスを指します。.dbs/database.db または本番／ライブデータベースに対して許可される操作は、実際のスキーマ変更に必要なリポジトリ指定のアプリケーションマイグレーションコマンドを、そのマイグレーションを担当するフェーズで実行し、マイグレーションの証跡として記録することだけです。これはマイグレーション実行に限った例外であり、本番 DB で作業してよいという許可ではありません。タスクでマイグレーションを作成または変更した場合、Phase 3 で昇格する前に、リポジトリ指定のアプリケーションマイグレーションコマンドを本番／ライブのデフォルト DB に対して実行することが必須です。ユーザーは完成したアプリをすぐに使うため、マイグレーションが未適用だと変更が反映されないか、動作しなくなります。それ以外の本番／ライブ DB 操作は禁止です。手動クエリ、データ操作、シード、リセット、フィクスチャ、Playwright、E2E、プローブ、デバッグ、クリーンアップ、rm、truncate、直接の SQLite 操作、独自のデータ修復、書き込みリスクを伴うデータ確認は行わないでください。コマンドが本番データに触れる可能性があり、実際のスキーマ変更に対するリポジトリ指定のマイグレーションコマンド、または分離されたテスト DB 操作であることを成果物から確認できない場合は、実行しないでください。
• Phase 5 と Phase 6 以外で、API／ランタイムのプローブに一時的な開発サーバーが必要な場合は、task-workflow/scripts/server-probe.mjs を使用してください。このスクリプトが PID の取得、準備完了の確認、時間制限付きのプローブコマンド、ランタイムログ、PID のみを対象とするクリーンアップを管理します。サーバーの準備完了には通常 5～10 秒かかります。通常の上限は 15～20 秒、起動準備の最大上限は 30 秒です。プロセス名による広範なクリーンアップは、PID／ポートによるクリーンアップが不可能な場合に限り、サンドボックス内で所有するプロセスの復旧として明示的に行い、その理由を成果物に記録してください。
• Phase 5 と Phase 6 では、実行中のアプリを必要とする最初のブラウザー、Playwright、または E2E コマンドで、原則として task-workflow/scripts/playwright-lifecycle.mjs を使ってライフサイクルの所有権を確立してください。まず既存と思われるサーバーに接続し、その後に fetch failed、古いデータ、リダイレクト、誤ったビルド出力などを根拠に手動サーバー管理が必要だと推測してはいけません。
• 既存のリポジトリ E2E テストがあっても、ヘルパーを迂回する理由にはなりません。原則として pnpm exec playwright test ... はヘルパーの --run を通して実行してください。ヘルパーがそのコマンドのサーバーを管理できない場合に限り、原因を診断したうえで、リポジトリの webServer によるネイティブ Playwright を使用し、実行前にその理由を記録してください。
• ヘルパーの --env はデータベースパスの上書き手段ではありません。ヘルパー、セットアップ、サーバー、実行コマンドで E2E_DATABASE_FILE_PATH、DATABASE_PATH、DB_PATH、または同様のデータベースファイル／パス環境変数を設定してはいけません。エージェントはリポジトリ内部の E2E／エンドツーエンド用データベースファイルのパスを変更してはいけません。テスト DB のパスは、リポジトリにチェックインされた E2E／エンドツーエンド設定、またはすでに具体化されている環境から取得してください。.dbs/database.db はライブワークスペース／本番データベースです。本番データベースをテストに使ってはいけません。Playwright、E2E、フィクスチャ、シード、リセット、確認、クリーンアップ、デバッグで .dbs/database.db を使うことは、task-workflow/ 内だけで使われている場合でも重大な失敗です。このデータベースが削除または破損すると、ユーザーが職を失うおそれがあります。
• 検証のライフサイクルでは、Phase 5 または Phase 6 を実行する前に、AGENTS.md、package.json、README／ドキュメント、Playwright 設定、tests/e2e ヘルパーから、リポジトリが指定するセットアップコマンドとサーバーコマンドを確認してください。テスト DB のみをリセットし、テスト用マイグレーションを適用し、決定的な検証データをシードする、分離された E2E／テスト状態を準備するリポジトリ指定のセットアップコマンドと、その分離状態を使ってアプリを起動するリポジトリ指定のサーバーコマンドを優先してください。対象リポジトリにこのパターンの名前付きスクリプトがない場合は、最小限のリポジトリ指定／テスト専用コマンドで同じ手順を構成し、実行前にその対応関係を記録してください。本番 DB への書き込み、DB パスの直接上書き、手動クリーンアップの連鎖で代用してはいけません。
• Phase 5 または Phase 6 で、手動のサーバークリーンアップ、固定時間の待機、DB 削除、サーバー起動、Playwright コマンドを連結して実行してはいけません。ヘルパー管理の実行では、分離されたテスト DB のリセット、テストマイグレーション、テストシード、テスト DB の準備といったサーバー起動前のセットアップを、ライフサイクルの --setup "..." に含めてください。現在の検証バッチでは、セットアップとサーバー起動を再利用可能なものとして扱ってください。必要なスクリプト／spec コマンドをまとめてヘルパー管理で一度実行することを優先し、コード、マイグレーション、フィクスチャ、DB 状態、ビルド入力、または直前のセットアップ出力が変わった場合にのみセットアップを再実行してください。次の E2E コマンドを実行するからという理由だけで、毎回 DB を削除／再作成したりサーバーを再起動したりしてはいけません。クリーンアップが必要な場合は、記録を残した独立した復旧手順としてヘルパーの実行前に行い、その後はヘルパーだけを実行してください。サーバー状態、DB 状態、ポートの所有権、またはビルドの鮮度に問題があるように見える場合は、まず現在のライフサイクル所有者のログと準備状況を通じて診断し、コード／セットアップを修正した後、同じ所有者経由で再実行してください。ヘルパーがタイムアウトする、または有用な出力を生成しない場合は、ライフサイクル／セットアップの証跡として扱い、task-workflow/runtime/server.log、task-workflow/runtime/setup-*.log、準備状況の出力、task-workflow/runtime/run-*.log を確認してから、セットアップ、サーバーコマンド、準備完了 URL、テストコマンド、フィクスチャ、または診断方法を変更して再実行してください。診断済みのライフサイクル／ツールの問題によりヘルパーが 1～2 回失敗した場合は、ヘルパーのログを記録し、検証を証明できる最小限の代替方法に切り替えてください。代替方法には、リポジトリの Playwright webServer、明示的な PID／ポートのクリーンアップ、または PID／ログ／準備状況／クリーンアップの証跡を取得した手動サーバー管理があります。プロセス名による広範なクリーンアップは、PID／ポートによるクリーンアップが不可能な場合に、記録を残したサンドボックス復旧としてのみ許可されます。
• タスクの検証中に playwright install、playwright install chromium、または同等のブラウザーのダウンロードを実行してはいけません。管理対象のライフサイクルヘルパーは、利用可能な場合に PLAYWRIGHT_BROWSERS_PATH=/ms-playwright を設定し、プロジェクトの Playwright バージョンがサンドボックスのブラウザーキャッシュと一致しない場合は早期に失敗します。

フェーズごとのコマンド実行ルール

• フェーズ 2 では、アーティファクト、読み戻し、差分、検索、限定的なブロック解除コマンドの証拠を厳密にそろえて、実装パケットを完了します。通常のチェック、lint、ビルド、unit/Vitest、E2E、Playwright、pnpm run check などのリポジトリ一括チェックコマンドは、具体的なコンパイル／型の問題が現在のパケットを妨げ、その問題をコマンド実行前に記録した場合を除き、担当する後続フェーズに委ねます。
• フェーズ 3 では、関連箇所を確認し、実装漏れを解消し、実装の完全性をレビューしたうえで、順序立てたチェック／ビルドのチェックポイントを担当します。実行するのは、リポジトリのチェック、有用な場合の対象を絞った lint、リポジトリでビルドが別途用意されている場合はビルドです。対象を絞った診断や限定的な修正確認は、特定の問題グループを立証する場合にのみ使います。広範なチェック／ビルドコマンドが失敗した場合は、確認できる問題グループを特定するのに十分な出力を調べ、広範なコマンドを再実行する前に、ローカルで修正可能なすべてのグループを修正します。記録するのは、グループ、修正、再実行の理由のみです。確認できる問題グループがほかにも残っているのに、細かな修正のたびに広範なコマンドを再実行してはいけません。トリアージに一時ログが必要な場合を除き、巨大なコマンドログを残してはいけません。一時的な全出力ログは、問題グループを抽出した後に削除します。ユニットテスト／E2E の網羅性に関する検討事項は、担当する後続フェーズに記録します。
• フェーズ 4 では、ユニットテストの網羅性を担当します。ユニット、サービス、コンポーネント、統合形式のテストのいずれが妥当かを判断し、そのうえで追加、更新、削除、または明示的なスキップを行います。既存のユニットテストが、コアではない、複雑ではない、古くなっている、または複雑に入り組んだ動作を対象としており、削除によってテストスイートが改善される理由をアーティファクトで説明できる場合は、削除してもかまいません。フェーズ 3 の証拠が最新である場合、フェーズ 4 ではチェック、lint、ビルドを再実行しません。
• 後続のフェーズでは、コード、設定、依存関係／ビルド入力、マイグレーション、生成アセット、古い出力、または互換性のない検証ツールによって証拠が無効にならない限り、フェーズ 3 のビルド証拠を再利用します。準備、再確認、安心のためだけに、フェーズ 4、フェーズ 5、フェーズ 6、フェーズ 7 でビルドを再実行してはいけません。
• フェーズ 6 では、E2E の網羅性を担当します。E2E の網羅性が妥当かを判断し、そのうえで追加、更新、削除、または明示的なスキップを行います。既存の E2E テストが、コアではない、複雑ではない、古くなっている、不安定、または複雑に入り組んだ動作を対象としており、削除によってテストスイートが改善される理由をアーティファクトで説明できる場合は、削除してもかまいません。
• ユニットテスト、E2E、またはブラウザー関連の作業を担当フェーズより前に行った場合は、そのタイミングだけを理由にタスクを失敗としないでください。アーティファクト、差分、コマンド出力を担当フェーズに引き継ぎ、昇格前に、担当フェーズで削除／更新／追加／スキップの判断を確定してください。

テストと再実行に関する最小限のルール

テストは本番コードです。テストを増やしても、害のない証拠が得られるわけではありません。保守負担となり、誤った安心感をもたらすリスクがあり、将来のワークフローを妨げる要因になります。

フェーズ 4 とフェーズ 6 では、テスト作業を「テストを増やせば安全」という手順ではなく、テストを精選し、最小限の網羅性を判断する作業として扱ってください。

ルール	必須の動作
既存のテストも例外ではありません	以前のエージェントが不要、時代遅れ、壊れやすい、複雑すぎる、重複している、または中核ではないテストを追加していた場合、現在変更された動作に関連するものは、担当フェーズで削除または簡素化する必要があります。
新しいテストは例外です	動作が安定した中核的なものであり、関連する既存のテストでは正当なアサーションを適切に追加できないことを証明した後に限り、新しいテストを追加してください。
追加のテストに合格しても品質の証拠にはなりません	合格数が多くてもゲートの評価は上がりません。ゲートでは、必要なカバレッジ、有用なアサーション、不適切なテストの削除を重視します。
テストの肥大化は警告サインです	テストの追加によって最大行数、フィクスチャの頻繁な変更、ヘルパーの頻繁な変更、コマンドの実行時間の増加、広範な再実行、新たな保守構造が生じる場合は、いったん止め、テストを統合、削減、既存テスト内で更新、または削除すべきか再評価してください。自ら招いたテストの肥大化を、すべてのテストが依然として必要であることを成果物が証明しない限り、構造をさらに追加して解決してはいけません。
新しいテストにはそれぞれ負担の記録が必要です	新しいユニットテストまたは E2E テストのケース／ファイルごとに、中核となるリスク、調査した関連する既存テスト、更新・削除・N/A では不十分だった理由、アサーションが最小限である理由、却下したより低コストな検証方法を記録してください。

• テストは最小限にしてください。中核となる動作や重要なワークフローを保護するために必要な、最小限のテストを優先してください。付随的な動作を対象とするテストが多すぎるのは、品質の証しではなく、コードベースの問題です。
• E2E では、Phase 6 の判断に基づいて実施する必要がある、新規または変更されたテスト、および直接関連するテストのみを実行してください。タスクで E2E 全体の実行が明示的に求められている場合、または具体的なリポジトリ内の指示で今回のタスクに限り E2E 全体／全テストの実行が指定されている場合を除き、フィルターをかけずに E2E テスト全体を実行してはいけません。リポジトリに Playwright のテストスイート、webServer、または「テストを実行する」スクリプトがあるだけでは、実行の根拠になりません。必要な対象限定または関連 E2E テストが成功し、関連するコード、テスト、設定、フィクスチャ、マイグレーション、ビルド入力に変更がない場合、最終的な確信、最終承認、状態の確認、またはレビュアーを納得させるための証拠として、E2E テスト全体の実行を追加してはいけません。
• 対象を限定した単一の Playwright スクリプトまたは E2E テストでは、タイムアウトを延ばすことは再試行の戦略ではありません。実用上最小のタイムアウトから始めてください。Phase 5 の起動／ページ状態／カスタムスクリプトのプローブには 15000～20000 ms、Playwright ランナーの起動オーバーヘッドが加わる Phase 6 の初回対象限定 E2E には最大 30000 ms を設定します。有用なエラー、アサーションの出力、未検出状態、コンソール／ランタイムエラー、ルートエラー、フィクスチャ／DB の不足、またはヘルパーの診断結果を伴って実行が失敗した場合は、その証拠を使って原因を診断してください。タイムアウトを延ばして再試行してはいけません。タイムアウトを延長できるのは、初回実行が有用な応答や説明のないまま、タイマーの期限切れだけを理由に終了した場合に限ります。またその場合も、ヘルパーのログ、準備状態、URL、未検出／エラー状態、必要な DB／フィクスチャのレコード、サーバーのランタイムログ、ブラウザーのコンソール、ネットワーク／ページの状態から、アプリとテストが実行可能な正しい状態にあることを確認した後に限ります。その場合に限り、60000 ms で一度だけ再実行できます。対象を限定した単一のスクリプト／テストで 120000 ms を超えてはいけません。対象を限定した単一の実行に 2 分を超えて要する場合は、タイムアウトの延長をやめ、まず検証処理の分割、またはライフサイクル、セットアップ、フィクスチャ、ページ状態、コンソール、ネットワーク、テスト設計の問題を診断してください。
• 確信を得ることだけを目的にテストを再実行してはいけません。品質に関する証拠が変わり得る場合に再実行してください。たとえば、関連する実装、テスト、設定／環境が変更された場合、前回の出力が不完全または古い場合、あるいは実際の失敗を修正するために、次の実行でより絞り込んだ診断情報を収集する場合です。
• 同一の失敗したテストコマンドを再実行する前に、前回の実行から何が変わったか、または再実行でどのような新しい証拠を収集するのかを記録してください。何も変わっておらず、前回の出力が完全な場合は、まずログ、DOM／状態、トレース、スクリーンショット、または永続化されたデータを調べてください。その後、実装、テスト、コマンドの対象範囲、または診断方法を変更してから再実行してください。既存の問題や実行順依存の失敗が疑われるだけでは、テストスイート全体に範囲を広げる理由になりません。失敗したテストを絞り込んで実行し、ログ／状態／トレースの証拠を使って原因を立証してください。対象範囲内の問題であれば修正し、範囲外の問題であれば、適切な根拠とともに未解決事項として記録してください。
• Phase 5 および Phase 6 の成果物には、ゲートを通過する前に、タイムアウトの値と、応答のない実行／タイムアウトに関するトリアージを記録する必要があります。Phase 5／Phase 6 の予算を超える、初回の対象限定 Playwright コマンドや、タイマー期限切れのみの失敗と状態が正常であることのトリアージを記録せずに行うタイムアウト延長後の再実行は、ゲート失敗となります。
• コマンドが停止またはアイドル状態に見え、次のワークフローの手順をローカルで実施できる場合は、コマンドを停止し、現在のフェーズの成果物または未解決事項一覧に証拠を記録してから、範囲を限定した復旧手順に進んでください。

継続ルール

• 各フェーズのゲートは内部の制御ポイントであり、ユーザーへの確認を求めるチェックポイントではありません。
• フェーズのゲートに合格した場合は、続行するかどうかを尋ねず、次のフェーズへ直接進んでください。
• フェーズのゲートに不合格となった場合は、そのフェーズをやり直し、ゲートを再実行し、ユーザーに続行の許可を求めずに繰り返してください。
• ゲート、再実行、検証、手直しのループは、実行中にユーザーの確認を不要にし、エージェントが実行を自律的に完了できるようにすることを目的としています。
• フェーズで不合格となった成果物は修正チケットであり、停止点ではありません。Decision: Fail、Score: 0/...、未処理のゲート項目、またはローカルで修正可能な未解決の警告を残したままフェーズを終え、最終回答を作成しないでください。
• 依存関係、起動の詳細、またはローカルのセットアップ上の問題によって進行が妨げられている場合は、ワークフローを維持できる、最も直接的で論理的な解決策で対処し、続行してください。
• 対象リポジトリまたはサンドボックス内で解決できる環境上の問題を理由に、スキルの厳格さを緩めたり、ゲートを省略したり、方針を変えたりしないでください。
• いずれのフェーズの後も、進捗を要約して続行するかどうかを尋ねるために停止しないでください。
• 実装、ビルド、リント、テスト、Playwright の検証、または E2E 作業の後も、後続のフェーズが未合格で、ローカルで実行可能な場合は停止しないでください。
• ユーザーが近道を見つけると想定しないでください。エージェント自身が近道を防がなければなりません。

</自律実行契約>

最終応答ガード

最終応答、停止メッセージを出力する前、またはユーザーに制御を戻して OpenCode のターンを終了する前に、成果物ファイルに対して次のガードを実行してください。

1. task-workflow/CURRENT_PHASE.txt は phase-7-final-signoff でなければなりません。
2. task-workflow/progress.md には、現在のフェーズが phase-7-final-signoff であること、最後に完了したゲートが Phase 7 であること、最終応答以外に次のローカルアクションがないことを記載しなければなりません。
3. task-workflow/progress.md には、現在のフェーズへのポインター、フェーズ成果物のインデックス、詳細な証拠の所在を示す成果物ポインターを含めなければなりません。
4. task-workflow/progress.md でフェーズ成果物のファイル一覧全体を重複して記載してはいけません。再開にすぐ必要な、重要度の高いアクティブなファイルのみを記載できます。
5. task-workflow/progress.md には、コンテキスト圧縮後に読み直すリポジトリ相対の指示／コンテキストファイルを記載しなければなりません。これには AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ 内の関連タスク添付ファイル／補助ファイル、および Phase 1 で選定した .agents/skills/ 内の関連する利用可能なスキルファイルのみが含まれます。
6. 必須のフェーズ成果物はすべて Decision: Pass でなければなりません。
7. 必須のスコアはすべてしきい値を満たさなければなりません。
8. すべてのゲート行には、Pending やテンプレートの既定値ではなく、具体的な証拠を記載しなければなりません。
9. task-workflow/open-gaps.md に、重大な未解決事項、合格済みフェーズが担当する古い未解決事項、またはプレースホルダー行があってはなりません。
10. Phase 5、Phase 6、Phase 7 には、検査した検証ファイルに固定待機が含まれていないことを示す固定待機レビューの証拠を記録しなければなりません。
11. Phase 5 と Phase 7 には、Phase 5 で引用したすべてのスクリーンショットパスについて、スクリーンショットの存在を証明する記録を含めなければなりません。
12. Phase 4 でユニットコマンドが必要な場合、または Phase 6 で E2E コマンドが必要な場合、そのフェーズと Phase 7 に、コマンドの正確な出力、または正確な出力と最終的な合否行を含むリポジトリ内のログファイルを記録しなければなりません。ユニットテスト／E2E テストが不要な場合は、担当フェーズと Phase 7 に N/A のカバレッジ判断を記録しなければなりません。テストを削除する場合は、担当フェーズと Phase 7 に、削除理由および差分／読み戻しの証拠を記録しなければなりません。
13. Phase 5、Phase 6、Phase 7 には、タイムアウトになった、出力がない、またはより長い再実行を行ったすべての Playwright／E2E コマンドについて、タイムアウト値とタイムアウト／無出力実行のトリアージ証拠を記録しなければなりません。
14. Phase 3 と Phase 7 で、変更したアプリ／サーバーのソースに残存する console.* がないことを確認しなければなりません。一時的な console.* は、ブラウザー／ランタイムの挙動をデバッグするためにコンソール出力を直接読み取る必要がある場合に限り、Phase 5 の対話テスト中に使用できます。また、Phase 5 の再実行、Phase 3 の再合格、または Phase 7 の承認前に削除しなければなりません。
15. Phase 7 の最終品質スコアカードは、すべてのカテゴリで 8/10 以上でなければなりません。
16. Phase 7 には成果物の整合性レビューを記録しなければなりません。このレビューでは、すべてのフェーズ成果物を再度開き、成果物の存在、Decision: Pass であること、スコアがしきい値を満たすこと、必要な証拠行がすべて記入されていること、CURRENT_PHASE.txt、progress.md、open-gaps.md と矛盾していないことを確認します。
17. .tasks/task.md またはプロンプトに記載された MITB 完了コマンドは、Phase 7 の監査チェックがすべて合格した後にのみ実行しなければなりません。これを最終的な外部タスクアクションとして扱い、タスク完了前にすべてのチェック、テスト、ビルド、サーバープローブ、検証コマンドを計画して実行してください。完了前に Phase 7 のチェックが1つでも失敗した場合、エージェントは最も早く失敗したフェーズに戻り、タスク完了を呼び出してはいけません。

いずれかの項目が失敗し、ローカルで解決できる場合は、最も早く失敗したフェーズからワークフローを続行してください。タスクが完了したかのように回答してはいけません。 実際の外部要因によって完了できない場合は、実行したコマンド、確認したファイル、ローカルでの復旧では解決できない理由、次に行う最小限のアクションを含めて、現在のフェーズ成果物と open-gaps.md にその阻害要因を記録してください。

OpenCode のターン継続ガード

OpenCode またはその他のツール駆動型コーディングセッションで実行する場合、コマンドが完了した、チェックが通った、リンターが起動した、ファイルが編集された、あるいはフェーズの成果物が一時的に失敗しているというだけで、エージェントはアシスタントのターンを終了してはいけません。

ツールの実行結果を受け取るたびに、ユーザーに制御を戻す前に、次の点を確認してください。

• CURRENT_PHASE.txt は phase-7-final-signoff より前ですか？
• 必須のフェーズ成果物に Decision: Fail と記載されたものはありますか？
• 現在のフェーズゲートに Pending、0/...、または証拠の不足はありますか？
• 次に必要なワークフローアクションは、ローカルで実行できますか？

最初の3つのいずれかが「はい」で、次のアクションをローカルで実行できる場合は、同じ実行内ですぐにそのアクションを続けてください。「次はリンターを実行します」「チェックは通りました」「次に成果物を更新します」「残りの作業は……です」といった、状況を説明するだけの時点で止まってはいけません。

有効な停止状態は、次のいずれかのみです。

• フェーズ7に合格し、最終応答ガードにも合格している。
• 実際の外部ブロッカーが、現在の成果物と open-gaps.md に完全に記録されている。

セッションが長くなる場合は、フェーズ成果物を最新の状態に保ち、次のツール／アクションの実行を続けてください。ブロックされていないフェーズを完了するために、ユーザーが「続けて」と入力することを当てにしてはいけません。

重要な出力不変条件

次の制約は必ず守ってください。

• 対象アプリは、静的なモックアップではなく、実際に操作できるアプリでなければなりません。
• Phase 4 または Phase 6 のカバレッジ判断で必要とされた場合、実装は対象リポジトリ内に、実際のルート、レイアウト、コンポーネント、状態、スタイリング、バックエンドのコントラクト、サービス、クエリ、マイグレーション、テストとして作成しなければなりません。
• 主要なページやビューは、1つの大きなコンポーネント内でインメモリのページ状態を切り替えるのではなく、実際のルーターのルートまたはリポジトリ標準のルートモジュールとして実装しなければなりません。
• タスクで必須とされている、またはタスクから必要と判断される表示コントロールは、実際の対象コントロールとして実装し、状態を一致させ、永続化が必要な場合は動作を永続化しなければなりません。
• バックエンド／データの処理は、リポジトリに既存のサービス、コントラクト、クエリ、永続化の境界に従わなければなりません。
• フロントエンドのランタイムコードから、サーバー専用のランタイムモジュールをインポートしてはいけません。
• 再利用可能な UI のスタイリングは、共有プリミティブ、コンポーネント固有のスタイリング、または既存のデザイントークンに記述し、グローバルに使い捨てのコンポーネントクラスを偽装してはいけません。
• Phase 3 のチェック／リンターの証拠、Phase 4 の単体テスト作業、Phase 5 の対話的な Playwright 検証、Phase 6 の E2E 作業は、それぞれ別のゲートです。いずれも他のゲートの代わりにはなりません。
• エージェントは、アプリをパーツごと、ルートごと、状態ごと、フローごとに確認しなければなりません。
• 重要な表示アクション、ルート、データ変更、検証経路のいずれかが、偽物、壊れた状態、または未確認のまま残っている場合、その実行は合格していません。
• 新しいタスクに合格するためだけに、既存のテストを削除してはいけません。古くなったテストを削除する場合は、その有用なカバレッジを置き換えるか、古いカバレッジが適用されなくなった理由を記録してください。
• 型アサーション、広範なキャスト、警告の抑制を、正しいコントラクトと型の絞り込みの代わりにしてはいけません。
• 最終サインオフでは、機能の成果、スキル遵守／成果物の整合性、コード品質／保守性、テスト品質、全体の成果の各品質カテゴリで、少なくとも 8/10 を獲得しなければなりません。

参照ファイルの読み込みルール

<reference_loading_rules>

すべての参照ファイルを、デフォルトで読み込んではいけません。

圧縮後および再開時の再読み込みルール

圧縮後、再開後、再試行後、再接続後、または新しいコーディングセッションの開始時には、task-workflow/progress.md と task-workflow/CURRENT_PHASE.txt を使って現在の状況を確認し、その後、次のファイルを読み直してください。

1. このメインの SKILL.md
2. task-workflow/progress.md
3. task-workflow/CURRENT_PHASE.txt
4. 現在のフェーズ成果物
5. task-workflow/open-gaps.md
6. Phase Reference Map に記載されている、現在のフェーズで必須の参照ファイル
7. progress.md に記載されている、リポジトリ相対パスの指示／コンテキストファイル

圧縮後に会話の記憶に頼らないでください。progress.md と CURRENT_PHASE.txt は実行の現在位置を示しますが、メインのスキル、現在のフェーズの参照ファイル、現在のフェーズ成果物、またはギャップ台帳の代わりにはなりません。これらのファイルを読み直してからでなければ、実行を続けることはできません。

フェーズ開始時の参照ルール

フェーズが始まるたびに、新しいフェーズへの昇格直後も含め、そのフェーズの作業を始める前に必須の参照ファイルを読み込んでください。

CURRENT_PHASE.txt が変更された場合、次に行うローカル操作は Phase Reference Map で新しいマーカーに指定された参照ファイルを読み込むことです。そのファイルを読む前に行ったフェーズ作業は無効です。

新規実行時：

1. この SKILL.md を読みます。
2. フェーズ 0 を開始します。
3. references/phase-0-1-startup-research.md のみを読み込みます。

圧縮後、再開後、再試行後、再接続後、または新しいコーディングセッションの開始時：

1. この SKILL.md を読み直します。
2. task-workflow/progress.md を読みます。
3. task-workflow/CURRENT_PHASE.txt を読みます。
4. 現在のフェーズ成果物と task-workflow/open-gaps.md を読みます。
5. progress.md に記載された指示／コンテキストファイルを読み直します。これには、AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ に記録された関連する添付ファイル／補足ファイル、および .agents/skills/ から選択された関連スキルファイルのみが含まれます。
6. progress.md、CURRENT_PHASE.txt、フェーズ成果物の内容が食い違う場合は、最も早い段階で失敗したフェーズ成果物から続行します。
7. 現在のフェーズを担当する参照ファイルのみを読み込みます。
8. 現在のフェーズの参照ファイルでインタラクティブな Playwright 作業が必要とされている場合に限り、references/playwright-interactive.md を読み込みます。

フェーズ参照マップ：

現在のフェーズマーカー	読み込む参照ファイル
task-workflow/ がない	references/phase-0-1-startup-research.md
phase-0-artifact-reset	references/phase-0-1-startup-research.md
phase-1-task-research	references/phase-0-1-startup-research.md
phase-2-execution	references/phase-2-4-execution-integrity.md
phase-3-second-execution	references/phase-2-4-execution-integrity.md
phase-4-unit-coverage	references/phase-2-4-execution-integrity.md
phase-5-playwright-verification	references/phase-5-7-verification-signoff.md および references/playwright-interactive.md
phase-6-e2e-verification	references/phase-5-7-verification-signoff.md
phase-7-final-signoff	references/phase-5-7-verification-signoff.md

フェーズ参照ファイルは、フェーズごとではなく、相互に関連する作業の流れごとにまとめられています。これは、参照スキルのパターンに合致しています。SKILL.md には厳格なグローバルプロトコルを記載し、参照ファイルには現在の作業の流れに関する詳細な手順を記載します。

</reference_loading_rules>

運用モード

<operating_modes>

検証モード

スキル自体を改善またはテストするときに使用します。

• 使い捨ての対象リポジトリのコピーを使用します。
• すべてのワークフロー成果物を保持します。
• 新規実行を重ねて再現性を評価します。
• 同じ失敗が繰り返される場合は、再実行する前に再利用可能なスキルを改善します。

デリバリーモード

ユーザーが実際の対象アプリまたはタスクの完了を求めているときに使用します。

• 提供された対象リポジトリ内で作業します。
• タスクファイルを信頼できる唯一の情報源として扱います。
• このファイルとフェーズ参照ファイルに記載されたすべてのゲートを文書で通過するまで、サインオフしないでください。

</operating_modes>

必須アーティファクト

以下は必須です。

• task-workflow/
• task-workflow/phase-0-artifact-reset.md
• task-workflow/phase-1-task-research.md
• task-workflow/phase-2-execution.md
• task-workflow/phase-3-second-execution.md
• task-workflow/phase-4-unit-coverage.md
• task-workflow/phase-5-playwright-verification.md
• task-workflow/phase-6-e2e-verification.md
• task-workflow/phase-7-final-signoff.md
• task-workflow/progress.md
• task-workflow/open-gaps.md
• task-workflow/CURRENT_PHASE.txt
• task-workflow/playwright/
• task-workflow/screenshots/
• task-workflow/scripts/
• task-workflow/scripts/playwright-lifecycle.mjs
• task-workflow/scripts/server-probe.mjs
• task-workflow/runtime/

assets/templates/ のテンプレートは、遵守を徹底するためのアーティファクトです。その構成をそのままコピーしてください。必須の表を文章に置き換えたり、監査可能な行がなくなるまで簡略化したりすると、実行は失敗となります。

複数フェーズのプロトコル

<multi_phase_protocol>

フェーズを順番に進めてください。

フェーズ 0：アーティファクトのリセットと足場の作成

前のタスクの task-workflow/ アーティファクトを削除し、テンプレートから必須のアーティファクトファイルを再作成して、実装ファイルが編集されていないことを証明します。

詳細な手順：references/phase-0-1-startup-research.md。

フェーズ 1：タスクの把握とコードベースの調査

タスク、ルートの AGENTS.md、.tasks/domain.md、.tasks/files/ 内のすべてのタスク添付ファイル／補足ファイル、.agents/skills/ 内の利用可能な関連スキルファイルのみ、関連ドキュメント、およびコードベースを読みます。AGENTS.md は拘束力のある開発指示として扱い、計画前にタスクに関連するルールを抽出してください。これらは参照用の入力です。読み取り、引用してください。ただし、編集してはいけません。タスクの理解、開発ルール、読み取りまたは確認したタスクファイル、選択したスキル、影響を受けるファイル、再利用するパターン、リスク、および順序立てた実装計画を記録してください。

詳細な手順：references/phase-0-1-startup-research.md。

フェーズ 2：主要な実行

調査した計画を順番に実行し、変更範囲を限定して、実装の根拠を記録します。

詳細な手順：references/phase-2-4-execution-integrity.md。

フェーズ 3：2 回目の実行、整合性、およびチェック／Lint の検証

実装を継続作業として見直し、不足または不十分な作業を補完して、関連する UI／API／データの各サーフェスに一貫性を反映し、実装の整合性レビューを実施して、順序立てられたチェック／ビルドの確認を完了します。フェーズ 3 では、ユニット／Vitest テストや E2E テストを作成または実行してはいけません。

詳細な手順：references/phase-2-4-execution-integrity.md。

フェーズ 4：ユニットテストのカバレッジ判断と検証

ユニット、サービス、コンポーネント、または統合形式のテストが必要かどうかを判断します。そのカバレッジを追加、更新、削除、または明示的にスキップし、妥当なユニットレベルのコマンドのみを実行します。不要、時代遅れ、複雑すぎるテストや、コアではない／複雑ではない動作を保護するテストは削除してください。

詳細な手順：references/phase-2-4-execution-integrity.md。

フェーズ 5：Playwright による対話的な検証

スタンドアロンの対話型 Playwright スクリプトを 2 段階で使用します。第 1 段階では、実際のユーザー操作を通じて変更後の動作が機能することを証明します。第 2 段階では、UI の品質を検証します。影響を受ける画面に、壊れている、窮屈、重なっている、クリップされている、配置が不適切、またはレスポンシブでない UI がないことを確認します。レスポンシブデザインはフェーズ 5 の最優先の保証事項であり、タスクの機能変更が動作することの証明と同等に扱います。ある程度の余白は問題ありませんが、1920x1080 などの一般的なデスクトップビューポートで、UI が壊れている、クリップされている、重なっている、使用できない、または余白が過剰に広いように見えてはいけません。2560x1440 などの大きなデスクトップビューポートでは、余白が多少増えてもかまいませんが、UI が未完成に感じられるほど広範囲に空白があってはいけません。レイアウトが意図的に制約されていて、一貫性が保たれている場合は、非常に大きな 4K／ウルトラワイド画面での余白は許容されます。

フェーズ 4／フェーズ 6 のテスト最小化ルールによって、フェーズ 5 の範囲が縮小されることはありません。フェーズ 5 はユーザー向け検証の主要なフェーズであり、変更されたフロー、関連する異常ケース、周辺の UI、レスポンシブのブレークポイント、スクリーンショット、視覚的な正確性を確認するために必要な時間をかけてかまいません。影響を受けるユーザーエクスペリエンスが正しいことを証明するため、必要に応じて、対象を絞った複数の Playwright スクリプト、調査、ビューポート別の確認、再実行を行ってください。変更箇所とその周辺に範囲を限定しつつ、フェーズ 5 を浅いスモークテストに縮小してはいけません。

詳細な手順：references/phase-5-7-verification-signoff.md および references/playwright-interactive.md。

フェーズ 6：E2E カバレッジの判断と検証

E2E カバレッジの判断を行います。まず既存の E2E カバレッジを確認し、妥当な中核フローがすでに対象となっている場合は更新してください。既存のテストでは適切にカバーできない、重要または複雑なワークフローに限って新しい E2E テストを追加してください。中核ではないフロー、複雑ではないフロー、または過度に複雑なフローを保護する不要な E2E テストは削除し、変更が小規模、視覚的なもののみ、または付随的な UI 変更の場合は E2E を避けてください。

詳細な手順：references/phase-5-7-verification-signoff.md。

フェーズ 7：最終監査と承認

すべての成果物を読み直し、最後の編集後もこれまでのすべてのゲートが通過していることを確認し、最終差分をレビューしてください。すべてのフェーズ 7 監査チェックに合格した後に限り、必要な MITB 完了コマンドを実行し、成果物の記録によって完了が証明されている場合に限って承認してください。

フェーズ 7 は、見落とされた作業を検証するためのものであり、検証を再実行するフェーズではありません。必要なチェック、ビルド、テスト、Playwright の実行、E2E の実行、その他フェーズごとに実行すべきコマンドが、担当フェーズで正しく完了しており、その証拠が最新である場合、フェーズ 7 ではその証拠を確認するだけにしてください。担当フェーズで必要なコマンドを実行し忘れた場合、記録された証拠が欠落、不完全、または古い場合、あるいは後続の変更によって証拠が無効になった場合に限り、コマンドを再実行してください。それ以外の場合、フェーズ 7 ではチェック、ビルド、テスト、Playwright、E2E を決して再実行してはいけません。

詳細な手順：references/phase-5-7-verification-signoff.md。

フェーズの参照資料は、任意の補足資料ではありません。現在の作業ストリームにおける詳細な実行手順です。

</multi_phase_protocol>

禁止される近道と自動失敗

<automatic_fails>

以下に該当すると、実行は自動的に失敗します。

フェーズ境界と成果物に関する失敗

• フェーズ 1 に合格する前にアプリ／ソースファイルを編集する
• フェーズ 0 の成果物が存在する前にアプリ／ソースファイルを編集する
• task-workflow/CURRENT_PHASE.txt に phase-0-artifact-reset または phase-1-task-research と記載されている間に、実装／ソースファイルを編集する
• task-workflow/phase-2-execution.md に、ソース編集前にマーカーが phase-2-execution に設定されたことが記録されていない状態で、フェーズ 2 に合格する
• 成果物のリセットを省略する
• 実装作業前に成果物テンプレートをコピーしない
• task-workflow/progress.md を作成しない、コンテキスト圧縮後に読み直さない、または作業を再開できる程度に最新の状態に保たない
• コンテキスト圧縮後、再試行後、再接続後、または新しいコーディングセッションで、task-workflow/progress.md と task-workflow/CURRENT_PHASE.txt を使って状況を確認し、その後に SKILL.md、現在のフェーズ成果物、open-gaps.md、および現在のフェーズで必要な参照ファイルを読み直す前に作業を続行する
• フェーズマーカーの変更後、そのフェーズで必要な参照ファイルを読む前に新しいフェーズの作業を始める
• 選択したリポジトリ相対パスの指示／コンテキストファイル（AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ 内の関連タスク添付ファイル／補助ファイル、.agents/skills/ 内で利用可能な関連スキルファイルを含む）を task-workflow/progress.md に記録して読み直さない
• AGENTS.md を単なるコンテキストとして読み、そこに定められたタスク関連の開発ルールを抽出して従わない
• ユーザー／タスクがその参照ファイル自体の編集を明示的に要求していないのに、.tasks/task.md、.tasks/domain.md、.tasks/files/、.agents/skills/ 内で選択したスキルファイル、または AGENTS.md を編集する
• task-workflow/progress.md の Current Phase Pointers、Phase Artifact Index、または Artifact Pointers が古い、欠落している、またはフェーズ成果物と矛盾した状態のままにする
• task-workflow/progress.md を、詳細を記載する成果物への参照ではなく、ファイル一覧の重複として使う
• そのフェーズに合格したと主張しながら、フェーズ成果物に必要な意味上の証拠を記載しない
• 現在のフェーズまたはそれ以前のいずれかのフェーズ成果物に Decision: Fail と記載されている状態で、task-workflow/CURRENT_PHASE.txt を先に進める
• 現在のフェーズまたはそれ以前のいずれかのフェーズ成果物に、ゲートの証拠としてプレースホルダーの Pending が残っている状態で、task-workflow/CURRENT_PHASE.txt を先に進める
• 成功したと主張しながら、成果物テンプレートの大部分を空欄のままにする
• 成果物で引用したスクリーンショットのパスが存在しない、または存在証明で確認されていない状態で、フェーズ 5 に合格する
• 必須の E2E 実行について、正確なコマンド出力が成果物または引用したリポジトリ内のログファイルに記録されておらず、説明だけが記載されている状態で、フェーズ 6 に合格する
• フェーズ 5 またはフェーズ 6 の Playwright／E2E コマンドを、適切なライフサイクル所有者の記録なしに実行する。デフォルトでは helper を使用し、リポジトリの Playwright webServer または手動のフォールバックを使うのは、コマンド実行前に理由／診断が記録されている場合に限る
• .dbs/database.db、リポジトリのデフォルトのユーザーデータ DB パス、および同等の稼働 DB パスを含む、本番／稼働ワークスペースのデータベースをテスト／検証状態として削除、リセット、再シード、切り詰め、直接変更、または使用する
• 実際のスキーマ変更に必要な、リポジトリ指定のアプリマイグレーションコマンド以外の本番／稼働 DB 操作を実行する。禁止される操作には、.dbs/database.db または同等の稼働 DB パスに対する手動クエリ、データ操作、シード、リセット、フィクスチャ、Playwright、E2E、デバッグ、クリーンアップ、直接の SQLite 操作、カスタムデータ修復、削除、切り詰めが含まれる
• 実際のスキーマ変更に必要なアプリのマイグレーションとして、担当フェーズ内で明示的なマイグレーションの証拠を残す場合を除き、本番データベースのマイグレーションを実行する
• マイグレーションを作成または変更した後、リポジトリ指定のアプリマイグレーションコマンドを使って本番／稼働のデフォルト DB に適用し、対象、コマンド、理由、出力を記録せずに、フェーズ 3 に合格する

テストの衛生管理とカバレッジの失敗

• 具体的なコア動作またはリスク上の理由がないのに、小規模な修正、軽微な UI 調整、文言変更、色やスタイルの変更、間隔やレイアウトの調整、単純なボタン接続に対して、ユニットテストを追加または必須化する
• コアとなる安定した動作のテストにユニットテストを限定せず、些細なコンポーネントの分岐、付随的なボタンクリック、見た目だけの変更、一度限りの UI 動作にユニットテストを追加する
• Phase 4 で削除可能と判断された後も、不要、古い、複雑すぎる、またはコアではない／複雑ではないユニットテストを残す
• 既存のテストを更新できなかったこと、動作が安定したコア動作であること、および新しいアサーションがすべて最小限であることを証明する、テストごとの必要性台帳を用意せずにユニットテストを追加する
• 関連する証拠から不要、重複、脆弱、複雑すぎる、またはコアではない／複雑ではないことが分かっているのに、以前エージェントが作成したユニットテストを「すでに存在する」という理由で残す
• 不要なテストカバレッジを先に削減または削除し、残りの量が必要な理由を記録することなく、テストファイルの分割、ヘルパーの変更、フィクスチャの変更、または広範な再実行が必要になるほどユニットテストを追加する
• 重要な／コアとなるワークフローでも複雑なフローでもなく、既存の E2E カバレッジを更新すれば適切に対応できる動作に、新しい E2E テストを追加する
• Phase 6 で削除可能と判断された後も、不要、古い、脆弱、複雑すぎる、またはコアではない／複雑ではない E2E テストを残す
• 既存の E2E テストを更新できなかったこと、ワークフローが重要な／コアとなるもの、または E2E テストを行うほど複雑であること、および新しいアサーションがすべて最小限であることを証明する、テストごとの必要性台帳を用意せずに E2E テストを追加する
• 関連する証拠から不要、重複、脆弱、複雑すぎる、またはコアではない／複雑ではないことが分かっているのに、以前エージェントが作成した E2E テストを「すでに存在する」という理由で残す
• Phase 4 で必要とされる対象を絞った／関連するユニットレベルのテストがある場合に、それらに合格する前に、広範な／全体のユニットテストまたは Vitest スイートを開始する
• 対象リポジトリの指示、変更されたグローバル／共有インフラストラクチャ、または不完全／古い出力による具体的な成果物上の理由がないのに、ユニットテストまたは Vitest スイート全体を複数回実行する
• 必要な対象を絞った／関連するテストにすでに合格していることを示す Phase 4 の成果物の証拠があり、これが最終確認の 1 回である場合、またはタスク／リポジトリ／グローバルな変更で広い範囲が明示的に求められている場合を除き、広範な／全体のユニットテストまたは Vitest を実行する
• 証拠を維持し、Phase 3 を順序立てたチェック／ビルドの確認ポイントとして使用する代わりに、Phase 2 の小さな編集のたびに通常のチェック、Lint、またはビルドを実行する
• コマンド実行前に具体的なコンパイル／型のブロッカーを記録することなく、Phase 2 で pnpm run check などのリポジトリ統合チェックコマンドを実行する
• 前回の出力で確認できる、ローカルで修正可能な問題グループをすべて修正する前に、チェック、Lint、またはビルドを再実行する。問題グループが隠れている場合、出力を tail／head で切り詰めただけでは不十分であり、一時的な全出力ログは抽出後に削除する必要がある
• Phase 3 のビルドの証拠が最新で、無効化する変更が記録されていないのに、Phase 4、Phase 5、Phase 6、または Phase 7 でビルドを再実行する

Playwright と E2E コマンドの失敗

• task-workflow/scripts/playwright-lifecycle.mjs --run ... を通さず、Phase 6 でネイティブの pnpm exec playwright test ... を実行すること。ただし、リポジトリの webServer の所有権が必要であり、コマンド実行前に記録されている場合を除きます。
• タスクで E2E 全件の実行が明示的に求められておらず、このタスクで E2E 全件／すべての spec の実行を指示する具体的なリポジトリ内の記述もない場合に、フィルターをかけず Playwright／E2E スイート全体を実行すること。
• コマンドの実行先が本番環境や実際のユーザーデータではなく、リポジトリが所有する隔離されたテスト／E2E データベースであることを成果物で最初に証明しないまま、Phase 5／6 で rm、seed、migrate、sqlite3、tsx server/db/seed、フィクスチャのセットアップ、またはデータベースのクリーンアップコマンドを実行すること。
• タスク固有の成果物による理由がないまま、初回実行の対象を絞った Phase 5 Playwright スクリプトを 20000 ミリ秒超、または初回実行の対象を絞った Phase 6 E2E を 30000 ミリ秒超で実行すること。
• 有用な失敗の証拠が得られた後に Playwright／E2E のタイムアウトを延長すること。または、タイマーのみ／出力なしの失敗の後、ヘルパーログ／準備状態／URL／DB フィクスチャ／サーバーログ／ブラウザーコンソール／ネットワーク／ページ状態を記録してトリアージし、アプリとテストが再実行可能であると証明せずにタイムアウトを延長すること。
• 確認のためだけにテストを再実行すること、または実装、テスト、設定、環境、出力の古さ、診断に関する実質的な理由を記録せず、同じ失敗するテストコマンドを盲目的に再実行すること。
• タスクの検証中に playwright install、playwright install chromium、または同等のブラウザーのダウンロードを実行すること。代わりに、サンドボックスのブラウザーキャッシュを使用するか、ヘルパーのブラウザー事前チェックで不一致が検出されたことを記録してください。

継続性と証拠の失敗

• 変更したアプリ／サーバーのソースに、進行中の Phase 5 デバッグループ以外で console.* が残っている状態で、Phase 3 または Phase 7 を通過すること。
• CURRENT_PHASE.txt が phase-7-final-signoff より前の状態で、最終回答または作業終了の要約を作成すること。
• 必須の成果物に Decision: Fail と記載されている、失敗スコアがある、またはゲートの証拠が保留中である状態で、最終回答または作業終了の要約を作成すること。
• 次のワークフロー作業がローカルで実行可能な状態なのに、OpenCode のターンをフェーズの途中で終了すること。
• task-workflow/phase-2-execution.md の実行ログが空欄またはすべて Pending のまま、Phase 2 のソースファイルを編集すること。
• 複数の Phase 2 実装パケットを完了させてから、それぞれの実行ログの行をファイルの証拠で更新すること。
• 証拠の表を文章に置き換えること。
• 2 回目の実行パスを省略すること。
• Phase 3 のチェック／lint の証拠を、Phase 4 のユニットテストカバレッジの判断、Phase 5 の対話型 Playwright 検証、または Phase 6 の E2E カバレッジの判断の代わりとして扱うこと。
• Playwright 検証を、必要な Phase 4 または Phase 6 のテスト作業の代わりとして扱うこと。
• Phase 2 のゲートを完了する代わりに、Phase 5 の対話型 Playwright 検証または Phase 6 の E2E カバレッジ作業を実行すること。
• セッションが停止するまで、長時間稼働する開発サーバー、ウォッチャー、または対話型コマンドをフォアグラウンドで実行し続けること。
• ゲートに関わるファイルについて、書き込み後に読み戻した証拠がないまま、ファイルへの書き込みまたはパッチだけを根拠として扱うこと。
• 書き込み結果が失敗、不正、または不確かな場合に、対象ファイルを修復して再読込せずに作業を続けること。

最終承認の失敗条件

• 重大な未解決のギャップが残っている状態で承認する
• task-workflow/open-gaps.md に、後続のフェーズで解決済みと判断された古い未解決ギャップが残っている状態で承認する
• task-workflow/open-gaps.md に Pending などのテンプレート用プレースホルダー行が残っている状態で承認する
• 固定待機のレビュー証拠を記録せずに Phase 5、Phase 6、または Phase 7 を合格とする
• 固定待機が task-workflow/playwright または tests/e2e に残っている状態で Phase 5、Phase 6、または Phase 7 を合格とする
• すべてのフェーズ成果物について、成果物の完全性レビューを記録せずに Phase 7 を合格とする
• 最終品質スコアカードのカテゴリのいずれかが 8/10 未満の状態で承認する
• 同等の置き換えカバレッジまたは成果物に基づく根拠を文書化せずに、既存のテストを削除する
• 限定的で証拠に基づく理由なく、広範な安全でないキャストや警告抑制を使って型システムを回避する
• 状況確認や再読み込みが必要なスキル、フェーズ参照ファイル、成果物の確認に progress.md と CURRENT_PHASE.txt を使わず、圧縮後に会話の記憶に頼る
• .tasks/files/ が空の場合でも、その内容を列挙しない
• Phase 1 の計画前に .tasks/files/ 内のすべてのタスク添付ファイル／補足ファイルを読んだり確認したりしない
• .agents/skills/ 内のスキルファイルをすべて一括で読み込み、タスクに関連するスキルだけを選んで読まない
• 抽出した AGENTS.md の開発ルールに違反する作業を計画、実装、検証、または承認する
• Phase 7 の監査チェックがすべて合格する前に、MITB タスク完了コマンドを実行する
• Phase 7 の監査チェックに失敗した場合、最も早い失敗フェーズに戻らない
• Phase 7 の監査チェックがすべて合格した後に、必須の MITB 完了コマンドを実行しない
• 次のフェーズに進める状態で、フェーズ間に続行するかどうかをユーザーに尋ねる

</automatic_fails>

参照マップ

• references/phase-0-1-startup-research.md：成果物のリセット、テンプレートのコピー、タスクの受け入れ、コードベースの調査。
• references/phase-2-4-execution-integrity.md：主な実行、2 回目の実行、ギャップの解消、完全性チェック。
• references/phase-5-7-verification-signoff.md：Playwright による対話型検証、E2E カバレッジの判断、最終監査。
• references/playwright-interactive.md：このスキルでスタンドアロンの対話型 Playwright スクリプトを使用する方法。
• assets/templates/phase-0-artifact-reset.md
• assets/templates/phase-1-task-research.md
• assets/templates/phase-2-execution.md
• assets/templates/phase-3-second-execution.md
• assets/templates/phase-4-unit-coverage.md
• assets/templates/phase-5-playwright-verification.md
• assets/templates/phase-6-e2e-verification.md
• assets/templates/phase-7-final-signoff.md
• assets/templates/progress.md
• assets/templates/open-gaps.md
• assets/scripts/playwright-lifecycle.mjs：Phase 0 で task-workflow/scripts/ にコピーする、サーバーの管理／準備状態確認／Playwright 実行用ヘルパー。
• assets/scripts/server-probe.mjs：Phase 0 で Phase 5 前のサーバーチェック用に task-workflow/scripts/ にコピーする、API／ランタイムサーバー管理プローブ用ヘルパー。

必須事項

• フェーズゲートに厳密に従ってください。
• 成果物を監査可能な状態に保ってください。
• 証拠が不十分な場合は、前のフェーズに戻ってください。
• Phase 0 と Phase 1 のゲートを通過する前に、ソースファイルを編集しないでください。
• Playwright による対話型検証と回帰テストのゲートを通過する前に、承認しないでください。

完了基準

Phase 7 に合格した場合にのみ、タスクは完了です。 タスクを完了できない場合、最終成果物には、正確な阻害条件、発生したフェーズ、実行したコマンド、確認したファイル、および次に必要な最小限のアクションを記載する必要があります。