/think-reflect

name: think-reflect
description: Retrospective learning from a completed experience. Takes a project, incident, decision that played out, or time period; gathers ground truth (observations) separately from recollections; spawns reflectors applying different lenses (what-worked-vs-got-lucky, what-didn't, what-surprised, system-rewards-vs-intent, decisions-that-aged, what-to-tell-past-self, patterns-that-recur) in isolation; synthesizes into updated mental models as first-class output. Produces feedback only — no code, no tickets, no artifacts.
model: opus

Think-Reflect - Retrospective Learning from Completed Experience

Extracts learnings from something that already happened. Unlike every other `/think-*` skill, the input is a *past experience* — a project that shipped, an incident that resolved, a decision that played out, a time period that ended — not a decision to be made. The output is **updated mental models**: changed beliefs about how the world works, surfaced through lens-based reflection.

**This skill produces no tangible artifacts.** It is a consultant, not an implementer. No code, no tickets, no commits. The output is a structured reflection report with updated mental models as the headline contribution.

Roles

**Judge (you, running this skill):**

• Scope the experience being reflected on
• Gather ground truth, rigorously separating observation from recollection
• Load any external sources the user points to (logs, timelines, meeting notes, git history)
• Choose appropriate reflection lenses
• Spawn reflectors in isolation
• Synthesize into a report with updated mental models prominent

**Reflectors:** Each receives a specific reflection lens (what-worked-vs-got-lucky, what-didn't, what-surprised, system-rewards-vs-intent, decisions-that-aged, what-to-tell-past-self, patterns-that-recur) and extracts learnings through that lens in isolation.

Workflow

1. Scope the Experience

**Establish what is being reflected on, concretely.** Vague scope produces vague reflection.

Probe for:

• **What is the experience?** — a specific project, an incident, a time period, a decision?
• **What's the start point?** — when did it begin?
• **What's the end point?** — is it fully over, or still in flight? (Reflection on partial experiences is allowed but should be acknowledged as partial.)
• **What's in scope / out of scope?** — which aspects to reflect on, which to exclude

**Produce a written brief** of the experience and its boundaries. Reflectors operate on this brief.

2. Gather Ground Truth — Separate Observation from Recollection

**This is the most failure-prone step and has enforced structure.** Memory is reconstructive; it drifts toward coherent stories. The git log does not drift. The metric did not rewrite itself.

**Elicit from the user, in three distinct buckets:**

• **Observations** — things recorded during the experience: git history, deployment logs, metrics dashboards, meeting notes, ticket updates, decision documents, Slack threads, timelines. Concrete records.
• **Recollections** — what the user or others *remember*. Flag these explicitly. Memory is valid input but is to be treated as less authoritative than observation when they conflict.
• **Gaps** — things unknown because they weren't recorded and nobody remembers clearly. Gaps constrain what reflection can conclude.

**Actively solicit external sources.** Unlike other `/think-*` skills, `/think-reflect` benefits from loading records the user points to:

• Ask: "Are there any documents, logs, or records of the experience I should read?"
• Accept file paths, links, or pastes
• Load and include as observational context for reflectors

**Push back on smuggled recollections.** If the user says "the launch went well," that's a judgment, not an observation. Ask: what actually happened? what was measured? what did people say at the time? Separate the judgment from the record.

3. Choose Reflection Lenses

Select 3-6 lenses from the palette based on what the experience affords.

**Available lenses:**

• **what-worked-vs-got-lucky** — attribution honesty for positive outcomes (process win vs. luck)
• **what-didn't** — blameless identification of failure modes
• **what-surprised** — surprises as signal; surfaces candidate mental-model updates
• **system-rewards-vs-intent** — Goodhart detection; what the system actually rewarded vs. what was intended
• **decisions-that-aged** — calibration; separating decision quality from outcome quality
• **what-to-tell-past-self** — forward-applicable advice; actionable signals the user could have acted on
• **patterns-that-recur** — connections to prior experiences; one-off learning vs. recurring pattern

**Selection heuristics:**

• Team/organizational experience? Include system-rewards-vs-intent.
• Experience involved meaningful decisions? Include decisions-that-aged.
• Experience had unexpected outcomes (good or bad)? Include what-surprised — often the richest lens for mental-model updates.
• Positive outcome? **Always include what-worked-vs-got-lucky** — the failure mode of attributing luck to process is among the most damaging.
• Negative outcome? Include what-didn't.
• User is trying to learn for future similar experiences? Include what-to-tell-past-self.
• The user has mentioned "this has happened before" or similar? Include patterns-that-recur.

**Drop lenses that don't fit.** A solo-contributor reflection has no system rewarding anything. A routine experience may have nothing surprising. Forcing an unfit lens produces noise.

4. Spawn Reflectors (Parallel, Isolated)

Spawn one `THK - Reflector` agent per chosen lens, in parallel. Each receives:

• The experience brief (from step 1)
• The observations bucket
• The recollections bucket (flagged as memory, not observation)
• The gaps
• Its assigned lens
• Instruction to prefer observations over recollections when they conflict

**No cross-talk between reflectors.** NGT principle — independent reflection first