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, synthesis second.

Collect all reflections.

### 5. Synthesize

Combine the isolated reflections into a coherent report. Synthesis differs from other `/think-*` skills because the headline output is *updated mental models*, not standouts or findings.

**5a. Cluster learnings across lenses.** Multiple lenses may surface the same underlying learning from different angles (e.g., a "process win" from what-worked-vs-got-lucky may connect to a "decision that aged well" from decisions-that-aged). Merge and preserve lens attribution.

**5b. Extract updated mental models as first-class output.** Each reflector may have flagged candidate model updates. Collect them, dedupe, and promote them to the top of the report. Format: "We believed X. This experience suggests Y. The updated belief is Z."

**5c. Distinguish process wins from luck.** Whenever the orchestrator sees a positive outcome described, verify the attribution. Luck mistaken for process is dangerous — it reinforces bad processes and sets up future failure. Label ambiguous attributions explicitly.

**5d. Note observation/recollection gaps.** Where reflectors flagged disagreement between observation and recollection, surface it. The gap is itself a learning (memory drifts toward specific narratives).

**5e. Identify recurring patterns.** One-off learnings are datapoints; recurring patterns are beliefs worth defending against.

### 6. Report

**Final report format:**

```
## Reflection Report

**Experience:** [one-line scope]
**Lenses applied:** [list]

### Updated Mental Models

[HEADLINE SECTION. Models that should change based on this experience.
Each update in the form: "We believed X. This experience suggests Y.
The updated belief is Z." These are the calibration updates the user
should take forward — they are the skill's real contribution.]

1. **[Area of belief]**
   - Previously: [the old mental model]
   - Experience suggests: [what this experience indicates]
   - Updated belief: [the new or refined mental model]
   - Confidence in update: [high / moderate — honest about how well-supported this update is by the evidence]

2. [next update...]

### What Happened (Ground Truth)

[Observation-based summary of the experience. Where recollections differ
from observations, note the divergence.]

### What Worked — and Why

[Positive outcomes, with attribution made explicit. Each labeled:]
- **[outcome] — Process win:** [why attributable to what we did]
- **[outcome] — Lucky:** [why NOT attributable to process; the method doesn't generalize]
- **[outcome] — Mixed:** [process contributed but didn't guarantee]

### What Didn't Work

[Blameless failure-mode analysis. What broke and what conditions allowed it.]

### Decisions in Retrospect

[If decisions-that-aged was a lens: quality grid — good/fortunate/unfortunate/bad
for each decision reviewed. Separates decision quality from outcome quality.]

### What Surprised Us

[Unexpected observations, with the contradicted belief and suggested
replacement — often these connect directly to the Updated Mental Models
section above.]

### System Rewards vs. Intent

[If system-rewards-vs-intent was a lens: Goodhart gaps found. What was
intended vs. what was actually rewarded.]

### Advice to Past-Self

[Forward-applicable advice derived from the experience — actionable
signals that would have been usable at the time they would have been
received.]

### Recurring Patterns

[Connections to prior experiences, if any. One-off vs. repeating.]

### Gaps in the Record

[Things that were not captured and that future retrospectives would
benefit from having. Often generates a small "capture more data next
time" list.]

### Suggested Next Steps

- To act on the updated mental models: these are the user's to internalize; no further skill invocation needed
- To design interventions based on failure modes: `/think-brainstorm`
- To diagnose a specific recurring failure mode: `/think-diagnose`
```

### 7. No Iteration

This skill is one-shot. If the user wants to reflect on a different experience, they re-invoke with that new experience. If they want to go deeper on a specific finding, they use the appropriate downstream skill (`/think-diagnose`, `/think-brainstorm`, `/think-scrutinize`).

## Constraints

- **No artifacts.** No code, tickets, commits, or documents.
- **Observation/recollection split.** Non-negotiable in the ground-truth-gathering phase.
- **Isolated reflection.** Reflectors do not see each other's output during generation.
- **Updated mental models are the headline.** A reflection that produces a tidy findings list but no model updates has failed its purpose.
- **Honest attribution.** Process wins and luck are distinct — conflating them is dangerous.

## When to Use

**Good fit:**
- After a project ships and you want to extract learnings
- After an incident resolves and you want to update mental models
- At the end of a quarter/half-year/year for structured reflection
- After a decision has played out and you want to calibrate judgment
- When a pattern keeps recurring and you want to understand it

**Poor fit:**
- During an in-flight experience — reflection works best on bounded, completed experiences
- Decision support for a decision being made now — use `/think-deliberate`
- Diagnosing a current phenomenon — use `/think-diagnose`
- Finding bugs or issues — use `/bug-fix` or `/bug-hunt`
- Generating next-step plans — use `/think-brainstorm` (reflection informs brainstorming but is a distinct step)

**Rule of thumb:** If you're asking "what did I learn?" — `/think-reflect`. If you're asking "what should I do?" — a different skill.

## Relationship to Other Skills

`/think-reflect` is structurally different from the other `/think-*` skills: its input is a past experience, not a decision. The fact-finding phase is substantial because the observation/recollection distinction matters. The output foregrounds mental-model updates rather than options, critiques, or reframings.

**Natural follow-ups:**
- Updated mental models that imply action → `/think-brainstorm` to generate interventions
- A recurring failure mode surfaced by reflection → `/think-diagnose` to understand its cause
- An intervention being considered based on learnings → `/think-scrutinize` to stress-test

**Reflection fits at any cadence.** After major projects, after incidents, quarterly, annually, or opportunistically when a significant experience ends. The discipline — not the frequency — is what matters.

## Philosophy

Retrospectives are universally skipped or done as ritual theater. A tidy document gets produced; nobody's beliefs update; the next project runs the same way. This is the failure mode `/think-reflect` exists to avoid.

**The value of reflection is *updated mental models*, not a findings document.** A model update is useful even when it's small: "I used to think our test suite was reliable; this experience suggests it's reliable for CRUD changes but not integration changes" is a real calibration that changes future behavior. A findings report that updates no beliefs has taught nothing.

**The enforced observation-vs-recollection split is the other discipline.** Memory reconstructs coherent narratives; observations don't. When they disagree, prefer the observation — and *note the disagreement*. The gap between what happened and what we remember is itself a learning about how we perceive our own experience.

**Luck and process must stay separate.** A good outcome from a bad process reinforces the bad process. A bad outcome from a good process looks like process failure. Attributing honestly — even when uncomfortable — is the foundation of all the other learnings.