implement

実装

1セッションにつき作業項目を1つだけ実装し、テストファーストで進めて、エンドツーエンドで検証します。作業項目とは、チケット、1セッションで完了できる規模の仕様、または合意済みの会話スコープです。例外は仕様の一括実行で、1セッションで仕様に含まれるすべてのチケットを実装します。

仕様の一括実行とPRの提出については、references/spec-run.mdを参照してください。毎回、ステップ1の前に必ず読んでください。最初に「提出方法の選択」の質問に答えます（現在のブランチ、PR、仕様全体を対象とするPRの積み重ねのいずれか）。ユーザーが仕様全体の実装を依頼した場合（all、「…をすべて実装」など）、またはPRとしてすでに提出した作業の変更を依頼した場合は、仕様の一括実行とフォローアップに関するセクションが適用されます。

パイプライン上の位置：wayfinder（判断する）→ to-spec（仕様を書く）→ to-tickets（チケットに分割する）→ implement（セッションごとにチケットを1つ実装し、レビューと検証も行う）。

ガードレール

• 明示的な承認なしに、データベースのリセット、ロールバック、削除、切り詰め、またはその他の破壊的なデータ操作を決して行わないでください。スキーマ変更は新しいマイグレーションに含め、稼働中のテーブルの変更は expand–contract の順序で行ってください。
• 識別子を使用する前に確認してください。対象には、ルート名、設定キー、列挙値、アイコン名、パッケージAPIが含まれます。マニフェストへの記載だけでは、登録や使用の証明にはなりません。

スタックのリファレンス。 マニフェストからスタックを特定してください。以下に該当するファイルがある場合は、ステップ1の前に読んでください。そのファイルには、そのスタックの破壊的なコマンド、フォーマッター、テストコマンド、ワークツリーの設定が記載されています。

• Laravel（composer.jsonにlaravel/frameworkがある場合）：references/laravel.md

プロセス

1. 作業範囲を定め、作業を確保する

入力を分類し、受け入れ基準を明確にします。

• チケット：本文とコメントをすべて取得します。親仕様に Build Contract セクションがある場合は、まずそのセクションを読み、その後、チケットに記載された見出し、または実装で参照する見出しを読みます。直接のブロッカーについては、引き継がれる境界を確認するために Resolution セクションを読みます。ほかのクローズ済みチケットとマップは、必要に応じて参照します。wayfinder の判断チケットは、種類が task の場合に限り対象になります。それ以外の種類は、実装ではなく判断を行うものなので、そこで停止します。task は手動でブロッカーを解消する作業であり、コードを書く作業ではありません。可能なものは自分で実施し、それ以外は ticket-types に記載された正確なチェックリストを人間に渡します。破壊的または取り消し不能な手順に進む前に、明示的な承認を得て、得られた事実を記録し、解決済みにします。コード変更を前提とするため、境界／TDD／コミット／レビュー／検証のループ（ステップ 2～7）は省略します。チケットが作業項目です。
• 仕様：本文とコメントをすべて取得します。独立して納品できるチケットが複数含まれている場合、または 1 セッションに収まらない場合は、チケットが必要です。tickets/ が公開されていて、仕様の実行が求められている場合は、仕様の実行を行います。それ以外の場合は停止し、ユーザーに to-tickets の実行を依頼します。1 セッションに収まる仕様は、それ自体が作業項目です。
• 会話：範囲と動作の基準を数行で言い換えます。トラッカーによる確保や解決処理はありません。

作業項目は .scratch/ 配下の Markdown ファイルです。外部トラッカーはありません。起動時のコンテキストに選択したファイル、そのステータス、ブロッカーがすでに示されている場合は、トラッカーの構成を読み直すのではなく、該当するファイルそのものを再検証します。それ以外の場合は、.agents/issue-tracker.md（/setup が作成）を通じて一度だけ構成を読みます。これがない場合は、従来の docs/agents/issue-tracker.md を確認し、それもなければ setup スキルのシードを確認します。項目の blocked-by フロントマターに記載された直接のブロッカーをすべて確認し、未解決のものが残っている場合は、作業を確保する前に停止します。その後、作業の確保に進みます。

• to-tickets で作成されたチケット、または直接実装する仕様の場合は、フロントマターの status: in-progress と claimed-by: にセッション固有の値を設定し、確保できたことを確認するために再読み込みします（トラッカーの「並行作業」ルールにある書き込み後の比較を参照）。仕様を直接実装する場合も、チケットと同じ方法で確保します。実装対象となるファイルであり、親項目としてそのままにしておくものではありません。
• wayfinder の判断チケットでは、Wayfinding の Claim 操作（claimed-by）を使用します。

チケットまたは仕様は追跡対象です。フロントマターの status が正式な状態を示します。リポジトリによっては、トラッカードキュメントにも作業の記録簿や説明的な要約を維持しています。リポジトリで求められている場合は更新しますが、フロントマターへの書き込みの代わりにはなりません。リンクされたワークツリーで実装しても、状態は変わりません。そこでフロントマターを更新してコミットすると、ブランチのマージ時にメインのチェックアウトへ反映されます。

項目がすでに確保済み、または作業中の場合は停止します。作業が明らかにコミット済み、または放棄されている場合に限り、確保状態が古いものとして扱います。

確保後、または会話のみの作業範囲を定めた後に、git rev-parse HEAD の出力を不変の base_sha として記録します。レビューと、失敗が既存のものだと証明する際には、必ずこの SHA を使用します。

作業が 1 セッションに収まり、受け入れ基準が明確で、追跡対象の項目がすべてブロッカー解決済みの状態で確保され、base_sha が記録された時点で、このステップは完了です。

2. 境界を選ぶ

tdd スキルの 境界：テストの配置場所 セクションにある、順位付けと選定のルールを使用します。仕様に記録済みの境界があれば再利用し、なければ自分で選び、その選択を明記します。境界ごとに 1 行とし、承認を求める段階は設けません。境界の配置はテスト構造であり、grilling の 質問する価値があること が示すとおり、判断はあなたに委ねられています。ルールが唯一の判断基準です。ルール上の優先度が同じで、配置によって作業内容が実質的に異なる場合に限り、真の選択肢について質問します。

すべての受け入れ基準に境界が設定された時点で、このステップは完了です。

3. TDD ループ

選んだ接点で tdd スキルを実行します。リポジトリのスクリプトと既存の使用例から、対象を絞ったテストと静的解析のコマンドを確認します。ループ中のすべてのテスト実行は、変更を網羅する単一のテストまたはファイルに絞ります（--filter=<test name> またはテストファイルの正確なパスを指定し、同じディレクトリ内の隣接するテストやデモ用テストは実行しません）。設定されている場合は、静的解析も定期的に実行します。このセッション中のテストを省略するようユーザーが明示的に求めた場合は、セッションの残りの間その指示に従い、ステップ 8 にその旨を記録します。

選んだ接点ですべての受け入れ基準が網羅され、対象を絞ったテストがすべて成功し（ユーザーがテストの省略を求めた場合は、最後に実行した対象を絞ったテスト結果を採用します）、設定されている静的解析がすべて成功した場合にのみ、ループを完了します。

4. レビュー可能なチェックポイントをフォーマットしてコミットする

リポジトリで設定されているフォーマッター（Pint、Prettier、Black、gofmt など）を、変更したパスだけに対して実行します。これにより、並行セッションの未コミットファイルはそのまま保たれます。git status --porcelain を確認し、作業項目のファイルだけを明示的なパスでステージングして、他者の変更はステージングしないでください。.claude/agent-memory/ 以下の変更は、誰が書いたものであっても常に自分の変更です。これらは memory: project を持つエージェントのメモであり、並行セッションの作業途中の変更ではないため、コミットに含めます（git add -- .claude/agent-memory）。現在のブランチにコミットします（PR の作成時にステップ 1 より前にブランチが作成されています）。このステップではブランチもワークツリーも作成しません。変更したパスを記録します。次のステップのレビュー対象はこれらのパスに限定されるため、同じブランチで並行して行われたコミットは、ここではステージングされず、レビュー対象にもなりません。

作業項目の変更がすべてコミットされ、他者の変更が一切変更されず、チェックポイントのコミット SHA が記録された状態で、このステップを完了します。

5. レビュー

記録した作業項目のパスに対象を絞り（共有ブランチ上の並行コミットがレビュー範囲に入らないようにするため）、base_sha を基準に code-review スキルを実行します。対応が必要な指摘はすべて tdd ループを通じて解決し、影響を受ける対象を絞ったチェックと静的解析を再実行してから、フォーマットし、明示的なパスをステージングして修正をコミットします。修正コミットのたびに、前回のレビューでの指摘とヘッドを渡して code-review を再実行し、再レビューします。レビューは 2 回までです。2 回目のレビューでも対応が必要な指摘が残る場合は、修正を打ち切り、各ラウンドでレビューしたコミットとともに、その指摘をユーザーに提示します。

code-review の正確性の観点では、バグと障害の発生要因を探します。BLOCKING と MAJOR の指摘も、ほかの指摘と同様に対応が必要です。仕組み（ジョブ、ロック、クレーム、再試行など）を追加する修正は、新たな対象範囲を生み出すため、その修正コミット後の再レビューでは追加部分も対象にします。このステップで見落とされた内容は、プッシュごとに 1 ラウンド、PR のレビューボットに引き継がれます。

レビューで未解決の対応必須の指摘がなくなり（またはレビュー回数の上限に達して残りの指摘が列挙され）、作業項目の変更がすべてコミットされた場合にのみ、このステップを完了します。

6. 最後の自動チェックを実行する

リポジトリのルールやユーザーが保存した設定（CI でテストスイートを実行する、または「依頼がない限り全テストスイートを実行しない」など）ですでに答えが決まっている場合は、全テストスイートに関する質問を省略し、その指示に従ってください。それ以外の場合は、最終的な自動チェックとして全テストスイートを実行するかどうかを、（利用可能であれば AskUserQuestion で、そうでなければチャットで通常の質問として）一度だけ尋ねてください。回答が「いいえ」の場合は、全テストの実行を省略します（ステップ 3 の重点テストを自動チェックの証拠とします）。省略したことを記録し、ステップ 8 で明確に報告してください。

承認された場合は、リポジトリで文書化された全テストスイートのコマンドを実行します。そのコマンドは、AGENTS.md または CLAUDE.md、パッケージスクリプト（composer.json、package.json、Makefile）、または CI ワークフローに記載されています。どこにも記載がない場合に限り、スタックの既定のテストランナーを使用してください。フォアグラウンドの制限時間を超える可能性がある実行は、バックグラウンドで実行します（利用可能であれば Bash の run_in_background を使用）。その後は返信せずにターンを終了し、完了通知を待ってください。「まだ実行中です」とだけ伝える確認メッセージでユーザーのターンを消費してはいけません。作業に起因する失敗は修正してください。無関係な失敗が作業前から発生していたことを証明するには base_sha と照合し、その失敗を明確に記録して、作業範囲を広げないでください。

コードを修正した場合は、再びこのゲートを実行する前にステップ 3～5 に戻ります。全テストの実行を省略した（拒否された場合、またはルールや設定ですでに決まっていた場合）、あるいは作業に起因するすべてのチェックが合格し、残る失敗すべてについて base-SHA の証拠がそろった場合に、このステップを完了します。

7. エンドツーエンドで検証する

verify スキルを実行します。製品の不具合が見つかった場合は、再度検証を実行する前にステップ 3～6 に戻ります。追跡可能な作業項目を完了として解決するには、検証に成功する必要があります。

外部依存関係が原因で検証できない場合は、コミット済みの実装を維持し、正確な阻害要因を報告して、作業項目を未完了のままにしてください。推測だけで検証済みとマークしてはいけません。

8. 作業を完了する

検証に成功したら、実装内容、正当な逸脱があればその内容、検証の証拠、実装コミットの SHA、後続の担当者が再利用すべき公開シームを記録し、満たした受け入れ基準すべてにチェックを入れてください。この Resolution は後続への引き継ぎです。親仕様を繰り返し説明せず、シームと証拠を具体的に記載してください。作業項目は、該当する分岐に従って解決します。

• チケット、または直接実装された仕様：そのフロントマターの status: closed を設定し、## Resolution を追記します。値は必ず closed とし、built や done など独自の値を使ってはいけません。
• wayfinder の判断チケット：Wayfinding の Resolve 操作を使用します。
• 会話：結果を報告し、.scratch/ 内のファイルには触れません。

すべての親項目は未完了のままにしてください。チケットを閉じてもその仕様は閉じません。また、仕様やチケットを書いた時点で to-spec、または仕様がない場合の to-tickets によりマップはすでに閉じられているため、implement でマップに触れてはいけません。仕様の tickets/ にあるすべてのチケットが閉じられた状態が、その仕様の完了です。これは報告する導出状態であり、仕様に書き込むステータスではありません。1 セッションで扱う作業項目が仕様そのものだった場合は、その仕様を直接閉じてください。解決内容の書き込みはコードのコミットに含めないでください。.scratch/ が追跡対象の場合は、別途コミットします。解決内容では実装コミットを記載し、解決内容自体のコミットは記載しません。

追跡可能な作業では、書き込み後に Markdown ファイルを読み直し、フロントマターが status: closed であり、## Resolution セクションがあることを確認してください。

実装コミットと解決内容の個別コミットがあればそれらを記録し、トラッカーの最終状態を確認できた時点、または会話のみの結果を報告した時点で完了です。その後は作業を止めてください。次の作業項目には、コンテキストを新たにしてクリーンなセッションで取り組みます。

完了したら

wayfinder/references/pipeline-end-block.md の形式に従って、セッション終了ブロックを出力します。親がある追跡可能な作業項目の場合は、ブロックを書く前に Markdown トラッカーを確認し、残りのフロンティアを把握してください。残りを推測してはいけません。

---
Pipeline: decide → spec → tickets → **build**   (4 of 4)
Done: <what now works, the work-item ref if any, commit(s), verification state>
Next:
  • <condition> → /<skill> <ref>

ステージ固有の Next 条件（該当するもののみ。可能性の高い順）：

• PR がオープンで、レビューボットがまだ実行中 → ボットからコメントが投稿されたら /resolve-review-comments <PR> を実行します。PR とワークツリーのパスを明記してください
• PR が複数オープン → /triage-github-pr <every PR, bottom-up> を実行し、マージコミットを使って下から順にマージします
• 親仕様に未対応のフロンティアチケットがある → /clear を実行してから /implement <next frontier ticket> を実行します（作業途中で中断した場合は、自分がクレーム済みで未完了のチケットを先に再開します）。残りを一度に実装するには /implement <spec path> all を、並行して実装するには /implement-spec <spec path> を実行します。対象と残りの件数を明記してください
• 仕様のすべてのチケットがクローズ済み → 実行することはありません。仕様が完了したことと、スコープ外として保留した項目があれば明記してください
• 残りのチケットがすべてブロック中 → まず /implement <the blocker> を実行します。ブロッカーが意思決定であれば /grill-me を実行してください
• ビルドによって、誰も下していない意思決定が明らかになった → その件について /grill-me を実行し、仕様が現状に合わなくなった場合は /to-spec を再実行します
• 検証が外部要因でブロックされている → 作業項目をオープンのままにし、ブロック解除に必要な条件を正確に明記してください
• 作業途中で中断した → どのテストが通っているか、変更がコミット済みか未コミットか、クレームの状態、次に作成すべき失敗テストを明記してください。次のセッションでは、新しいチケットに着手する前にそのチケットを再開するか、フロンティアに戻すためにリリースしてください