reflect

Reflect

A four-phase process for learning from experience without lying to yourself about it. The enemy of a good reflection is the convenient story — the tidy narrative that protects the ego, blames the weather, or credits luck as skill. This process is built to defeat that. Work the phases in order; Phase 1 before judgment, Phase 3 before conclusions are the load-bearing rules.

Phase 1 — Reconstruct (Socratic, facts before verdicts)

Get the events on the table before anyone evaluates them. Judgment too early contaminates the facts. Ask the user to walk through what happened, then probe with specific questions — batched, not one at a time:

• What was the actual sequence? Build a rough timeline. What happened, in what order?
• What was expected vs. what occurred? Where did reality diverge from the plan or prediction?
• What did you know and when? Separate what was knowable at the time from what's only obvious now.
• What were the decisions and their reasons — as understood then, not with hindsight?
• Concrete evidence, not impressions. "It went badly" → what specifically, measured how?

Hold back evaluation here. If the user jumps to "I should have…", note it but steer back to facts first. Reflect the reconstruction back and confirm it's accurate before analyzing.

Phase 2 — Analyze (structured retrospective)

Now make sense of it. Structure the retro; cover:

• What worked — and why. Not just the wins, but the cause. Repeatable, or luck?
• What didn't — and why. Same: dig past the symptom to the mechanism.
• Root causes. For the main outcomes, ask "why" until you hit something fundamental — a process, an assumption, an incentive, a missing skill — not a surface event. A late launch isn't a root cause; the thing that made it late is.
• Inflection points. The moments where a different choice would have changed the outcome.
• What was outside your control vs. what was inside it — kept honest by Phase 3.

Phase 3 — Challenge (adversarial)

Attack the analysis. The story so far is probably too kind, too tidy, or both. Push hard on:

• Self-serving bias. Are successes credited to skill and failures blamed on circumstance? Flip it: what went right by luck, and what went wrong that was actually within your control?
• Hindsight bias. Is a "lesson" only obvious now? Was it genuinely knowable and ignored, or are you punishing a reasonable past decision for an unlucky outcome?
• The comfortable narrative. What explanation is being reached for because it's easiest to live with? What's the version of events you'd rather not write down?
• Single cause. Is a messy, multi-cause reality being flattened into one clean villain?
• The non-event. What didn't happen that should have? What was avoided rather than confronted?

Name the strongest 2–4 challenges directly. Revise the analysis where they land. The goal isn't self-flagellation — it's an account accurate enough to actually learn from.

Phase 4 — Distill & deliver

Turn the honest analysis into something that changes future behavior:

• Lessons — stated as transferable principles, not just "that was bad."
• Concrete changes — specific things to do differently, start, or stop. Vague resolutions ("communicate better") don't count; make them actionable.
• What to keep — what worked and should be deliberately repeated.

Deliver the retrospective and offer to save it to a markdown file in the current working directory (e.g. retro-<slug>.md). Keep the final artifact focused on the lessons and changes — that's what gets reread later.