stack-version-audit

name	stack-version-audit
description	Find the lowest-version repos in a fleet for Node, Next.js, React, Vite, Prisma, TypeScript, ESLint. Produces a prioritized upgrade queue. Use when planning fleet-wide version upgrades — you want to know "which 5 repos are on Next 14 and which 10 are on Next 15" before deciding where to spend the time. Cites real patterns from a fleet where the lowest repos were on Prisma 5.22.0 and Next 14.
sources	github-search, package-analysis

Stack Version Audit

When the user says "upgrade the fleet to current versions", you need to know which versions are in use. This skill produces a fleet-wide version table.

Per-Stack Audit

For each version category, get all repos in the fleet and their pinned version.

Node

for repo in $(gh repo list --limit 200 --no-archived --json name -q . | jq -r '.[]'); do
    node_ver=$(gh api repos/camster91/$repo/contents/.nvmrc 2>/dev/null | jq -r '.content' | base64 -d 2>/dev/null | tr -d 'v' || \
              gh api repos/camster91/$repo/contents/package.json 2>/dev/null | jq -r '.content' | base64 -d 2>/dev/null | jq -r '.engines.node // "?"')
    echo "$repo: $node_ver"
done | sort -k2 -V

Or check the CI workflow's node-version: for the source of truth.

Next.js

for repo in $(gh repo list --limit 200 --no-archived --json name -q . | jq -r '.[]'); do
    next_ver=$(gh api repos/camster91/$repo/contents/package.json 2>/dev/null | jq -r '.content' | base64 -d 2>/dev/null | jq -r '.dependencies.next // "-"')
    [[ "$next_ver" != "-" ]] && echo "$repo: $next_ver"
done | sort -k2 -V

React

for repo in $(...); do
    react_ver=$(... | jq -r '.dependencies.react // .devDependencies.react // "-"')
    [[ "$react_ver" != "-" ]] && echo "$repo: $react_ver"
done | sort -k2 -V

Prisma

for repo in $(...); do
    prisma_ver=$(... | jq -r '.devDependencies.prisma // "-"')
    client_ver=$(... | jq -r '.dependencies["@prisma/client"] // "-"')
    [[ "$prisma_ver" != "-" || "$client_ver" != "-" ]] && echo "$repo: prisma=$prisma_ver, client=$client_ver"
done

Vite, TypeScript, ESLint, etc.

Same pattern — extract from package.json via gh api and jq.

Output Format

**Stack version audit (59 active repos)**

### Node
- `oldest-frontend`: Node 16 (out of support, security risk)
- `mid-tier-app`: Node 18 (current LTS)
- `newest-stack`: Node 20 (current LTS)
- 2 repos don't specify Node version (uses npm default)

### Next.js
- `markup-clone`: 14.2.18 (latest 14)
- `budget-app`: 15.0.0 (early 15)
- `SealSend`: 16.2.6 (latest)
- 8 repos use Next.js 15 or 16
- 3 repos use Next.js 14 (consider upgrading)

### Prisma
- 6 repos on Prisma 5.22.0 (needs upgrade to 7)
- All others on Prisma 6 or 7

### Priority queue
1. **Critical**: Prisma 5 → 7 in 6 repos
2. **High**: Node 16 → 20 in 2 repos (security)
3. **Medium**: Next 14 → 15 in 3 repos
4. **Low**: TypeScript 4 → 5 in 5 repos

Prioritization Heuristics

Not all upgrades are equal. Prioritize:

1. Security: Node versions out of LTS (Node 16, 18 → upgrade to 20)
2. EOL frameworks: Prisma 5 (still supported but legacy), Next 13 (EOL)
3. Major breaking changes: React 18 → 19, ESLint 8 → 9
4. Minor updates: less critical, can wait for Dependabot

Output for the User

**Recommended upgrade order (estimated time):**

1. **Prisma 5 → 7 in 6 repos** (4-6 hours)
   - Use `prisma-fleet-migration` skill
   - Requires lazy-proxy pattern + lockfile regen

2. **ESLint 8 → 9 in 3 repos** (1-2 hours)
   - Use `eslint-flat-config-upgrade` skill
   - Lower risk, often the first upgrade in a fleet

3. **Node 16 → 20 in 2 repos** (30 min)
   - Update CI workflow `node-version: '20'`
   - Update `.nvmrc` if present

4. **Next 14 → 15 in 3 repos** (3-4 hours)
   - Update `next` dep version
   - Run build, fix any breaking changes

Common Pitfalls

1. Don't conflate "available" with "pinned" — ^15 means "15 or higher"; for fleet planning, use the lowest version in the range.
2. Don't trust README or docs — they're often out of date. Always check package.json (or .nvmrc for Node).
3. Some repos have the version in CI workflow, not in package.json — check both.
4. Monorepos may have different versions per workspace — iterate per workspace.

Related Skills & Chains

• fleet-ci-audit — Use this first to get the fleet state, then prioritize upgrades
• prisma-fleet-migration — The most common upgrade after a stack audit
• eslint-flat-config-upgrade — The second most common
• lockfile-regen — When bumping versions, lockfiles need regen