think-reflect

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 c