From b17z-sage
Evaluate and maintain knowledge freshness - detect and fix stale knowledge
How this skill is triggered — by the user, by Claude, or both
Slash command
/b17z-sage:sage-knowledge-hygieneThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
When knowledge is recalled, evaluate its freshness. Stale knowledge injects wrong context.
When knowledge is recalled, evaluate its freshness. Stale knowledge injects wrong context.
| Signal | How to Detect | Example |
|---|---|---|
| Version mismatch | Knowledge mentions old version | "Post v2.4" when we're on v2.6 |
| Temporal markers | "TODO", "planned", "upcoming", "will be" | Feature listed as TODO but shipped |
| Contradiction | Recalled content conflicts with current facts | "Not implemented" but we just used it |
| Date references | Specific dates in the past | "Q1 2025 roadmap" |
Different knowledge types decay differently:
| Type | Decay Rate | Evaluate For |
|---|---|---|
knowledge | Medium | Version refs, temporal markers, contradictions |
preference | Very slow | Only explicit user contradiction |
todo | Fast | Completion, age without action (30+ days) |
reference | Slow | Source validity, version refs |
sage_update_knowledge(
knowledge_id="the-id",
content="Updated accurate content",
)
sage_deprecate_knowledge(
knowledge_id="the-id",
reason="Superseded by v2.6 skills architecture",
replacement_id="new-knowledge-id", # optional
)
sage_archive_knowledge(knowledge_id="the-id")
sage_update_knowledge(
knowledge_id="the-id",
content=None, # Keep content
# Just accessing it updates last_recalled internally
)
When you see recalled knowledge, ask:
If any answer is yes -> remediate immediately.
Recalled knowledge says:
"Post v2.4.0 - TODO: Proactive recall on session start"
But we're on v2.6 and proactive recall shipped in v2.5.
Action:
sage_update_knowledge(
knowledge_id="feature-ideas",
content="Updated content marking proactive recall as shipped...",
)
npx claudepluginhub joshuarweaver/cascade-featured --plugin b17z-sageGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.