メニュー
PR作成時に生成AIがPR本文にオンボーディングを記述するスキル。変更の契約を、レビューア・将来の自分・障害対応者に渡す。理解の再現性・反証可能性・運用可能性を同時に成立させる。トリガー条件: PRを作成する時（「PRを作成して」「プルリクを書いて」）、PR本文を充実させたい時（「PR説明を書いて」「PRオンボーディングして」）、変更の影響を整理したい時（「この変更の影響範囲を整理して」）、レビューの準備をする時（「レビュー用に変更をまとめて」）。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | pr-onboarding |
| context | fork |
| description | PR作成時に生成AIがPR本文にオンボーディングを記述するスキル。変更の契約を、レビューア・将来の自分・障害対応者に渡す。理解の再現性・反証可能性・運用可能性を同時に成立させる。トリガー条件: PRを作成する時（「PRを作成して」「プルリクを書いて」）、PR本文を充実させたい時（「PR説明を書いて」「PRオンボーディングして」）、変更の影響を整理したい時（「この変更の影響範囲を整理して」）、レビューの準備をする時（「レビュー用に変更をまとめて」）。 |
PR作成時に「説明」ではなく「変更の契約」を記述し、理解負債の蓄積を防ぐ。
PRオンボーディングの目的は、以下3つを同時に成立させること:
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. 不確実性管理
各ステップの出力は、下記のPR本文テンプレートの対応セクションにそのまま落とし込む。ここではテンプレートに書かれていない判断基準のみ示す。
詳細は references/guardrails.md を参照。
各ステップの詳細な実行方法と品質ゲートは references/skills-catalog.md を参照。
PRオンボーディングの品質評価基準は references/evaluation-rubric.md を参照。
## 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: [リンク]
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク（Double Diamond・Atomic Design・Design Tokens 3層）の適用、暗黙的デザイン判断の形式知化（DDR/QOC/RFC）、UIインベントリ収集（手動+MCP自動化）を統合する。ゼロから体系的に構築する用途向け。既存の単発UIから再利用可能な構造を抽出するにはrelational-design-pluginのdesign-system-backflowスキルを使用すること。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。
iOS/Androidモバイルアプリのデザインを体系的に行うスキル。Apple HIG・Material Design 3などプラットフォームガイドラインに準拠し、ナビゲーション・レイアウト・コンポーネント・モーション・アクセシビリティを適切に設計する。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「モバイルアプリをデザインして」「iOSアプリのUIを設計して」「Androidアプリの画面を作って」「モバイルのナビゲーションを設計して」「タッチUIを改善して」「アプリのアクセシビリティを対応して」と言われた時。
Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。
Use this skill when a design assumption, user segment, business goal, constraint, or product requirement has changed and you need to analyze which design hypotheses, decisions, artifacts, copy, or components should be retracted or revised. Requires a Relational Design trace session with recorded observations/relations/hypotheses/decisions to analyze against — not a general "redo this design" request.
Use this skill to critique an existing UI, frontend implementation, wireframe, flow, or visual design through Relational Design relations: user state, business intent, action risk, trust, information density, reversibility, accessibility, and implementation constraints. This is a relation-based critique, not a general design-methodology review — for platform-guideline or design-system compliance review, use design-plugin instead.
Use this skill after creating or reviewing a design artifact to extract reusable design-system knowledge: semantic tokens, components, variants, interaction rules, copy patterns, accessibility constraints, and governance notes. This only backflows structure out of an artifact that already exists — to build or govern a design system from scratch (Design Tokens layers, Atomic Design, DDR/QOC/RFC, UI inventory), use design-plugin's design-system-builder instead.