PIR²: Plan → Implement → Review → Test → Retrospect

このワークフローは、複雑な実装を計画し、実装・独立確認・テスト・振り返りまで完了させる。親（main）はユーザーとの対話、要件、計画、所有境界、統合、受入、最終判断を持つ。担当は自分に渡された範囲だけを扱い、親の計画や受入判断を置き換えない。

タスク: $ARGUMENTS

このスキルに同梱された参照文書を使う場合は、読み込んだ本 SKILL.md の実体から同じ skill package 内の references/ を解決する。対象リポジトリ内の同名ディレクトリ、特定ランタイムのホームディレクトリ、特定のツール名は前提にしない。

1. 事実確認と計画

開始時に対象リポジトリの状態、既存の未コミット変更、依頼、入口、関連実装を確認する。既存の変更はユーザーまたは他担当の作業であり、所有範囲外の変更を戻さない。reset、checkout、restore、stash、自動的な revert、commit、push は、ユーザーが明示した範囲を除き実行しない。dotfiles管理下の承認はdotfiles-autosyncに従う。

要件が曖昧で結果が変わる設計判断が残る場合だけ、brainstorm または追加の対話を使う。タスクが明確なら省略する。探索は親が直接行うか、独立した問いだけを現在のランタイムの委譲機構へ渡す。探索担当は読み取り専用とし、実装や計画の変更を行わない。レポートは後続の判断に役立つ場合だけ作り、未生成のパスを必須入力にしない。

親は確認済みの事実から、次を含む計画を作成・更新する。

• 目的、非目的、対象範囲、変更してはならない範囲
• ユーザー指示を対象・操作・条件に分けた内容。順序語（「〜から」「先に」）で対象を狭めない
• ユーザー指定または原本をそのまま受入基準にし、許容差や代替基準で弱めない
• 既存パターンと根拠、依存関係、書き込み単位の排他的所有
• 実装手順、成功条件、挙動ごとの検証方法
• 未確認事項と、追加調査またはユーザー判断が必要になる条件

公開 API・型・設定、データ・migration、認証・認可、生成物、実行時の分岐・状態に波及する変更では、references/destructive-change-check.md で影響と対応する確認を計画へ記録する。

--deepplan が明示された場合だけ deepplan スキルを読み込み、その結果を親が対象コードと照合して計画へ反映する。通常の計画でも必要な専門検討を行い、計画全体を専任担当へ渡さない。

計画や実行用artifactは、長いrunで再開に実益がある場合、またはユーザーが記録を求めた場合だけ作る。handoffは references/handoff.md に従う。

専門検討から実装条件へ

親は要件と既存コードから暫定案を作り、状態所有者、APIの意味、依存方向、データ移行、認証・認可、失敗時の扱いなど、後から変更すると実装全体へ波及する判断を特定する。関係する観点だけを専門担当へ渡し、小さく既存パターンで方針が明確な変更は親の短い確認で進める。影響範囲が不明なら先に探索する。コードなしで成立性を判断できない部分は、所有と確認方法を限定した小実装で確かめてから広げる。

親は同じshared packageの ../code-review-guidance/SKILL.md、../code-review-guidance/references/pre-implementation.md と担当観点のreferenceの実体を確認する。専門担当へ対象と版、要件、確認済み事実、暫定案、担当観点と各絶対パスを渡し、担当自身が必要な本文を読む。親は委任のためだけに全専門referenceを読まない。独立した問いは容量内で並列に渡し、容量が足りなければ順に扱う。独立担当を利用できなければその未実施範囲を示し、親の確認と区別して依存しない作業を進める。

親は返却された条件、根拠、破る場合の不利益、確認方法、未決定を照合する。相反する提案は ../reviewer/references/finding-reconciliation.md の「矛盾を見つけたとき」に従って一つの方針へまとめる。deepplan等で同じ観点の条件と根拠が揃っていれば再利用し、不足または変わった前提だけ検討する。

親は実装前に次を一つの計画または委譲指示へまとめる。

• 作るもの、変更箇所、変更しない範囲。
• 採用する構造、守る具体的な挙動、その理由と原本の根拠。
• 実行する確認と、設計を再検討すべき具体的な条件。

事前検討は最終受入ではなく、後段のreviewerの観点を絞る根拠にもならない。

2. 実装経路と統合

計画、所有範囲、終了条件を確定してから、親は実装経路を選ぶ。

実装経路、委譲内容、並列化、統合、FAIL後の再実装は implementation-delegation.md に従う。Claude Code の --codex / --claude は同 reference「既定の実装担当」の指定として、同じセッションの以後の委譲に適用する。

3. レビューとテスト

親は shared reviewer/tester に、対象版、要件、ユーザー指定、実在する差分・計画、実装条件と設計理由・根拠、必要な確認範囲を渡す。レビューは shared reviewer の手順で独立した評価担当を起動して行い、親自身の評価で代替しない。事前検討の結論で省略しない。返却された実在の結果を受入判断へ使い、実装者の自己申告や存在しない担当・成果物で補わない。

4. テストと失敗時の対応

テストは変更した挙動と失敗時に防ぐ実害から shared tester の手順で選ぶ。プロジェクト必須検証と安全・権限確認を維持する。

reviewer/tester の返却が要件未達または未確認を示した場合、親は指摘を実コード、仕様、再現・テスト結果、ユーザーの明示判断で照合する。自分の計画や委譲時の指示文は、争われている主張の正しさの証拠にしない。誤検知と判断した場合は根拠を残す。要件未達が確認できた場合は、報告と実差分から根本原因を特定し、影響する最小単位を修正する。修正後は影響する確認だけを shared skill の手順で再確認する。安全性、正しさ、権限、データ損失に関する未確認事項が残る場合は完了扱いにしない。

OS 設定、security control、認証・認可、本番・外部状態、不可逆操作、権限拡張を変更する場合は、references/destructive-change-check.md の検証選定を適用したうえで、対象、影響、復旧方法を親が提示し、必要な明示承認を得る。検証担当数を調整するための承認に置き換えない。

5. 任意の改善と振り返り

refactor-advisor は本来の要件や受入条件とは別の任意改善であり、使う場合も提案を実装へ混ぜず、適用前にユーザーの意思を確認する。振り返りは親が短く行うか、複数担当・失敗分析を分離する価値がある場合だけ読み取り専用の振り返り担当へ委譲する。比較用の台帳、固定メタレポート、未生成 artifact を作ること自体を完了条件にしない。

終了時に references/experimental.md の Active な実験を確認し、今回の run が対象になる実験があれば、同ファイルの観測手順で1件記録する。

6. 受入と完了報告

親は次を実測して受入を判断する。

1. status、対象 diff、実在する変更ファイルが所有・禁止範囲に収まっている。
2. 要件・計画の成功条件を満たし、実行した検証の結果が確認できる。担当が実行したと申告した検証は、events・ログ・出力など実行痕跡とも照合する。
3. 未実行、判定不能、環境・権限 blocker を成功と分けている。
4. 既存のユーザー変更を保全し、不要な commit、push、破壊的操作をしていない。
5. PRへpushする作業では、push直前に対象PRの状態を確認し、MERGED/CLOSEDならpushせず報告している。

最終報告は、タスク、変更ファイル、実際に実施したレビューとテスト、未確認事項・blocker、必要なら実在する記録先だけを簡潔に示す。未起動の担当や未生成の path を補完しない。未完了の要件がある場合は完了と書かない。