Turn Every AI Pitfall Into a Guardrail by End of Day

---

theme: cyanosis highlight: atom-one-dark

First, look at the finished product. This is a real retrospective briefing I generated:

## Retrospective Briefing
**Root cause this time**: Before writing source code containing special characters, a step to "identify escape-sensitive characters" was missing;
       after writing, a step for "integrity verification" was also missing.
**Historical comparison**: Stepped on the same pitfall a second time. The old memory existed but the trigger description was vague, retrieval failed → Rewrote the old memory.
**Consolidated**: Rewrote memory — when writing source code containing control characters, avoid escape notation,
       use String.fromCharCode instead; trigger scenario: before AI writes a file.
**Outstanding suggestions**: None

My daily work now is chatting with an AI IDE: describe requirements, AI implements, I verify, problems arise, fix them, problems arise again. There's an inconspicuous fact in this loop: AI does not grow its own memory. The pitfall it steps into this time, if you ignore it, it will step into it again in the next new session. What actually grows is the part you actively consolidate.

The Retrospective Skill I wrote does exactly one thing: at the end of every task, forcibly turn the pitfalls encountered this time into memories and skills that the AI can read when it starts work next time. Pitfalls stepped on today automatically become guardrails tomorrow. Inside are three disciplines, all bought with my own pitfalls.

Discipline One: Retrospective is execution, not writing a report

I used to do retrospectives too: write a document, list a bunch of "things to watch out for next time," and then never open it again. The result was stepping on the same pitfalls. There was one pitfall I stepped on twice.

That pitfall was tiny: when having the AI write a script, the source code contained escape notation for control characters, and when writing the file the content was truncated in whole sections. It took half a day to locate the cause. The second time I stepped on the same pitfall, I finally understood the problem: the output of a retrospective is "suggestions," but what the AI reads when it starts work next time is its startup context — memories and skills. Suggestions lying in a summary document that nobody opens means nobody executes them.

So I set the hardest rule for myself: the closing action of a retrospective must be executing one consolidation. Write a memory, or add a step to a skill, or supplement a script — pick one of three, must land. A retrospective that only outputs a suggestion list is counted as invalid.

Discipline Two: Three-layer root cause, only consolidate the process layer

When analyzing a problem, ask three layers from shallow to deep. Take the control character pitfall again:

Layer	Question	Answer for this example
Phenomenon layer	What result was wrong	The written file was truncated in whole sections, content incomplete
Behavior layer	Why was it written wrong	Directly used escape notation, didn't anticipate the write step's special handling of control characters
Process layer	Which missing step allowed it to happen	Before writing, a step to "identify special characters" was missing; after writing, a step for "integrity verification" was missing

If you only consolidate to the phenomenon layer — "remember this file was truncated" — next time with a different file, a different character, you'll still step on it. Lessons at the behavior layer rely on human memory, also unreliable. Only conclusions at the process layer can be consolidated, because they are missing steps, and steps can be enforced: written into a checklist, written into a skill, the AI will follow them every time.

So my rule is: only consolidate process-layer conclusions. Specific values at the phenomenon layer go into project memory archives, behavior-layer lessons go into pitfall records, process-layer gaps are upgraded into checklist items or skill steps. The three-layer questioning method itself is domain-agnostic; frontend style restoration, API integration debugging, build failures, data correction can all use it, only the "authoritative source of truth" differs per line.

Discipline Three: Retrieve before writing, don't create new for repeated pitfalls

Earlier I mentioned stepping on this pitfall twice. Actually, after the first time, I had already consolidated it. The result was still stepping on it a second time.

Upon investigation, that memory was written too vaguely, the trigger description was unclear, and retrieval at startup simply didn't associate it. This forced out another rule: the value of a memory lies not in its content, but in whether it can be recalled next time.

Therefore, you must retrieve before writing. Judgments fall into three types: exact duplicate — the same pitfall stepped on for the Nth time, meaning the old memory's retrieval failed or the granularity is wrong; in this case don't create new, rewrite the old memory, make the trigger scenario words specific, e.g., "before writing any source code containing escape characters, recall this first." New variant of the same kind — create a new one, but reference the old entry in the content, explaining the distinguishing boundary between the two. Brand new problem — create normally.

A memory bank is not more useful the larger it is. Many things die as they are written: everything is written, nothing can be retrieved.

Five-step process quick reference

The complete process has five steps; you can directly copy this checklist:

- [ ] S1 Collect fact list: what was fixed, all errors/rework/rejections,
      verification evidence for each problem, which steps were manually repeated
- [ ] S2 Three-layer root cause: phenomenon → behavior → process, ask until a modifiable process gap is reached
- [ ] S3 Historical duplicate retrieval: search using pitfall keywords,
      determine exact duplicate / new variant of same kind / brand new
- [ ] S4 Execute consolidation: deduplicate → write, execute whichever type is matched
- [ ] S5 Output retrospective briefing: root cause / historical comparison / consolidated / outstanding, each section no more than 5 lines

Accompanied by a consolidation product criteria table:

Product	Criterion	Action
Project memory	Project-specific configuration, data structures, environment contracts	Write to project memory, deduplicate before creating
General pitfall memory	A lesson that still holds when switching projects	Record phenomenon/root cause/fix/boundary, must attach trigger scenario
Task archive	Complete execution snapshot of this task	Keep original records, corrections done by appending
Skill / Script	This time 2 or more instances of manual repetition with a fixed pattern appeared	Create a new skill, or attach the script to an existing skill

The last row actually holds the highest value: the same manual operation appearing twice means this step can be automated, written into a script and attached to a skill. Several of my efficiency scripts came about this way, none of them planned in advance.

After running for a while, what changed

I won't talk about efficiency percentages, that can't be calculated; I'll talk specifics. Now when having the AI write files containing special characters, it will first retrieve this memory, and the escape truncation issue hasn't happened again. The pitfall stepped on twice, never stepped on again after the second time.

The biggest change is actually mindset. Before, I was a bit afraid of stepping on pitfalls — rework, annoyance, time wasted. Now I'm relatively calm; the pitfall stepped on today will be automatically loaded by the AI tomorrow, and the lost time at least gets exchanged for an asset.

Also clarify the boundary: it won't make the AI smarter, and it can't replace testing. It just turns lessons from one-time pain into reusable things.

Finally

If you also work by chatting with AI every day, before clocking out today you can try one thing: pick a problem you reworked today, ask the three-layer root cause, and write the process-layer conclusion somewhere the AI can read when it starts work. You'll feel the difference once.

If you want the complete SKILL.md, say so in the comments, and I'll release it. Also welcome to chat: what pitfall have you repeatedly stepped on when collaborating with AI?