# Stale Check

> Verify a memory file's claims against the repo, git, npm and the live service, and propose the edit. Use for "is this memory still true", "audit my memory", "stale check <project>".

- Skill: `kitfunso/stale-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kitfunso/stale-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kitfunso/stale-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: kitfunso (https://skillmd.com/u/kitfunso)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kitfunso/stale-check

---


# Stale check

Memory records what was true when it was written and rots without saying so. The global rule already says to treat any pending-or-broken memory claim older than about a week as unverified. Nothing did the verifying. This is the verifier.

Takes one memory file (or one project), checks every claim that can be checked, and proposes the edit. It never applies it.

## 1. Split the file into claims

Read the file and list every load-bearing claim: a version, a commit sha, a branch, a file path, a function name, a URL, a count, a state word (`SHIPPED`, `BLOCKED`, `LIVE`, `PENDING`, `NOT yet`), a date-relative statement.

Sort each into one of three buckets before checking anything:

- **Checkable now** — something in this session can settle it.
- **Checkable, but not from here** — needs a login, a phone, a paid console. These go to `/human-blockers`, not to a guess.
- **Not checkable** — a preference, a decision, a lesson. Leave these alone. A rule about how to work is not stale because it is old.

## 2. Check the checkable ones

One command per claim, and the command goes in the report so Keith can re-run it.

| Claim shape | How it settles |
|---|---|
| version published | `npm view <pkg> version`, `pip index versions <pkg>` |
| commit / branch / head | `git -C <repo> log -1 --format=%h`, `git -C <repo> branch --show-current` |
| file or function exists | `Read` the path, `Grep` the symbol |
| a service is live | one `curl -s -o /dev/null -w '%{http_code}'` against the URL |
| a count | the query or `wc` that produced it |
| open PR, CI state | `gh pr list`, `gh pr checks` |
| a gate is open | read the `docs/LAUNCH.md` row, not the memory line |

Never settle a claim by reasoning about it. If no command settles it, it is unverifiable, which is a verdict, not a failure.

## 3. Verdict per claim

- **VERIFIED** — the source agrees. Say so and move on; no edit.
- **STALE** — the source disagrees. Give the old text, the new fact, and the command that shows it.
- **UNVERIFIABLE** — nothing here settles it. Say what would.

A memory file where every claim comes back VERIFIED is a good result and takes one line to report. Do not manufacture findings to justify the run.

## 4. Propose, do not apply

Memory files are hand-maintained. Output one block per stale claim:

```
<file>:<line>
  was:  <the current text>
  now:  <the corrected text>
  why:  <command and its output>
```

Then wait. Keith says apply, or edits it himself. Do not write to the memory file, `MEMORY.md`, or hippo before he does, and do not delete a claim you could not verify: unverified is not the same as wrong.

When he applies, update the memory file and `hippo remember` the correction in the same session, per the writeback rule.

## Scope

One file, or one project's files, per run. A sweep over all 225 memory files produces a report nobody reads and burns a session doing it. Run it on the project you are about to work on, at the start, which is also where a stale claim would have cost the most.