Decay
- 848 installs
- 1.3k repo stars
- Updated July 26, 2026
- neolabhq/context-engineering-kit
decay is a context-engineering skill that flags expired evidence on decision records and prescribes governance actions for developers who must keep architecture and ops choices aligned with current benchmarks and audits.
About
decay is a skill in neolabhq/context-engineering-kit that implements FPF B.3.4 Evidence Decay for decision-record governance. Every evidence item carries a valid_until date; when benchmarks, security audits, or performance measurements expire, linked decisions inherit hidden risk until evidence is refreshed or superseded. The skill scans decision artifacts for stale supporting evidence and outputs governance actions such as re-benchmarking, re-auditing, or formally accepting residual risk. A benchmark from six months ago may no longer reflect current system performance, and a security audit completed before a major dependency upgrade cannot account for newly introduced vulnerabilities. Developers reach for decay when ADRs, launch checklists, or ops runbooks still cite outdated load tests or expired compliance proof. It complements context-engineering workflows that treat evidence as perishable rather than permanent justification for ship and operate choices across the software lifecycle.
- Maps FPF B.3.4 evidence decay to three governance actions: Refresh, Deprecate, and Waive
- Treats expired valid_until evidence as questionable decisions rather than silently trusting old proof
- Documents temporary risk acceptance with explicit waivers and a planned refresh date
- Separates “re-run proof” (Refresh) from “rethink the decision” (Deprecate)
- Surfaces hidden risk when benchmarks, audits, or test results are no longer current
Decay by the numbers
- 848 all-time installs (skills.sh)
- +47 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #553 of 3,301 Productivity & Planning skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/neolabhq/context-engineering-kit --skill decayAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 848 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | July 26, 2026 |
| Repository | neolabhq/context-engineering-kit ↗ |
How do you detect stale evidence on architecture decisions?
Govern decision records when supporting evidence has expired so shipping and ops choices are not based on stale benchmarks or audits.
Who is it for?
Engineering teams maintaining decision records and ADRs who need systematic evidence freshness checks under the FPF Evidence Decay model.
Skip if: Greenfield projects with no decision history or teams that only need one-time security scanning without ongoing evidence governance.
When should I use this skill?
The user asks whether benchmarks, audits, or decision evidence are stale, expired, or still valid for a ship or ops choice.
What you get
Stale-evidence reports, valid_until audit lists, and governance action recommendations tied to decision records.
- stale-evidence reports
- governance action lists
By the numbers
- Implements FPF B.3.4 Evidence Decay governance pattern
Files
Evidence Freshness Management
Manages evidence freshness by identifying stale decisions and providing governance actions. Implements FPF B.3.4 (Evidence Decay).
Key principle: Evidence is perishable. Decisions built on expired evidence carry hidden risk.
---
Quick Concepts
What is "stale" evidence?
Every piece of evidence has a valid_until date. A benchmark from 6 months ago may no longer reflect current system performance. A security audit from before a major dependency update doesn't account for new vulnerabilities.
When evidence expires, the decision it supports becomes questionable - not necessarily wrong, just unverified.
What is "waiving"?
Waiving = "I know this evidence is stale, I accept the risk temporarily."
Use it when:
- You're about to launch and don't have time to re-run all tests
- The evidence is only slightly expired and probably still valid
- You have a scheduled date to refresh it properly
A waiver is NOT ignoring the problem - it's explicitly documenting that you know about the risk and accept it until a specific date.
The Three Actions
| Situation | Action | What it does |
|---|---|---|
| Evidence is old but decision is still good | Refresh | Re-run the test, get fresh evidence |
| Decision is obsolete, needs rethinking | Deprecate | Downgrade hypothesis, restart evaluation |
| Accept risk temporarily | Waive | Record the risk acceptance with deadline |
---
Action (Run-Time)
Step 1: Generate Freshness Report
1. List all evidence files in .fpf/evidence/ 2. For each evidence file:
- Read
valid_untilfrom frontmatter - Compare with current date
- Classify as FRESH, STALE, or EXPIRED
Step 2: Present Report
## 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 |Step 3: Handle User Actions
Based on user response, perform one of:
Refresh
User: "Refresh the redis caching evidence"
1. Navigate to the hypothesis in .fpf/knowledge/L2/ 2. Re-run validation to create fresh evidence
Deprecate
User: "Deprecate the auth module decision"
1. Move hypothesis from L2 to L1 (or L1 to L0) 2. Create deprecation record:
# 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 alternatives3. Move the hypothesis file:
mv .fpf/knowledge/L2/auth-module.md .fpf/knowledge/L1/auth-module.mdWaive
User: "Waive the benchmark until February"
1. Create waiver record:
# 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.---
Natural Language Usage
You don't need to memorize evidence IDs. Just describe what you want.
Example Workflow
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 Principle
A hypothesis is STALE if any of its evidence is expired (and not waived).
This is the Weakest Link (WLNK) principle: reliability = min(all evidence). One stale piece makes the whole decision questionable.
---
Audit Trail
All actions are logged:
| Action | What's Recorded |
|---|---|
| Deprecate | from_layer, to_layer, reason, date |
| Waive | evidence_id, until_date, rationale, date |
Files created in .fpf/evidence/:
deprecate-{hypothesis}-{date}.mdwaiver-{evidence}-{date}.md
---
Common Workflows
Weekly Maintenance
/fpf:decay # See what's stale
# For each stale item: refresh, deprecate, or waivePre-Release
/fpf:decay # Check for stale decisions
# Either refresh evidence or explicitly waive with documented rationale
# Waiver rationales become part of release documentationAfter Major Change
# Dependency update, API change, security advisory...
/fpf:decay # See what's affected
# Deprecate obsolete decisions
# Start new hypothesis cycle for replacementsRelated skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.645k185kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.547k185k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.466kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).466kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.466kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.465kHow it compares
Use decay after decisions are recorded when evidence ages out; use premortem-style skills before committing to plans that have not yet failed.
FAQ
What does decay consider stale evidence?
decay treats evidence as stale once its valid_until date has passed relative to the current decision context. Examples include load benchmarks older than the current architecture, security audits completed before major dependency upgrades, and performance measurements that no lon
Which framework pattern does decay implement?
decay implements FPF B.3.4 Evidence Decay from the neolabhq context-engineering-kit First Principles Framework. The governing principle is that evidence is perishable: decisions justified only by expired benchmarks, audits, or measurements carry hidden operational risk until team
Is Decay safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.