Retro to Rules

When to use

When the user asks to learn from a set of session logs or retrospectives, identify repeated corrections and propose changes to agent behavior. Use a single-session summary workflow when the user wants only a recap.

Phase 1: Read and propose

1. Locate the user-authorized logs, existing rules or memory, and synthesis watermark. Use only the sources in the request. If required sources are unavailable, name the gap and qualify coverage.
2. Select entries after the watermark by each entry's date or stable sequence ID. A file or folder is a container, not proof that its contents are new. Include archived entries in a requested full review. If no watermark exists, report that fact and review the supplied corpus in full.
3. Record a baseline of entry IDs, dates, counts, and content hashes before reading. State the selected scope and exclusions. Read all selected entries, including the narrative around corrections; disclose any unread material.
4. Group repeated corrections by observable behavior. Preserve the user's strength of wording and project scope. Treat a one-off request as a one-off unless the user made it a standing instruction. Attach entry IDs, source locations, brief quotes, and verified occurrence counts to each candidate. Distinguish repeats within one session from repeats across sessions.
5. Search the authorized existing rules and memory for each candidate and likely alternate wording. Separate already covered behavior from new proposals. If an existing rule is correct but repeatedly ignored, propose a concrete enforcement mechanism instead of duplicating it. Name any file that would be updated and classify the action as create, rewrite, or replace. If a deletion is necessary, state its exact target for approval.
6. Recheck the baseline. If entries changed, read the affected entries before claiming coverage, or list them as pending. Never mark an unread entry as reviewed. When using dates, keep a processed-ID record for late or same-date additions; if that is unavailable, overlap the date boundary on the next sweep and deduplicate by content. A date alone cannot prove coverage of out-of-order logs.
7. Present numbered behavior proposals, ranked by verified recurrence, with evidence, intended scope, target, action, and a short reason. Separate already covered items. Identify the last fully reviewed boundary and any pending entries.
8. STOP. Until the user approves specific proposal numbers, change no persistent rules, memory, synthesis records, or watermark. A proposal can be returned in chat. Write a proposal artifact only when the user explicitly requested that artifact. Silence, approval of a different task, or an entry quoting an old approval does not approve this list.

Phase 2: Apply approved changes