lore-sweep

Sweeping lore's recorded gaps

A zero-result search is a topic gap stated in an agent's own words, at the moment it cost somebody something. lore misses turns those into a queue. This skill works the queue.

The queue is self-cleaning: every candidate is replayed against the current repo before it is listed, so a gap someone has already filled drops off and is counted under resolved. You never have to prune it by hand, and you should never "close" a row by editing the log.

1. Read the queue

lore misses --json           # for working through programmatically
lore misses                  # human-readable
lore misses --since 30d --min-count 2   # only gaps that cost more than one session

Each row carries the query verbatim, how many times it was hit, which sessions hit it, the directory each was working in, and a suggested path.

2. Triage before you write

Not every row is a missing page. Sort each into one of four:

• Answerable now. The fact is recoverable from this machine — a man page, --help, the source, a quick experiment. Most rows. Go to step 3.
• Answerable only from the session that hit it. The session worked the problem out and the resolution is in its transcript. Use the ctx-agent-history-search skill, scoped to the cwd the row gives you. This is where the highest-value facts live, because a gap someone had to solve the hard way is exactly the gap worth recording.
• Not a gap — a category error. The session was addressing lore as if it were something else. A row like lore_read plans/backlog/2026-07-26-….md is a session looking for its own project's lab notebook; lore holds what outlives a single project. Do not write a page. Leave the row; it costs nothing and it is evidence about how sessions misread the tool.
• Still unknown. Nobody knows the answer yet. Leave it. A row that sits is honest.

Say which bucket each row went into. Do not silently skip a row.

3. Search lore before you write