Why Your Skill Library Gets Messier Over Time: Subtract from Your Backlog with the "Diff Note Method"

**Applicable Scenario:** You have collected or written many skills (prompts, workflows, scripts), but you often can't remember which version works and which is long obsolete. Searching for the right one takes more than ten minutes.

---

The Problem: The "In-Only, No-Out" Skill Library

Most people manage their skills in a one-way direction:

1. Find a useful technique → Save a copy

2. Technique gets upgraded → Save another copy (too lazy to delete the old one)

3. Three months later → Three files with the same name, versions guessed entirely from filenames

The result: Your skill library is nominally an "asset," but actually a "dumpster." Before you can actually use anything, you have to do archaeology—digging through directories, opening files to compare, and recalling why you made changes back then. One round of this eats up ten minutes. Worse yet is the "fear of deleting": What if I need it again someday? So, obsolete versions permanently occupy space in your library.

What Is the Diff Note Method

Every two weeks (or whenever there is a major version update), perform a "differential inventory" of your skill library. Record only the **changes**, without rewriting the entire library. Each inventory session produces a diff note no longer than 20 lines, structured into four fixed sections:

- **Added**: What skills were added this week? Clarify the trigger condition in one sentence (when should you use it).

- **Replaced**: Which old skill was superseded by a new version? Mark the old version as `deprecated` and specify "when not to use it anymore."

- **Deleted**: Remove directly, leaving only one line stating "what was deleted + why."

- **Unchanged**: Write nothing.

Archive these notes in the root directory of your skill library. This can be a rolling `CHANGELOG.md` or monthly files (e.g., `diff-2026-08.md`). The key rule: **Record only the delta.** Three months from now, you (or a colleague) should be able to understand "how the library changed during this period" within 30 seconds of reading the notes.

When to Use It

- You have more than 15 skills, with duplicate or similarly named files (e.g., `prompt-v2-final-actually-v3.md`).

- You find yourself spending more time "finding the right version" than actually "using the skill."

- Multiple people share a skill library—in this case, diff notes serve as both release notes and handover documentation.

- Your skills depend on external tools, and tool upgrades silently break old implementations.

When Not to Use It

- Your library has fewer than 5 skills—a simple list is enough; don't over-engineer the process.

- Your skills are already in a strictly version-controlled Git repository—use `git log`, tags, and PRs instead; diff notes would be reinventing the wheel.

- You are still in the "wild growth phase"—accumulate real pain points over two or three months first before introducing a method; introducing it too early only creates unnecessary ritual.

Action Checklist (Single Inventory Session, Under 15 Minutes)

1. List all skills in the library (filenames only; do not open content).

2. Ask three questions for each item: When was the last time I used it? Is there a current alternative? Which version will I use next time?

3. Categorize the answers into Added / Replaced / Deleted / Unchanged.

4. Write the diff note; add a header marker to replaced old files: `⚠️ DEPRECATED: Superseded by xxx, 2026-08-16`.

5. Save/commit. If deprecated files receive no objections after two weeks, delete them directly.

Common Pitfalls

- **Writing a chronological log**: Diff notes are not logs. Absolutely do not write about "unchanged" items; otherwise, the notes become unreadable in the next inventory, turning the notes themselves into new clutter.

- **Replacing without deleting**: Leaving obsolete files in place is the source of chaos. Marking them is the first step; deletion is the goal.

- **Too frequent**: Doing this weekly becomes a new burden. Bi-weekly or monthly is a reasonable rhythm; higher frequency indicates the library itself isn't stable yet.

- **Shared team library but only one person doing inventory**: Diff notes must go into a shared repository and undergo review; otherwise, it's as if you did nothing—others won't know about your changes and will continue piling new files based on old versions.

- **Notes and library out of sync**: Forgetting to sync the diff note when deleting a file (or vice versa). Completing both in the same commit is the most efficient discipline.

One-Sentence Summary

The value of a skill library lies not in quantity, but in "the one that works correctly as soon as you open it." The Diff Note Method lets you spend 15 minutes maintaining this order, rather than spending 15 minutes doing archaeology every time you use it.