mcpField
D
decay

decay

github.com/neolabhq生産性1.8k1.2k 回インストール9 週間前に更新
リポジトリ

decay について

decayは、FPFの証拠の鮮度を管理するスキルです。古い証拠と影響を受ける仮説を特定し、更新、非推奨化、期限付きのリスク受容を記録できます。

主な機能

  1. 01証拠の鮮度レポート作成
  2. 02期限切れの証拠を含む仮説の特定
  3. 03証拠の更新・非推奨化・免除
  4. 04対応と理由の記録

活用シーン

  1. 01週次メンテナンスで古い証拠を確認
  2. 02リリース前に判断根拠を点検
  3. 03大幅な変更後に古い仮説を非推奨化

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/neolabhq/context-engineering-kit --skill decay

インストール後、Claude Code で/decayを入力して読み込まれたか確認します。

詳細

エビデンスの鮮度管理

エビデンスの鮮度を管理し、古くなった意思決定を特定して、ガバナンス上の対応を提示します。FPF B.3.4（エビデンスの劣化）を実装しています。

重要な原則： エビデンスは劣化します。期限切れのエビデンスに基づく意思決定には、見えないリスクが伴います。

基本概念

「古くなった」エビデンスとは？

すべてのエビデンスには valid_until の日付があります。6 か月前のベンチマークは、現在のシステム性能を反映していない可能性があります。主要な依存関係を更新する前に実施したセキュリティ監査では、新たな脆弱性を考慮できません。

エビデンスの期限が切れると、それが裏付ける意思決定は疑わしいものになります。必ずしも誤りというわけではなく、検証されていない状態になるだけです。

「免除」とは？

免除 ＝「このエビデンスが古くなっていることは承知しています。一時的にリスクを受け入れます。」

次のような場合に使用します。

  • リリース直前で、すべてのテストを再実行する時間がない
  • エビデンスの期限が少し過ぎただけで、まだ有効である可能性が高い
  • 適切に更新する日程が決まっている

免除は問題を無視することではありません。リスクを把握し、特定の日付まで受け入れることを明示的に記録します。

3 つの対応
状況対応内容
エビデンスは古いが、意思決定はまだ有効更新テストを再実行し、新しいエビデンスを取得する
意思決定が時代遅れで、再検討が必要非推奨化仮説の評価を下げ、評価をやり直す
一時的にリスクを受け入れる免除期限付きでリスクを受け入れたことを記録する

対応（実行時）

ステップ 1：鮮度レポートを生成する
  1. .fpf/evidence/ 内のすべてのエビデンスファイルを一覧表示します
  2. 各エビデンスファイルについて、以下を行います。
    • フロントマターから valid_until を読み取ります
    • 現在の日付と比較します
    • FRESH、STALE、EXPIRED に分類します
ステップ 2：レポートを提示する
## Evidence Freshness Report

### EXPIRED (Requires Action)

| Evidence | Hypothesis | Expired | Days Overdue |
|----------|------------|---------|--------------|
| ev-benchmark-2024-06-15 | redis-caching | 2024-12-15 | 45 |
| ev-security-2024-07-01 | auth-module | 2025-01-01 | 14 |

### STALE (Warning)

| Evidence | Hypothesis | Expires | Days Left |
|----------|------------|---------|-----------|
| ev-loadtest-2024-10-01 | api-gateway | 2025-01-20 | 5 |

### FRESH

| Evidence | Hypothesis | Expires |
|----------|------------|---------|
| ev-unittest-2025-01-10 | validation-lib | 2025-07-10 |

### WAIVED

| Evidence | Waived Until | Rationale |
|----------|--------------|-----------|
| ev-perf-old | 2025-02-01 | Migration pending |
ステップ 3：ユーザーの対応を処理する

ユーザーの応答に基づき、以下のいずれかを実行します。

更新

ユーザー：「redis キャッシュのエビデンスを更新して」

  1. .fpf/knowledge/L2/ 内の仮説に移動します
  2. 検証を再実行し、新しいエビデンスを作成します
非推奨化

ユーザー：「認証モジュールの意思決定を非推奨化して」

  1. 仮説を L2 から L1（または L1 から L0）に移動します
  2. 非推奨化の記録を作成します。
# In .fpf/evidence/deprecate-auth-module-2025-01-15.md
---
id: deprecate-auth-module-2025-01-15
hypothesis_id: auth-module
action: deprecate
from_layer: L2
to_layer: L1
created: 2025-01-15T10:00:00Z
---

# Deprecation: auth-module

**Reason**: Evidence expired, technology landscape changed

**Next Steps**: Run `/fpf:propose-hypotheses` to explore alternatives
  1. 仮説ファイルを移動します。
mv .fpf/knowledge/L2/auth-module.md .fpf/knowledge/L1/auth-module.md
免除

ユーザー：「2 月までベンチマークを免除して」

  1. 免除の記録を作成します。
# In .fpf/evidence/waiver-benchmark-2025-01-15.md
---
id: waiver-benchmark-2025-01-15
evidence_id: ev-benchmark-2024-06-15
waived_until: 2025-02-01
created: 2025-01-15T10:00:00Z
---

# Waiver: ev-benchmark-2024-06-15

**Evidence**: ev-benchmark-2024-06-15
**Hypothesis**: redis-caching
**Waived Until**: 2025-02-01
**Rationale**: Migration pending, will re-run after completion

**Accepted By**: User
**Created**: 2025-01-15

**WARNING**: This evidence returns to EXPIRED status after 2025-02-01.

自然言語での使用方法

エビデンス ID を覚える必要はありません。 希望する内容を説明するだけで構いません。

ワークフローの例
User: /fpf:decay

Agent shows report with stale evidence

User: Waive the benchmark until February, we'll re-run it after the migration.

Agent: Creating waiver for ev-benchmark-2024-06-15 until 2025-02-01.
       Rationale: "Re-run after migration"

       [Creates .fpf/evidence/waiver-benchmark-2025-01-15.md]

User: The vendor API is being discontinued. Deprecate that decision.

Agent: Deprecating hypothesis-vendor-api from L2 to L1.
       [Moves file, creates deprecation record]

       Next step: Run /fpf:propose-hypotheses to explore alternatives.

WLNK の原則

仮説のエビデンスのうち、期限が切れているもの（免除されていないもの）が1 つでもあれば、その仮説はSTALEです。

これは Weakest Link（WLNK）原則です。信頼性 ＝ すべてのエビデンスの最小値です。古いエビデンスが 1 つあるだけで、意思決定全体が疑わしいものになります。

監査証跡

すべての対応を記録します。

対応記録内容
非推奨化from_layer、to_layer、reason、date
免除evidence_id、until_date、rationale、date

.fpf/evidence/ に作成されるファイル：

  • deprecate-{hypothesis}-{date}.md
  • waiver-{evidence}-{date}.md

一般的なワークフロー

週次メンテナンス
/fpf:decay                    # See what's stale
# For each stale item: refresh, deprecate, or waive
リリース前
/fpf:decay                    # Check for stale decisions
# Either refresh evidence or explicitly waive with documented rationale
# Waiver rationales become part of release documentation
重大な変更の後
# Dependency update, API change, security advisory...
/fpf:decay                    # See what's affected
# Deprecate obsolete decisions
# Start new hypothesis cycle for replacements

コメント

Markdown 対応