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

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

タスク: $ARGUMENTS

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

Review/test の接続

レビューまたはテストが必要な場合、同じ親が shared skill package の実体にある ../reviewer/SKILL.md または ../tester/SKILL.md を存在確認して読み込み、その手順を実行する。別の進行担当を起動せず、親は対象版、要件、ユーザー指定、実在する計画・差分、必要な確認範囲を渡し、選定・配分・集約は shared skill に委ねる。

shared reviewer は評価者へ code-review-guidance/SKILL.md の実体絶対パスと対応する reference だけを渡し、reviewer の進行手順を評価者へ渡さない。shared tester は tester/references/test-procedure.md と結果契約の実体を実行担当へ渡す。親が自ら評価・検証する場合だけ、必要な専門手順を読む。この workflow では観点、未知指定、担当間の分離、判定規則を再定義しない。

1. 事実確認と計画

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

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

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

• 目的、非目的、対象範囲、変更してはならない範囲
• 既存パターンと根拠、依存関係、書き込み単位の排他的所有
• 実装手順、成功条件、挙動ごとの検証方法
• 未確認事項と、追加調査またはユーザー判断が必要になる条件

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

--deepplan が明示された場合だけ deepplan スキルを読み込み、その結果を親が対象コードと照合して計画へ反映する。通常の計画でも次の専門検討を必要な範囲で使う。計画全体を専任担当へ渡さない。計画ファイルや実行用 artifact は、長い run で再開に実益がある場合、またはユーザーが記録を求めた場合だけ作る。handoff の作成・再開判定・更新・保管は references/handoff.md に従う。再開時に親から実在する plan または handoff path が渡された場合は、その実体を読み、完了済み・決定済みの項目を保持したまま未完了項目だけを同じ path へ増分更新する。path を推測したり、未指定の artifact を作ったりしない。

専門検討から実装条件へ

親は要件と既存コードから暫定案を作り、状態所有者、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. 実装経路と統合

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

• 実装・修正は親が直接行わず、書き込み担当へ委譲する。全体文脈と密結合した変更は1人の担当へまとめる。
• 所有ファイルと完了条件が明確な独立単位は、現在のランタイムが提供する worker/collaboration primitive へ委譲できる。
• 原因推論、状態所有権、競合、性能、厳しい整合性など難しい単位は、利用可能な高推論担当へ最初から委譲できる。
• --codex が指定された場合、またはユーザーが実装を Codex に任せると指示した場合は、委譲する実装・修正を shared skill package の ../codex/SKILL.md の実装経路で行う。計画・レビュー・テスト・受入は親が通常どおり持つ。

実装を委譲する場合（--codex を含む）、複数の独立単位を並列化する場合、reviewer/tester の FAIL 後に再実装する場合は、references/implementation-delegation.md の経路選択・並列化条件・統合・再実装の手順に従う。

委譲時に渡す内容は implementation-delegation の「責任境界」に従う。担当が別担当を勝手に起動することや、親の計画・scope・受入条件を変更することを前提にしない。

独立単位を並列化するのは、書き込みファイル、共有契約、生成物、lockfile、共通 helper、実装順序に競合がなく、親が統合後の確認をできる場合だけとする。共有契約や同一ファイルは直列化する。並列化できないときは単一担当へ戻す。担当の完了報告だけで受入せず、親が実際の status、対象 diff、変更ファイル、確認出力を照合する。

3. レビューとテスト

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

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. 要件・計画の成功条件を満たし、実行した検証の結果が確認できる。
3. 未実行、判定不能、環境・権限 blocker を成功と分けている。
4. 既存のユーザー変更を保全し、不要な commit、push、破壊的操作をしていない。

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