### What to look for

Read the full transcript for these signals:

**User corrections or redirections**
- "no", "actually", "that's not right", "you need to also...", "you missed..."
- User provides information Claude didn't know or couldn't infer from code
- User reminds Claude of a step, pattern, or relationship
- A correction about something other than current task requirements is ALWAYS rule-worthy

**Investigation and debugging**
- Claude tried multiple approaches, read logs, or tested hypotheses
- Investigation revealed non-obvious behavior or root causes
- Debugging strategies that worked (or didn't) for specific areas

**Architecture not evident in code**
- Files that must change together (templates + installation, routes + registration)
- Complex files, data flows, pipelines, or system interactions that would benefit from an overview

**Commands and workflows**
- Specific commands or flags needed for this area
- Order of operations that matters ("must run X before Y")

**Ignore:**
- Corrections to requirements for the current feature or bug
- Confusion isolated to the current work session (won't recur)

### Before creating a rule

**Critical check:** Read the actual source files that were modified. If the code already contains comments, guard patterns, or tests that explain the insight, the code is the documentation — skip the rule unless the file is complex and you've made a mistake or the user had to interrupt and correct you.

Show your thinking before proceeding with creating or updating rules.

### How to write rules

**Rules must be forward-looking, not historical.** You are reading a session transcript where bugs were found and fixed, but the rule should describe the *current* codebase, not tell the story of what went wrong, what was fixed, etc. The code has already been updated — past bugs are no longer relevant.

- **DO**: State constraints and requirements ("this script MUST copy directories recursively, not just files")
- **DO**: Explain *why* something matters ("errors in prompt copying are silently caught, so missing directories won't surface as errors")
- **DON'T**: Describe what old code did ("the old version only copied files, causing X to be missing")
- **DON'T**: Narrate the debugging journey ("we discovered that the catch block was swallowing errors")
- **DON'T**: Note issues or known gaps if they are actively being worked on!

Think of the reader as a developer about to modify these files. They need to know what constraints to preserve and what pitfalls to watch for — not what happened in the past if it is no longer relevant.
