OpenSkillIndex← back to search
claude-codedevops

Claude-skill-registry eld-predict-impact

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/eld-predict-impact" ~/.claude/skills/majiayu000-claude-skill-registry-eld-predict-impact && rm -rf "$T"
manifest: skills/data/eld-predict-impact/SKILL.md
tags
#change-impact#risk-assessment#stage-planning#code-safety#causal-analysis
source content

ELD Predict Impact

変更の影響を事前に分類・評価し、安全な変更計画を策定する。

目的

  • 「壊さずに収束する」を最優先: 賢く動くよりも安全に進める
  • 変更の影響を事前に分類・評価
  • 安全上限を持った自律編集の設計
  • 停止条件の明確化

因果タイプ分類

変更の影響を5つのタイプで分類する：

タイプ説明リスク対策
互換性API/スキーマの破壊High段階リリース、deprecation
性能レスポンスタイム、スループットMediumベンチマーク、負荷テスト
信頼性障害耐性、復旧時間Highフェイルセーフ、Circuit Breaker
セキュリティ認証/認可、データ保護Criticalセキュリティレビュー
可観測性ログ、メトリクス、トレースLow監視設定の確認

リスクマトリクス

            影響範囲
         狭い     広い
発   低  [Low]   [Medium]
生
確   高  [Medium] [High/Critical]
率

影響予測プロセス

Step 1: 変更スコープの特定

変更対象を明確化する：

change_scope:
  target_files:
    - path: <変更対象ファイル>
      change_type: modify | add | delete
      symbols: [<変更するシンボル>]

  related_laws:
    - <関連するLaw ID>

  related_terms:
    - <関連するTerm ID>

Step 2: 直接影響の分析

このファイル・モジュールの変更による直接的な影響：

direct_impact:
  - change: <変更内容>
    causal_type: 互換性 | 性能 | 信頼性 | セキュリティ | 可観測性
    risk: Low | Medium | High | Critical
    affected_components: [<影響を受けるコンポーネント>]
    mitigation: <リスク緩和策>

Step 3: 間接影響の分析

依存先への伝播を追跡：

indirect_impact:
  - dependent: <依存先ファイル/モジュール>
    impact_type: <影響内容>
    risk: Low | Medium | High | Critical
    verification: <確認方法（テスト名等）>

Step 4: unknown（未確認）の特定

静的に追跡困難な影響を明示：

unknown_impacts:
  - description: <追跡困難な理由>
    possible_risk: <潜在的リスク>
    investigation: <調査方法>

よくあるunknown:

  • DI/IoC経由の呼び出し
  • 設定ファイルからの参照
  • コード生成による参照
  • リフレクションによる呼び出し
  • 動的インポート

段階化戦略

危険度に応じた段階化

危険度:    Low → Medium → High → Critical
段階数:     1      2-3      3-5     5+

段階化の原則

  1. 最小単位で変更: 1ステップ = 1概念の変更
  2. 即時検証: 各ステップ後に静的診断 + テスト
  3. ロールバック可能: 各ステップで戻せる状態を維持
  4. 観測可能: 各ステップの成功/失敗が検証可能

段階化計画テンプレート

## 段階化計画

### Step 1: <ステップ名>
- **変更内容**: <具体的な変更>
- **因果タイプ**: <互換性/性能/信頼性/セキュリティ/可観測性>
- **検証方法**: <静的診断/テスト名>
- **成功条件**: <このステップの完了条件>
- **ロールバック**: <戻し方>

### Step 2: <ステップ名>
...

### Step N: 統合検証
- **変更内容**: 全体の統合テスト
- **検証方法**: <統合テスト名>
- **成功条件**: <全体の完了条件>

品質優先原則（Superpowers統合）

核心原則

  1. Epistemic Humility: 推測を事実として扱わない。
    unknown
    と言う勇気を持つ
  2. Evidence First: 結論ではなく因果と証拠を中心にする
  3. Minimal Change: 最小単位で変更し、即時検証する
  4. Grounded Laws: Lawは検証可能・観測可能でなければならない
  5. Source of Truth: 真実は常に現在のコード。要約はインデックス

「速さより質」の実践

  • 要件の曖昧さによる手戻りを根本から排除
  • テストなし実装を許さない
  • 観測不能な変更を防ぐ

完了条件

  • 因果タイプが正確に分類されている
  • 段階化戦略が明確に定義されている
  • 各ステップの停止条件が設定されている
  • 影響範囲が予測されている
  • Evidence収集計画が立案されている

停止条件

標準停止条件

以下が発生したら即座に停止し、追加計測またはスコープ縮小：

1. 予測と現実の継続的乖離

  • 想定外のテスト失敗が3回以上
  • 想定外の依存関係が発見された
  • 影響範囲が当初の予測を50%以上超過

2. 観測不能な変更の増加

  • 物差し（テスト/メトリクス）で検証できない変更が増える
  • 「動いているはず」という推測が増える
  • Evidence Ladderの低いレベル（L0のみ）が続く

3. ロールバック線の崩壊

  • 戻せない変更が発生
  • 依存関係が複雑化して部分的な戻しが困難
  • データマイグレーションが不可逆に

カスタム停止条件

Issue Contractで定義した追加の停止条件：

custom_stop_conditions:
  - condition: <条件>
    action: <停止時のアクション>
    owner: <責任者>

反射の選択

変更後の診断結果に応じて、適切な反射を選択：

機械反射（自動対応）

即座に修正可能な問題：

  • 型エラー → 型を修正
  • lint警告 → フォーマット修正
  • 未使用変数 → 削除

設計反射（判断が必要）

方針決定が必要な問題：

  • テスト失敗 → 原因分析と修正方針決定
  • 依存関係の問題 → アーキテクチャ検討
  • 性能劣化 → 最適化戦略の検討

停止反射（ユーザー確認）

停止条件に達した問題：

  • セキュリティ脆弱性発見
  • 重大な設計変更が必要
  • スコープ外の影響が判明
軽微な問題 → 機械反射で即修正
中程度の問題 → 設計反射で方針決定
重大な問題 → 停止反射、ユーザーに確認

出力形式

Impact Prediction Report

# Impact Prediction Report

## Summary

| 項目 | 値 |
|------|-----|
| 変更対象 | <ファイル数> files, <シンボル数> symbols |
| 直接影響 | <件数> components |
| 間接影響 | <件数> dependents |
| 未確認(unknown) | <件数> items |
| リスクレベル | Low / Medium / High / Critical |
| 推奨段階数 | <N> steps |

---

## 変更スコープ

### 対象ファイル
| ファイル | 変更タイプ | 変更シンボル |
|----------|-----------|-------------|
| src/orders/service.ts | modify | `createOrder`, `validateOrder` |
| src/orders/types.ts | modify | `OrderInput` |

### 関連Law/Term
- **Laws**: LAW-pre-order-quantity, LAW-inv-stock-balance
- **Terms**: TERM-order-quantity, TERM-inventory-available

---

## 直接影響

| 変更 | 因果タイプ | リスク | 緩和策 |
|------|-----------|--------|--------|
| createOrder引数変更 | 互換性 | High | 段階リリース |
| バリデーション追加 | 信頼性 | Medium | テスト追加 |

---

## 間接影響

| 依存先 | 影響内容 | リスク | 検証方法 |
|--------|----------|--------|----------|
| src/api/orders.ts | 引数変更の伝播 | High | test_api_orders |
| src/batch/process.ts | 型変更の影響 | Medium | test_batch_process |

---

## 未確認(unknown)

| 説明 | 潜在リスク | 調査方法 |
|------|-----------|----------|
| DI経由の呼び出し | 実行時エラー | 実行時テスト |
| 設定ファイル参照 | 環境依存 | 設定レビュー |

---

## 段階化計画

### Step 1: 型定義の更新 (Low)
- **変更内容**: OrderInput型に新フィールド追加
- **因果タイプ**: 互換性
- **検証方法**: tsc --noEmit
- **成功条件**: 型エラーなし
- **ロールバック**: git checkout -- src/orders/types.ts

### Step 2: バリデーション追加 (Medium)
- **変更内容**: validateOrder関数の強化
- **因果タイプ**: 信頼性
- **検証方法**: npm test -- orders.validation
- **成功条件**: 全テストパス
- **ロールバック**: git checkout -- src/orders/validation.ts

### Step 3: サービス実装 (High)
- **変更内容**: createOrder関数の修正
- **因果タイプ**: 互換性 + 信頼性
- **検証方法**: npm test -- orders.service
- **成功条件**: 全テストパス + カバレッジ80%以上
- **ロールバック**: git checkout -- src/orders/service.ts

### Step 4: 統合検証 (High)
- **変更内容**: E2Eテスト実行
- **検証方法**: npm run test:e2e -- orders
- **成功条件**: 全E2Eテストパス
- **ロールバック**: git revert HEAD~3

---

## 停止条件

### 標準停止条件
- [ ] 想定外のテスト失敗が3回発生
- [ ] ロールバック不可能な状態になった
- [ ] 観測不能な変更が増加

### カスタム停止条件
- [ ] セキュリティ脆弱性が発見された場合
- [ ] 性能が20%以上劣化した場合

---

## 次のアクション

1. [ ] Step 1から順次実行
2. [ ] 各ステップで検証を実施
3. [ ] 停止条件をモニタリング
4. [ ] 完了後 `/eld-ground-check` で接地確認

失敗パターン（必ず回避）

静的整合だけで完了扱い

NG: 「型エラーが消えたので完了」 OK: 「型エラー解消 + テスト通過 + 影響範囲確認」

表層エラーを消すための無理な対応

NG:

  • 無理なキャスト（
    as any
    ）
  • 例外の握り潰し（
    catch {}
    ）
  • 警告の無効化（
    // @ts-ignore
    ）

OK: 根本原因の解決

参照がないから安全と判断

NG: 「grep で参照がないから安全」 OK: 以下も確認:

  • DI/IoC経由の呼び出し
  • 設定ファイルからの参照
  • コード生成による参照
  • リフレクションによる呼び出し

物差し不足なのに意味の正しさを断言

NG: 「テストはないけど正しく動くはず」 OK: 「テストがないため意味の正しさは検証未完了」

チェックリスト

  • 変更の影響を因果タイプで分類したか
  • 直接影響と間接影響を分析したか
  • unknown（未確認）を明示的にマークしたか
  • 危険度に応じた段階化計画を立てたか
  • 各ステップでロールバック可能か確認したか
  • 停止条件を明確に定義したか
  • 失敗パターンに該当していないか確認したか

使用例

User: 注文作成機能の変更について影響予測して

Claude:
## Impact Prediction実行中...

### Step 1: 変更スコープ特定
- 対象: src/orders/service.ts (createOrder)
- 関連Law: LAW-pre-order-quantity, LAW-inv-stock-balance
- 関連Term: TERM-order-quantity

### Step 2: 直接影響分析
- API引数変更 → 互換性リスク(High)
- バリデーション強化 → 信頼性向上

### Step 3: 間接影響分析
- src/api/orders.ts → 引数伝播(High)
- src/batch/process.ts → 型変更影響(Medium)

### Step 4: unknown特定
- DI経由呼び出し: 要実行時確認

---

## Impact Prediction Report

### Summary
| 項目 | 値 |
|------|-----|
| リスクレベル | High |
| 推奨段階数 | 4 steps |

### 段階化計画

**Step 1**: 型定義更新 (Low)
**Step 2**: バリデーション追加 (Medium)
**Step 3**: サービス実装 (High)
**Step 4**: 統合検証 (High)

### 停止条件
- 想定外テスト失敗3回
- セキュリティ脆弱性発見

この計画で進めますか？

関連スキル

  • /eld-model-law-card
    - 関連Lawの確認
  • /eld-model-term-card
    - 関連Termの確認
  • /eld-ground-check
    - 変更後の接地検証
  • /eld-record-collection
    - 変更履歴の記録