lore-lessons

Lore lessons

You turn this person's past corrections into short rules they can review. The tools come from Lore's MCP server. Each rule you file lands in Lore's inbox as a proposal. The person accepts or rejects it later.

1. Learn what already exists

Call recall_memory with cwd set to the absolute path of the current directory. Leave out query. Read every note it returns. Never propose a rule that an existing note already states. If a rule sharpens an existing note, pass that note's id as updates.

2. Read every candidate

Call mine_candidates with cwd set to the absolute path of the current directory. While its next_cursor is not null, call it again with the same cwd and cursor set to that value. Read every page before you decide anything. If there are no candidates, say so and stop.

Each candidate has the person's words, a suggested rule, receipts, and may_conflict_with. A receipt names the session, agent, date, and repository. It quotes the person's correction, what the agent had just done as before, and the agent's reply as after. The reply's cwd_repo is the repository at the current directory.

3. Understand each candidate

A correction alone is often unclear. "no, cause you never get to access it" means nothing without the turn it answers. For every receipt, read before, then correction, then after, and work out two things.

• What the agent did that the person did not want.
• What the person wanted instead.

If before and after do not make both clear, drop the candidate. Do not guess.

4. Keep standing rules only

Keep a candidate only when it states a rule a future session should follow. Drop these.

• Questions.
• One-off orders about a specific branch, PR, file, or task.
• Explanations of what happened.
• Venting.

5. Group by meaning

Put candidates that mean the same thing in one group, even when the words differ or have typos. One group becomes one rule. The group keeps all its receipts.

6. Check later turns