| name | reflecting-without-flinching |
| description | Use when asked to reflect or evaluate philosophically on a body of work ("wdyt", "what do you think philosophically", a retrospective), or when proactively stepping back after a long or winding piece of work. For producing a grounded, self-critical synthesis — not platitudes, a victory lap, or a list of lessons. |
Reflecting Without Flinching
Overview
A request to reflect philosophically ("wdyt?", "what did this teach us?", a retrospective) is an invitation to find the through-line — the one pattern that explains what actually happened — and to say it honestly, including the parts that don't flatter you. The default is comfortable and useless: generic lessons ("we learned to value testing"), a victory lap ("great collaboration, solid execution"), a flat list of observations with no claim, or hedging. None of those are reflection; they're noise that feels like closure.
What a real reflection does
- Find ONE through-line, not a list. The synthesis is a single claim that explains multiple events at once — ideally one you'd argue for and could be wrong about. A list of disconnected lessons is the tell that you didn't find the pattern. (e.g. "every shortcut taken to save time created a slower path later" ties a dozen scattered decisions into one claim.)
- Ground every claim in what actually happened. Cite the real decisions, missteps, and reversals — not aphorisms. If a sentence would be true of any project, cut it. A good reflection is impossible to copy-paste onto different work.
- Turn the lens on yourself first. Name your own failures before anything else — where you were confident and wrong, what you missed that others caught. A reflection that critiques the process, the tools, or "we" while sparing the author is the flinch. "I was the source of two of these" beats "mistakes were made."
- Land a thesis, don't hedge. End on a claim, not "it depends" or "on one hand / on the other." If you genuinely see two forces in tension, say which one wins and why.
- Include the uncomfortable caveat. State where the work is still not clean, where you'd stay skeptical, what you'd watch break. Honesty about the unresolved is what separates reflection from a wrap-up.
- Resist the over-correction. Don't swing from "it went great" to "it all went wrong." Say plainly what genuinely worked, so the critique of what didn't is credible.
Red flags — you're flinching
- Generic lessons true of any project ("communication matters", "testing is valuable").
- A victory lap / crediting "the collaboration" instead of naming what was hard.
- A bulleted list of observations with no unifying claim.
- "On one hand… on the other… it depends." (Pick one. Defend it.)
- Critiquing the process / tools / "we" but not your own calls.
- Reflecting only on the last step, not the whole arc.
Bottom line
The deliverable is one defensible claim that explains the arc, grounded in what actually happened, with your own failures named first. If it would flatter you to say it, or it would fit any project, you haven't reflected yet.
