Default behavior: verify package/framework/version recommendations against current state before suggesting them

Problem

Claude Code agents will confidently recommend specific packages, frameworks, libraries, or version numbers based on training data without verifying current state. Training cutoff means these recommendations may be silently stale — archived, deprecated, superseded, or version-rolled past the version cited. The failure mode is invisible: the agent doesn't surface "I'm not sure if this is current" because it has no signal that its knowledge has expired.

For non-trivial architectural decisions, this turns into real cost: the user adopts the recommendation, builds against it, and only discovers the deprecation later.

Concrete example (April 2026)

In a recent session, Claude Code was helping design a Windows desktop auto-update pipeline. The first-pass recommendation leaned on Clowd.Squirrel (a Squirrel.Windows fork) as the maintained Windows update framework — based on training-era guidance.

Clowd.Squirrel was archived 2024-07-05 (github.com/clowd/Clowd.Squirrel — README explicitly redirects to Velopack as the successor by the same maintainer). The agent caught this only after I prompted explicit research, not by default.

Velopack — the actual maintained successor — could itself have been deprecated between training and now, and the agent would have confidently named it the same way. Every architectural recommendation that names a specific package/framework is exposed to this failure.

Proposed behavior

Add a default rule (system-prompt, skill, or hook) that triggers whenever the agent is about to recommend:

• A specific named package (velopack, pyinstaller, winsparkle, etc.)
• A specific version number (React 19, Tailwind 4, Postgres 16, Sonnet 4.5, etc.)
• A specific framework / service / API
• A specific model identifier

The rule: before the recommendation lands in a response, design doc, or persisted artifact, verify current state via WebFetch / WebSearch / package registry lookup. Findings should be visible in the response so the user can audit.

Implementation options

1. System-prompt addition — most universal, no opt-in needed
2. Default skill that triggers on certain phrase patterns
3. Hook in settings.json that fires on tool calls referencing named tech
4. Per-project opt-in via CLAUDE.md convention (this is what we're doing locally as a workaround)

Option 1 has the highest impact / lowest configuration burden. Option 4 is what we're forced to do today, but it only protects the projects where someone thought to add it.

Why this isn't solvable from the model side alone

The cutoff is structural — the model genuinely doesn't know what it doesn't know. External verification (web / registry lookup) is the only signal that breaks the silent-failure loop. Adding a default behavior that mandates the verification step removes the "did Claude remember to check?" ambiguity from every interaction.

Adjacent precedent

This is the same shape as security-defaults that ship in tools by default (no need to opt in to running tests, no need to opt in to lint warnings). For an agent that increasingly handles architecture decisions, "verify what's still alive" deserves the same treatment.