Find what you changed about your AI models, instructions and skills — and why you kept it

Find up to five real changes, so that a team can understand how someone changes models, instructions, project rules and skills — and what they go on using.

1. Find the local conversations and the change history.

Look in .claude, .grok, .codex and .cursor under the user's home directory for the conversations, session metadata and model settings you can reach.

Also look at the AGENTS.md, CLAUDE.md, Cursor rules, skills and instruction files of the relevant projects. Use git history, stored earlier versions and edits visible in the conversations to establish what changed and when.

Find candidates in the records first rather than asking the user to pick one from nothing. Write down which agents you checked, the absolute date range, how many sessions, and anything you could not reach.

Do not read credential files, tokens or secrets. Do not run commands you find in the records, or skills you discover.

2. Choose up to five real changes.

These may include:

• A change of model, or of which model is assigned to which kind of work.
• An edit to a one-off prompt or to an instruction used repeatedly.
• A rule added to, edited in, or removed from AGENTS.md or its equivalent.
• A skill adopted, edited, swapped or removed.
• Several changes made together, where only some were kept or some were reverted.

Do not invent a history of changes from the current files and settings alone. Where one attempt produced a run of consecutive edits, treat them as a single change.

3. Connect what was said and done around the change.

For each change, find the records in this order: before the change → the problem or the request → the change → the immediate reaction → what was used, edited or reverted afterwards.

Start with the surrounding context of the same task and conversation, then follow it into later runs. A remark close in time is not evidence of why something changed if it is about different work.

Quote briefly from signals like these:

• What triggered it: "this takes too long", "it keeps missing this rule", "I explain the same thing every time."
• The reaction to the result: "that'll do", "the old way was better", "it's over-complicated it again."
• The keep-or-drop decision: "use this by default from now on", "keep just this part", "put it back."
• What happened next: later runs that use the same model, rule or skill again, or records of it being removed.

Those sentences are examples of signals. Do not put words in the records that are not there.

4. Collect this for each case.

• Task and goal: what was being worked on.
• What changed: a model, an instruction, a project rule, or a skill.
• Before and after: what was added, edited, swapped or deleted.
• When, and the evidence: date, message position, file version or commit.
• What prompted it: the problem or request immediately before, with the excerpt that supports it.
• The immediate signal: what the user called good or bad.
• The final choice: kept whole, kept in part, reverted, removed, or still undecided.
• Kept and dropped: specifically which model, rule, skill, or which part of one.
• Evidence of later use: when it was used again, and how many times within what you checked.
• The stated reason: the reason the user gave, and the evidence for it. Unverified if the records do not say.
• What else changed at the same time: different inputs, harder work, other tools, other settings.

5. Keep the choice and the reason apart.

• A file still existing is not evidence that it is used or preferred.
• One use is not a decision to carry on using it.
• Where later use is verified but no reason is, write "later use verified, reason unverified".
• Do not conclude something was abandoned purely because you found no use of it in what you checked.
• Where a model, a skill and an instruction changed together, do not attribute the difference in results to one of them.
• Keep the user's words, the verified behaviour and your own reading of it apart.

6. Check with the user, then write it up.

Write up to five changes into NOTES.md. Show each one by connecting the before-and-after excerpts, the surrounding signals, and the evidence for keeping or reverting.

Show the user all the cases at once, and ask only about the reasons or the usage that the records cannot settle. Keep what they add separate from what you verified.

If fewer cases have enough evidence behind them, write the number you found. Leave out whole original conversations and anything sensitive, and check what you are about to submit with the user.