Pir2

---
name: "pir2"
description: "複雑な実装・設計変更を Plan → Implement → Review → Test → Retrospect で進める。要件、影響範囲、リスク、レビューや検証の選定を親が管理し、必要な担当だけを委譲する。`--deepplan` は深い計画、`--codex` は実装を Codex に任せる場合の明示オプション。"
argument-hint: "[タスクの説明] [--deepplan] [--codex]"
---

# 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](references/destructive-change-check.md) で影響と対応する確認を計画へ記録する。

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

## 2. 実装経路と統合

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

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

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

委譲時は目的、確認済みの事実、許可・禁止範囲、維持する制約、完了条件、実行する focused check、返却事項だけを渡す。担当が別担当を勝手に起動することや、親の計画・scope・受入条件を変更することを前提にしない。

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

## 3. レビューとテスト

親は前節の shared reviewer/tester に、対象版、要件、ユーザー指定、実在する差分・計画、必要な確認範囲を渡す。返却された実在の結果を受入判断へ使い、実装者の自己申告や存在しない担当・成果物で補わない。

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

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

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

OS 設定、security control、認証・認可、本番・外部状態、不可逆操作、権限拡張を変更する場合は、[references/destructive-change-check.md](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 を補完しない。未完了の要件がある場合は完了と書かない。