think-reflect

What this skill does

# 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