# Pr Onboarding

> PR作成時に生成AIがPR本文にオンボーディングを記述するスキル。変更の契約を、レビューア・将来の自分・障害対応者に渡す。理解の再現性・反証可能性・運用可能性を同時に成立させる。トリガー条件: PRを作成する時（「PRを作成して」「プルリクを書いて」）、PR本文を充実させたい時（「PR説明を書いて」「PRオンボーディングして」）、変更の影響を整理したい時（「この変更の影響範囲を整理して」）、レビューの準備をする時（「レビュー用に変更をまとめて」）。

- Skill: `caphtech/pr-onboarding` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add caphtech/pr-onboarding`
- Raw SKILL.md: https://api.skillmd.com/api/skills/caphtech/pr-onboarding/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: CAPHTECH (https://skillmd.com/u/caphtech)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/caphtech/pr-onboarding

---


# PR Onboarding

PR作成時に「説明」ではなく「変更の契約」を記述し、理解負債の蓄積を防ぐ。

## 目的

PRオンボーディングの目的は、以下3つを同時に成立させること:

1. **理解の再現性**: 他者が同じ理解に到達できる
2. **反証可能性**: 正しさの根拠（テスト・観測・仕様）が提示され、間違いなら突ける
3. **運用可能性**: 壊れたときに検知でき、戻せる（戻せないなら明記）

## 合格条件（PR Onboarding Done）

PR本文（＋リンク先）を読むだけで、レビューアが以下を答えられる状態:

| # | 項目 | 内容 |
|---|------|------|
| 1 | What | 何が変わったか |
| 2 | Why | なぜそう変えたか（代替案含む） |
| 3 | Invariants | 何を壊してはいけないか |
| 4 | Blast Radius | どこに影響するか（境界・波及） |
| 5 | Failure Modes | どう壊れうるか |
| 6 | Evidence | どう確かめたか（検証・根拠） |
| 7 | Rollback | どう戻すか（または戻せない条件） |

## ワークフロー

```
1. 契約確立 → 2. 変更理解 → 3. 意図抽出 → 4. 境界特定 → 5. 不変条件 → 6. 失敗モード → 7. 検証証拠化 → 8. リリース戦略 → 9. レビュー誘導 → 10. DocDD同期 → 11. 不確実性管理
```

### 入力（AIに渡すもの）

- PR差分（diff）と変更ファイル一覧
- 関連チケット/設計ID（あれば）
- テスト結果（CIログ or 実行コマンド）
- DocDDの正本リンク（あれば）

### 各ステップの要点

各ステップの出力は、下記のPR本文テンプレートの対応セクションにそのまま落とし込む。ここではテンプレートに書かれていない判断基準のみ示す。

1. **契約確立**: PR本文に載せる項目を中核6〜8項目に絞り、詳細はリンクに逃がす（本文は1〜2画面に収める）
2. **変更理解**: 行数差分ではなく振る舞い・責務・契約の変化として要約する（What Changed）
3. **意図抽出**: Whyは作文ではなく意思決定の記録として書き、代替案と棄却理由を残す
4. **境界特定**: 呼び出し元/先・データ・外部I/Fへの影響と互換性を確認する（Blast Radius）
5. **不変条件**: Must stay trueを最大3つに絞り、破ったときの症状を紐づける（Invariants）
6. **失敗モード分析**: 壊れ方トップ3（起きやすい/致命的/気づきにくい）に検知手段を紐づける
7. **検証証拠化**: 実施した検証（自動/手動）と再現手順・根拠リンクを揃える（Evidence）
8. **リリース戦略**: ロールアウト/ロールバック手順とロールバック不能条件を明記する
9. **レビュー誘導**: 重点ファイルを最大3〜5に絞り込み、議論すべき論点を示す
10. **DocDD同期**: 参照した正本ドキュメントへのリンクと、更新が必要なドキュメント・差分案を示す
11. **不確実性管理**: 未確定事項を最大5件に絞り、解消手段とマージ条件/フォローアップの別を明記する

## ガードレール（絶対禁止事項）

1. **根拠なしの断言**: もっともらしい説明ほど危険
2. **未実施の検証の捏造**: 信用を一撃で破壊する（最重要）
3. **長文化で安心させる**: 読み手の注意を散らし重要点が埋もれる
4. **影響範囲の過小評価**: 特にデータ、権限、外部I/F、並行性
5. **"問題ないはず"の楽観**: 不確実なら不確実として扱い検証へ落とす

詳細は [references/guardrails.md](references/guardrails.md) を参照。

## スキル詳細

各ステップの詳細な実行方法と品質ゲートは [references/skills-catalog.md](references/skills-catalog.md) を参照。

## 評価ルーブリック

PRオンボーディングの品質評価基準は [references/evaluation-rubric.md](references/evaluation-rubric.md) を参照。

## PR本文テンプレート（出力例）

```markdown
## Summary
[変更の中心を1〜3文で]

## Why
- **Goal**: [目的]
- **Reason**: [採用理由]
- **Alternatives**: [検討した代替案と棄却理由]

## What Changed
- [振る舞いが変わった点1]
- [振る舞いが変わった点2]

## Blast Radius
- **Affected**: [影響範囲]
- **Compatibility**: [互換性への影響]

## Invariants (Must Stay True)
| 条件 | 根拠 | 破ったときの症状 |
|------|------|-----------------|
| [条件1] | [コード/テスト] | [症状] |

## Failure Modes
| 種類 | パターン | 検知手段 |
|------|---------|---------|
| 起きやすい | [説明] | [テスト/ログ] |
| 致命的 | [説明] | [テスト/ログ] |
| 気づきにくい | [説明] | [テスト/ログ] |

## Evidence
- [x] 自動テスト: `npm test` 全パス
- [x] 手動検証: [手順]
- 根拠: [リンク]

## Rollout & Rollback
- **Rollout**: [手順]
- **Rollback**: [手順]
- **Cannot rollback if**: [条件があれば]

## Review Focus
- [ ] [重点ファイル1]: [観点]
- [ ] [重点ファイル2]: [観点]

## Unknowns
| 項目 | 解消手段 | ブロッカー? |
|------|---------|-----------|
| [未確定事項] | [手段] | Yes/No |

## Related
- Issue: #XXX
- Docs: [リンク]
```