Identify the feedback source.
- Use PR review comments, CodeRabbit or Codex findings, CI failure analysis, bug reports, user corrections, or a completed task retrospective.
- Separate one-off requests from reusable failure patterns.
Read the project feedback ledger.
- Prefer ledger/review-feedback.md when present.
- If the project uses another durable task-memory path, use that path and name it in the final report.
- If no feedback ledger exists and the pattern is worth keeping, create a compact one.
Extract reusable lessons.
- For each candidate, write the specific issue, root cause, general implementation rule, evidence, and verification signal.
- Keep rules operational: future agents should know what to check before coding, not just what went wrong.
- Do not store secrets, long pasted comments, private user data, or full logs.
Deduplicate before appending.
- If an existing entry covers the same class of failure, update Last seen, Evidence, or Implementation rule instead of adding a parallel entry.
- If the same pattern recurs, strengthen the rule so it is harder to miss during planning.
Feed the ledger into future work.
- When starting implementation, read active feedback-ledger entries before planning.
- Carry relevant active rules into the plan, tests, and self-review checklist.
- If no entries apply, say that the ledger was checked and no relevant prior feedback was found.
Close or retire stale entries.
- Mark an entry Retired only when project structure, tooling, or policy makes the rule obsolete.
- Do not delete history unless it contains sensitive content that should not have been recorded.

Entry Format

Use this compact Markdown shape:

### YYYY-MM-DD - Short Pattern Name

- Status: Active
- Last seen: YYYY-MM-DD
- Source: PR review, CI failure, user correction, bug report, or retrospective
- Trigger: when this kind of implementation work starts
- Issue: what went wrong in the concrete task
- Cause: why the original implementation missed it
- Implementation rule: what future work must check or do before coding
- Evidence: concise links, file paths, PR numbers, or command names
- Verification: check that proves the rule was applied

Final Report

Include:

feedback sources reviewed
ledger path updated or consulted
entries added, updated, skipped as one-off, or retired
implementation rules future work should apply
any sensitive details intentionally omitted

retrospective-codify

Retrospective Codify

Workflow