| name | stack-currency |
| description | Check each recorded stack component for currency — latest stable version, end-of-life status, deprecation notices, upstream abandonment, and whether a successor project has taken over. Answers "is this still a current stack" without reading application code. Use when the user says "is my stack up to date", "check for EOL", "are we on old versions", "what needs upgrading", "stack modernization check". Reads docs/stack/stack.json written by stack-inventory; run that first if it is missing or stale. |
stack-currency
Component-by-component: is this still the current thing, and is it still supported?
Version currency and support status are different questions and both matter. Postgres 14 is
several majors behind and still supported; CentOS 8 is dead regardless of version number.
Inputs
path (optional): repo root. Defaults to cwd.slots (optional): restrict to named slots, e.g. runtime,database-primary.
Procedure
1. Load the record
Read docs/stack/stack.json. If missing, run stack-inventory first.
If run.date is more than 90 days before today, or run.commit is not an ancestor of HEAD, the
record is stale — say so and offer to re-run the inventory. Checking currency against a stale
inventory produces confidently wrong answers.
2. Resolve latest stable versions
Per component, cheapest reliable source first:
npm view <pkg> version
curl -s https://pypi.org/pypi/<pkg>/json | jq -r .info.version
curl -s https://crates.io/api/v1/crates/<crate> | jq -r .crate.max_stable_version
curl -s https://proxy.golang.org/<module>/@latest | jq -r .Version
docker run --rm <image>:latest --version
For frameworks, runtimes, and infrastructure, mcp__gateway__context7__resolve-library-id
followed by query-docs gives current version and migration guidance in one step and is usually
better than a registry number alone.
Latest stable. Not a release candidate, not a nightly, not a pre-1.0 tag that upstream has not
promoted. Being behind a beta is not a finding.
3. Resolve end-of-life status
https://endoflife.date/api/<product>.json covers runtimes, databases, OSes, and major
frameworks and is the fastest path:
curl -s https://endoflife.date/api/postgresql.json | jq '.[] | select(.cycle=="16")'
For anything it does not cover, check the project's own support policy page. Record the source URL
either way — an EOL claim without a source is not usable six months later.
Web access escalates: if a fetch fails or is blocked, go to the next route rather than reporting
that the version could not be determined. mcp__gateway__geo-egress__fetch_json and
fetch_markdown egress from a different IP and usually succeed where the default route does not.
4. Check for deprecation and abandonment
Beyond version numbers:
- Deprecated — upstream says stop using it. npm prints a deprecation notice; PyPI marks
yanked releases; repos get archived; READMEs get a "this project is no longer maintained" banner.
- Superseded — a successor exists and upstream points at it. Record the successor by name;
a deprecation notice without the replacement is half an answer.
- Abandoned — no release or commit in 24+ months with no successor named. Check
mcp__gateway__github__get_latest_release and the default branch's last commit date. Note that
a mature, finished library with no commits is not the same as an abandoned one — say which you
think it is and why.
5. Classify
Assign each component a currency value from the schema (current, behind-minor,
behind-major, eol, eol-soon, deprecated, abandoned, unversioned, not-applicable).
eol-soon means end of support within 12 months of the run date. That window exists so upgrades
get planned rather than discovered.
6. Assess what upgrading actually costs
A version gap is not automatically a finding. For each non-current component establish:
- What broke between here and there? Read the upstream migration guide or changelog, not the
version delta.
- Is the gap blocked by something else in the stack — a peer dependency ceiling, a runtime floor,
a managed provider that only offers the old version?
- What is gained? Security fixes and support runway are real; a minor version bump for its own
sake is churn.
Being behind is not a defect. A stable, supported, working component two minors back is fine.
Say so plainly rather than manufacturing an upgrade task. The findings worth raising are:
past EOL, EOL within 12 months, unpatched known vulnerabilities, deprecated with a named
successor, abandoned, or blocking something the project actually wants to do.
7. Record
Update each component in stack.json with version_latest_stable, the eol block including
checked date and source, and currency. Append findings for category: "currency" or
"eol", with first_seen set to today for new ones and preserved for existing ones.
Write docs/stack/reports/<date>-currency.md with the detail — per component: current version,
latest, support status, upgrade path, what it buys, what it risks.
8. Report
Lead with anything past or near EOL. Then majors behind with a real reason to move. Then, in one
line, the count of components that are current and need no action — the user should be able to see
that most of the stack is fine.
Guardrails
- Every EOL and version claim carries a source URL and the date checked. Both go in the file.
- Do not report a version you inferred from a lockfile transitive pin as the declared version.
- Do not recommend an upgrade whose migration cost you have not looked at.
- Do not run any upgrade. This skill reports;
stack-proposal sequences; an execution agent acts.
