implement

implement

このスキルを使って、承認済みの PRD または範囲が明確なタスクを最初から最後まで実装します。

これは prd に対応する実行スキルです。

implement は、修正も含め、タスクを完了まで進める一連の作業を担います。検証を再実装することはせず、ループのゲートとして verify に判断を委ねます（「最終検証」を参照）。完了と判断する方法の唯一の基準は verify であり、任意の差分に対する独立した監査として単独で実行することもできます。

入力

タスクが prd によって作成された場合は、.dev/<topic-slug>/ 配下の成果物を読みます。

• prd.md - 契約です。スコープ、対象外事項、要件、受け入れ基準、タスク、検証計画が記載されています。受け入れ基準は、検証者が照合する評価基準です。
• checklist.md - タスクのチェックリストです。新たに作り直すのではなく、これを作業用チェックリストとして採用します。
• context-notes.md - プロジェクトの背景情報です。prd で確認済みの事項を再調査しないよう、これを読みます。

これらの成果物が存在しない場合（ユーザーから範囲が明確なタスク、リンクされた仕様書、または依頼が直接渡された場合）は、その単一のソース文書を参照し、そこからチェックリストを作成します。

着手前の確認

コードを編集する前に、次のことを行います。

1. 上記の入力（.dev/<slug>/ の成果物、またはフォールバック時の単一のソース文書）を読みます。
2. スコープ、対象外事項、要件、受け入れ基準、検証方法を特定します。
3. git status --short を確認します。
4. 変更する可能性が高い実際のファイルを読みます。
5. 必要な事前作業、認証情報、プロダクト上の決定、破壊的なデータ変更、または構造上の承認が不足している場合は、作業を止めて確認を求めます。

作業用チェックリスト

checklist.md がある場合は、それを作業用チェックリストとして採用します。ない場合は、ソース文書から作成します。

次の項目を追跡します。

• 要件
• 受け入れ基準
• 実装タスク
• 検証コマンド
• ブラウザーまたはランタイムでの QA シナリオ
• 人による確認事項

受け入れ基準を裏付ける証拠、または具体的な阻害要因がない限り、タスクを完了としてマークしないでください。

構造化タスクリストの準備

checklist.md が存在し、タスクが 3 つ以上ある場合は、フラットな TodoWrite ではなく、TaskCreate を使って構造化タスクリストを準備します。これにより、ループを通じて各タスクに要件との対応関係、順序、証拠を紐付けて保持できます。

checklist.md の各 T<n> タスクについて、次の手順を行います。

1. タスクを 1 つずつ TaskCreate で作成します。チェックリストのタグを metadata に引き継ぎます。
   • metadata.req - (req: ...) の ID。
   • metadata.ac - 対象タスクが担当する (ac: ...) の ID。
   • metadata.checklistId - T<n> ID。after: を解決するために使います。
2. すべてのタスクを作成した後、順序を設定します。(after: T1) タグがある場合は、依存するタスクの addBlockedBy に前提タスクのタスク ID を指定します。
3. 受け入れ基準と人による確認事項は Markdown のチェックリストに残します。タスクリストでは実装可能な作業を追跡し、基準の判定は検証者が行います。

checklist.md がない場合、タスク数が少ない場合、または変更が単純で 1 つだけの場合は、TodoWrite を使用します。些細なタスクに構造化タスクリストを準備しないでください。余計な手順に見合う価値はありません。

実装ループ

タスクは依存関係の順に進めます。構造化されたタスクリストを使用する場合は、blockedBy が空の次のタスクを選択します（checklistId が最も小さいものを優先）。ブロック中のタスクには着手しないでください。

各タスクについて：

1. 編集前に TaskUpdate でステータスを in_progress にし、進捗が見えるようにします。
2. 関連するファイルを読み直します。
3. 対応する要件（metadata.req）を満たす、最小限の変更を行います。
4. 無関係なリファクタリングは避けます。
5. ユーザーが所有するワークツリーの変更を保持します。
6. 重要な編集を行った後は、必要最小限の有効なチェックを実行します。
7. 対応する受け入れ基準（metadata.ac）を、その基準が実際に求めるレベルでその場で検証します。すべての検証を最後の段階に先送りしないでください。
   • 機械的にチェックできる基準（SQL クエリ、curl、ビルド、ユニットテスト、生成された出力など）→ 今すぐチェックを実行し、実際の出力を記録します。
   • ランタイム／ブラウザーに関する基準 → 可能であれば、検証担当者が使用するものと同じ playwright-cli を使って、その場でフローを実行します。現実の前提条件によって実行できない場合（自動化できない OAuth ログインなど）は、合格したと見なさず、具体的なブロッカーとして記録します。
8. 作業を進めながら証拠を記録します。タスクに証拠（実行したコマンド、ファイルと行番号、確認できた結果）を保存し、最終検証担当者がゼロから始めずに済むようにします。
9. 対応する受け入れ基準（metadata.ac）に実際の証拠または具体的なブロッカーがある場合に限り、ステータスを completed にします。コードを読んで動作すると推測するだけでは証拠になりません。変更の一部に未検証の点がある場合は、タスクを in_progress のままにします。

新しいタスクが必要な場合は、承認済みの要件に対応するもの、または検証／リリースの衛生管理だけを目的とするものに限り、TaskCreate で追加し、metadata.req を付与します。新たなプロダクトスコープの追加や、承認済みの構成を大幅に変更する場合は、事前に確認してください。

最終検証

まず実装を完了させます。その後、一度だけ、完了の判定を自分で行うのではなく、独立した検証担当者に委ねます。

変更を作成した同じコンテキストは、その変更を評価するのに最も適していません。そこで、ビルドが完了したら、コードを書いていない新しい検証担当者を起動し、受け入れ基準に照らして判定してもらいます。

1. Task ツールで独立した検証サブエージェントを1つ起動します。以下を渡します。
   • prd.md（またはタスク）に記載された受け入れ基準。抜粋ではなく、すべての基準を渡します。
   • PRDの「Verification - Agent」と「Verification - Human」の両セクションを、利用可能な検証方法として渡します。検証担当者はあなたと同じツールを使えます。これには playwright-cli も含まれるため、「Verification - Human」に分類された基準も自動的に対象外にはなりません。ブラウザー／API／DBの手順を人手なしで実行できる場合は、検証担当者が実行します。
   • 変更した範囲（git status --short／差分）と関連ファイル。
   • 実装中に収集した証拠。 検証担当者には、verify スキルに従い、適切な検証レベルで各受け入れ基準を判定し、verify の出力形式で報告するよう指示します。報告には全体の判定と、証拠を添えた基準ごとの結果（checked／failed／not checked）を含めます。実行せずコードを読むだけでしか確認できない基準は、黙って合格とせず、不足している前提条件（例：「認証済みセッションが必要」）を示して Blocked と報告します。検証担当者は報告のみを行い、コードは変更しません。
2. 判定を確認します。verify は、基準ごとの詳細とともに Pass | Partial | Fail | Blocked を返します。すべての基準に実証済みの証拠がある場合に限り Pass が有効です。実行時／ブラウザー関連の基準が未確認のまま Pass が返された場合は Partial とし、検証担当者に実際に実行するよう求めます。
   • Pass（すべての基準を証拠付きで満たしている）→ 完了です。
   • Partial または Fail → 検証担当者が示した具体的な不足箇所（ファイル、行、失敗したケース）を修正し、もう一度だけ検証担当者を実行して確認します。2回目の検証後は停止します。それでも失敗する場合は、残っている不足を報告します。
   • Blocked → 人間による対応または判断が必要なブロッカーを報告して停止します。残件として明示し、Passの陰に隠さないでください。

自分で下した判定、検証の省略、または基準よりも弱い対象に対する判定を根拠に、完了を主張しないでください。具体的な不足を報告してください。

最終レポート

## Status

Done | Partially Done | Blocked

## Changed

- ...

## Acceptance Criteria

- AC1: Met | Not Met | Blocked - evidence

## Verification

- Command or scenario:
- Result:

## Human Check

- ...

## Risks

- ...