Capability Scan — the self-learning routine

What it is: a repeatable pass that compares what Claude/Sam HAVE (MCP connectors, skills, local scripts, connectors) against the friction Sam keeps HITTING (recurring pains from recent sessions), then surfaces the wirings that would remove that pain. It is the answer to SCOPE_BACKLOG 38-K7 "no real self-learning loop" + Sam's standing ask: "it has to self-learn and offer those things even if it's a basket."

Why it exists: Claude keeps gaining capabilities (new MCPs, new skills) and Sam keeps hitting the same frictions, but nothing systematically connects the two. Without this, capabilities sit unused and pains recur. This routine makes the connection explicit on a cadence.

First run: outputs/2026-05-26_14-15_audit_capability-scan-first-run.html.

The procedure (any Claude Code session can run this)

Step 1 — Inventory what's available (capabilities)

• claude mcp list → every MCP connector + its health (Connected / Needs auth / Failed).
• The skill catalog (the session's available-skills list) — note both platform skills AND Sam's own hookstreet-skills.
• ls scripts/*.ps1 *.sh → local automation scripts.
• Note especially: capabilities that are idle (connected but unused) or broken (failed/needs-auth) — those are either dead weight or untapped.

Step 2 — Mine the friction (recurring pains)

Read, newest first, looking for repeated pains (not one-offs):
- docs/SCOPE_BACKLOG.md — the session blocks + KB-cleanup items (the 38-K* style entries are gold — they're self-diagnosed gaps).
- .remember/recent.md + .remember/today-*.md — recent session breadcrumbs (when the writer works).
- The last ~10 outputs/ files — what kept needing hand-work.
- The current session's own friction (what cost minutes).

A pain qualifies if it shows up in 2+ sessions OR cost real time more than once.

Step 3 — Match capability ↔ pain

For each pain, ask: is there a capability we already have that would kill this, and just isn't wired? Three buckets:
- Unwired capability — we have the tool, it's not connected to the pain (e.g., schedule skill ↔ "things don't fire on their own").
- Dead weight — capability that's connected/listed but does nothing (wire it to a need or drop it so the inventory stays honest).
- Gap — pain with NO capability yet (flag for a build decision; don't force a tool that doesn't fit).

Step 4 — Rank + report

• Rank recommended wirings by leverage (how much recurring pain removed ÷ effort).
• Write the report to outputs/YYYY-MM-DD_HH-MM_audit_capability-scan.html (portal format).
• Anything that's a recurring autonomous agent or removes a connector = say-go item (flag, don't auto-execute).
• Local + reversible wirings (git hooks, hookify rules, doc refreshes) = safe to build if Sam's in go-mode.

Cadence

Recurring trap log (feed hookify)

Traps that have bitten more than once — codify these as hookify rules so they auto-warn:
- .json.json double extension when saving downloaded files on Windows (Gmail OAuth keys hit this 2026-05-26).
- Non-ASCII (em-dash, smart quotes) in .ps1 files → Windows PowerShell 5.1 reads UTF-8 as ANSI and the parse breaks. Keep scripts ASCII-only.
- clasp push needs --force in non-interactive mode when the manifest exists (else "Skipping push").
- MIS dedup-date written BEFORE send → crash-reentrancy / double-fire. Write the guard AFTER a successful send.
- clasp redeploy / clasp deploy wipes Web App config → only clasp push (code) is safe on live Web Apps.

What "honest inventory" means

The scan is only useful if it tells the truth, including about itself:
- Don't recommend a tool that doesn't fit just to fill the page — a real gap (no capability) is a valid, useful finding.
- Flag dead weight plainly (a failing/unused connector is noise — wire it or drop it).
- Don't claim a wiring works until it's tested (verification-before-completion).

Created 2026-05-26 · Session 39 · in response to Sam's "do the capability scan routine" + the standing self-learning ask. Repeatable by any session; recurs via the cadence table above.