One file. Four sections. Nothing slips.
Everything you meant to come back to, in one place.
You put things off — a bug you couldn't reproduce, a plan you paused, a warning you'd rather
fix later. Right now those live in a TODO comment, a plan file, an audit report, a note to
yourself, and your memory. Months later, "what did I put off?" means checking all of them.
unforget puts them in one file, sorted by whether they block your next release.
4 min read · every command · the format
One UNFORGET.md in your project. Each row is something you deferred:
| # | Target | Finding | Urgency | Effort | Status |
|----|----------|------------------------------------------|-----------|---------|--------|
| A1 | 🔴 THIS | Paywall lists a feature that ships free | 🟡 HIGH | Trivial | `@status:done-verified` |
| A2 | 🔵 NEXT | Slow loading on the inventory screen | 🟢 MEDIUM | Small | `@status:open` |Target is the column that matters: when does this have to be done?
| 🔴 THIS | Before the next release. This is the only one that stops you shipping. |
| 🔵 NEXT | The release after that. |
| 🟡 LATER | Further out. |
| ⚪ SOMEDAY | No promise. Written down so it isn't lost. |
When you ship, NEXT becomes THIS automatically, and LATER becomes NEXT.
Underneath the table, each row gets a few lines of detail: why it matters, which files, and a command to check whether it's still a problem. The table is the index; the detail is the story.
Every row carries a status the skill can read, and there are two kinds of done:
done-verified— fixed, and somebody checkeddone-unverified— the code is written, nobody confirmed it works
That second one still counts as open. It shows up in your list, and it stops a release until it's proven.
This exists because of a specific mistake: marking something done, believing it, and shipping. A row that says "done" because someone said so is not the same as a row that says done because it was checked, and only one of them should let you ship.
Run these one at a time, waiting for the first to confirm before the second:
/plugin marketplace add Terryc21/unforget
/plugin install unforget@unforget
Then, in a project:
/unforget init
Setup takes 5 to 15 minutes, once per project. It asks where to keep the file, looks through your project for things you've already deferred (TODO comments, plan files, audit reports, GitHub issues, notes), and shows you what it found before writing anything.
The step that finds the most is the one where it asks what's on your mind — the things no search could have found.
Why two separate commands?
Pasting both /plugin lines at once makes Claude Code read the second line as an argument to
the first. Run them separately.
Installing by hand
mkdir -p ~/.claude/skills
git clone https://github.com/Terryc21/unforget.git ~/.claude/skills/unforgetThen use /skill unforget (with the prefix). Update later with git pull in that folder.
Something comes up while you're working on something else:
/unforget add "rate limiter returns 429 even when under quota"
Takes seconds. If it took longer, you'd stop doing it.
Getting ready to ship:
/unforget list --target=THIS
That's your blocking list. Fix them, then /unforget promote checks they're really done and
rolls everything forward.
Probably yes if: you work alone or in a small team, the things you've deferred are scattered across several places, and you'd like your AI assistant to be able to read the list.
Probably not if: people outside your dev team need to file or read tickets, or you need sprints and story points. Jira and Linear do that; this doesn't try to.
They work together fine — unforget for the technical debt near your code, the other tracker for work that crosses teams.
- It's a file, not an app. Plain markdown. Renders on GitHub, opens in any editor, follows your repo. Nothing to lock you in.
- It knows about shipping. One column says when, and one moment each release moves everything forward.
- Your AI reads it without being asked. Setup wires it into your CLAUDE.md.
- It notices things going stale.
/unforget scanfinds rows sitting far longer than their priority suggests.
Solid. The format has been through a real App Store release cycle on Stuffolio, the app it came from. Setup has been tested twice against different project shapes, which caught 13 gaps that are now fixed.
Untested. It knows one shape well: a single developer shipping an app in distinct releases. Web services, libraries, continuous deployment, non-Apple stacks — there's a Continuous preset for time-based work instead of release-based, but nobody has really put it through its paces.
Real limits, worth knowing before you start:
- It assumes one person keeps the file tidy. Teams can share it through git, but there's no assigning, no comment threads, no notifications.
- It doesn't sync to anything. No Jira, no Linear, no GitHub Issues. You can paste links; nothing updates itself.
- You decide when to run the release check. Forget, and nothing moves forward on its own.
What would help most: try it on a project that isn't a mobile app and tell me where the format falls apart. Open an issue — small repos, web backends, Android, libraries, or a Cursor or Aider workflow are all more useful than another iOS report.
Audit tools and linters drop their unfixed findings straight in. Paused plans become a row that points back at the plan file. Any AI that reads your project instructions can read the file — Cursor, Copilot, Aider, Continue. It works with no AI at all, since it's just markdown.
It commits to git like any other file. After a merge conflict, open it in a preview to check the
table survived — a misplaced | breaks a table quietly.
Pairing it with the bug-finding skills → · If the file gets mangled →
| Every command | Full detail on each one |
| The format | Columns, statuses, and the optional 1-star-risk column |
| Setup | What init does, step by step |
| Release ritual | What promote checks before letting you ship |
| Splitting the file | When a sprint or someone else's list earns its own |
| Recovery | Repairing a broken file |
| SKILL.md | The instructions Claude follows, and the full changelog |
Reading the file outside Claude. Ten columns is wide. GitHub and GitLab render it fine, as do VS Code's preview, Obsidian, Typora, Bear, MacDown, iA Writer, and Marked 2. If a table looks broken in a narrow terminal, the file is fine — the window is too small.
The format is stable. What it needs is exposure to project shapes it hasn't seen.
Pull requests welcome for new presets, better staleness rules, integrations, and clearer errors.
Three things it won't take, because each breaks a promise the format makes: hiding columns on some rows, renaming or reordering the core columns, and splitting UNFORGET.md into several files.
bug-echo — find the same bug elsewhere after a fix · bug-prospector — hunt for bugs before a release · workflow-audit — trace SwiftUI behaviour · radar-suite — six skills tracing user paths · prompter — rewrite prompts before running them · skill-reviewer — candid reviews of other skills · tutorial-creator — lessons from your own code
New to Claude Code? A skill is a set of written instructions Claude Code knows how to
follow. Type /unforget add "..." and it adds a row to your file and tells you what it did.
Nothing to memorise, and the file stays plain markdown you can edit yourself.
Terry Nyberg, Coffee & Code LLC. It came out of Stuffolio, where deferred work had spread across five different places and pre-release prep meant checking all of them. If unforget has caught something for you, a coffee is appreciated — though a note about how it went on a project unlike mine is worth more.
Apache 2.0 — see LICENSE.