メニュー
ELD v2.3 Predict-Lightゲート。変更の影響度をP0/P1/P2で自動判定し、適切な検証深度を決定する。フルPredictの代わりに軽量ゲートとして機能。使用タイミング: Change前の自動判定、「影響度を判定して」「P0/P1/P2を判定して」、実装前のリスク評価、段階化計画の策定。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | eld-predict-light |
| description | ELD v2.3 Predict-Lightゲート。変更の影響度をP0/P1/P2で自動判定し、適切な検証深度を決定する。フルPredictの代わりに軽量ゲートとして機能。使用タイミング: Change前の自動判定、「影響度を判定して」「P0/P1/P2を判定して」、実装前のリスク評価、段階化計画の策定。 |
Change前の影響度を P0 / P1 / P2 で自動判定し、検証深度を決定する軽量ゲート。 フルPredictスキル（廃止）の代わりに、必要十分な分析を最小コストで提供する。
| Level | 条件 | 検証深度 |
|---|---|---|
| P2 | 公開API変更 / DB スキーマ変更 / 認証・認可変更 / 課金ロジック変更 | フル影響分析 |
| P1 | 複数ファイル変更 / テスト未カバー領域 / 外部依存変更 | 影響リスト + 停止条件 |
| P0 | 上記いずれにも非該当 | 3行要約のみ |
function predict_light(change_set):
# Phase 1: P2 check (critical domain detection)
if touches_public_api(change_set): return P2, "公開API変更"
if touches_db_schema(change_set): return P2, "DBスキーマ変更"
if touches_auth(change_set): return P2, "認証・認可変更"
if touches_billing(change_set): return P2, "課金ロジック変更"
# Phase 2: P1 check (complexity/risk detection)
if count_files(change_set) >= 3: return P1, "複数ファイル変更"
if test_coverage(change_set) < 0.80: return P1, "テスト未カバー"
if has_no_tests(change_set): return P1, "テスト未カバー"
if touches_external_deps(change_set): return P1, "外部依存変更"
# Phase 3: Default to P0
return P0, "該当条件なし"
| チェック関数 | 判定方法 |
|---|---|
touches_public_api | ルーター/コントローラー定義、OpenAPI spec、エンドポイントハンドラの変更を検出 |
touches_db_schema | マイグレーションファイル、モデル定義、スキーマファイルの変更を検出 |
touches_auth | auth/、middleware/auth、permission、role、token、session 関連ファイルの変更を検出 |
touches_billing | billing/、payment/、subscription/、pricing 関連ファイルの変更を検出 |
touches_external_deps | package.json, go.mod, Cargo.toml, requirements.txt 等の依存定義変更を検出 |
test_coverage | 変更対象ファイルに対応するテストファイルの存在とカバレッジを推定 |
エージェントの自動判定は Manual Override で上書き可能。
OVERRIDE: P{n} → P{m} REASON: {理由}
## Predict-Light: P0
**変更概要**: {1行の変更説明}
**影響範囲**: {直接影響するファイル/モジュール}
**判定根拠**: {P0判定の理由}
## Predict-Light: P1
**変更概要**: {変更の説明}
**判定根拠**: {P1判定の理由}
### 影響リスト
| # | 影響対象 | 影響種別 | 確信度 |
|---|---------|---------|--------|
| 1 | {ファイル/モジュール} | {direct/indirect} | {high/medium/low} |
### 停止条件
- [ ] {条件1}: {具体的な停止トリガー}
- [ ] {条件2}: {具体的な停止トリガー}
### 推奨アクション
- {検証すべき項目}
## Predict-Light: P2
**変更概要**: {変更の詳細説明}
**判定根拠**: {P2判定の理由}
**リスクレベル**: {high/critical}
### 影響分析
| # | 影響対象 | 影響種別 | 確信度 | 検証方法 |
|---|---------|---------|--------|---------|
| 1 | {対象} | {direct/indirect/transitive} | {high/medium/low} | {テスト/手動確認/レビュー} |
### 破壊的変更チェック
- [ ] 後方互換性: {評価}
- [ ] データ整合性: {評価}
- [ ] 外部連携影響: {評価}
### 停止条件
- [ ] {条件1}: {具体的な停止トリガーと対処方針}
- [ ] {条件2}: {具体的な停止トリガーと対処方針}
### 段階化計画
1. {Phase 1}: {内容} → {検証ポイント}
2. {Phase 2}: {内容} → {検証ポイント}
### 必須レビュー項目
- {専門レビューが必要な領域}
詳細テンプレートは eld/references/predict-light-template.md を参照。
以下の条件に該当した場合、即座に作業を停止し報告する。
| ID | 条件 | 対応 |
|---|---|---|
| S-PRED-01 | P2判定だが段階化計画を立案できない複雑さ | 人間の判断を仰いで停止 |
| S-PRED-02 | Override降格の根拠が不十分 | 降格を拒否し理由を説明 |
| S-PRED-03 | 複数のP2条件に同時該当 | 最も重大な条件を優先し全条件を報告 |
1. 変更セットを受け取る
2. Machine Judgment Logicで自動判定 → P0/P1/P2
3. Manual Overrideが指示されている場合は適用
4. 判定レベルに応じたOutput Templateで出力
5. 停止条件チェック
6. 結果を返却（後続のChange/Groundスキルへ引き継ぎ）
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）から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.