A Retention Policy for Agent Memory: Flag Unused Skills at 30 Days, Archive at 90

A developer publishing as Lily has released the mechanics of a weekly job that appends a `status: stale` marker to Claude Code skills unused for 30 days and moves skills unused for 90 days into an `.archive/` directory ^[1][2]. That is a retention policy for agent memory, and the reason it matters is structural rather than tidy-desk aesthetic: according to the post, Claude Code's context injection grows with every skill file you add, so files nobody uses are paid for on every conversation ^[3].

The accumulation is by design. The post describes an auto-skill mechanism in which Claude, after completing a non-obvious task five or more times, discovering a workaround, or having its approach corrected, writes the procedure to `~/.claude/skills/auto/<kebab-name>/SKILL.md` ^[4]. A section in the author's `~/.claude/CLAUDE.md` instructs the model to write reusable procedures without being asked, which keeps the generator running ^[5]. Lily reports that once 30 or 50 skills have piled up, thousands of tokens go to descriptions of skills you are not using before the conversation starts ^[6], and claims that on Opus or full-quality Sonnet this degrades output while raising the monthly token bill ^[7]. That second claim is the load-bearing one and the post offers no measurement for it, so treat it as a hypothesis you can test in your own logs.

The implementation is conservative in the ways that matter. It takes a tarball snapshot into `.snapshots/auto-YYYYMMDD-HHMMSS.tar.gz` before touching anything ^[8]. It only processes skills carrying an `author: auto` front matter field, so hand-written skills are never candidates ^[9]. Last-used dates come from grepping the skill name across conversation log files under `~/Documents/my-knowledge-base/raw/conversations/` and taking the newest matching file's mtime, which the author states explicitly is a proxy for usage rather than an API-level call log ^[10]. If no match exists, it falls back to the `created:` front matter field, then to the `SKILL.md` file mtime ^[11]. Neither the 30-day nor the 90-day action deletes anything ^[12]. An optional step, triggered when at least two skills are active, asks Claude to write duplicate and low-quality consolidation candidates into `.curator-proposals.md` without modifying any skill ^[13]. Scheduling is a launchd job, `com.shun.skill-curate`, firing Sundays at 4:15 AM with LowPriorityIO ^[14][15].

Two consequences fall out of the thresholds. A flagged skill sits stale for 60 days before it is archived ^[1], roughly eight curator runs at a weekly cadence ^[2], which is a generous grace period for something the tool cannot actually prove is dead. And because the fallback chain starts the clock at `created:` when a name never appears in a log, a genuinely useful skill that the transcripts never mention by name gets flagged 30 days after creation ^[3]. That is the failure mode to instrument first: grep on names catches discussion, not invocation.

The author frames this as maintaining the environment's environment, and says most of the work behind a business he reports at 1.2M yen a month is designing ways to route work to Claude rather than doing the tasks ^[16][17]. Fair enough as motivation. The number that would settle the argument is the token count of injected skill descriptions before and after a curation pass, and how response quality moves with it. The post does not report either.