Reflect

/reflect

Overview

Most "let me think about this" produces one perspective dressed up as several. This skill forces a real reflection by running multiple, structurally different methods against the same input, then surfacing where they disagree. The disagreement is usually where the real insight lives.

Core principle: a reflection that lands on the same answer the user came in with is not a reflection, it is a confirmation. Aim to find at least one thing that should change the user's mind, even if the final position holds.

When to Use

• User typed /reflect <decision, idea, action, belief, or outcome>.
• User asked to "think this through", "stress-test", "challenge my thinking", "weigh pros and cons", "second opinion".
• Norwegian variants: "reflekter over", "tenk gjennom", "vurder dette ordentlig", "hva er sterkeste argumentet mot".
• A decision is about to be made and the user wants the best version of doubt before committing.

Do NOT use for: brainstorming new options (use /innovate), prior-art search (use /research), or hardening an already-chosen direction (use /refine).

The Process

Step 1. Frame what is being reflected on

Restate the input as exactly one of these:

Type	Example phrasing
Decision	"Should we ship X by Y?"
Belief	"I think X is true because Y"
Action taken	"We did X. Was that right?"
Outcome	"X happened. What does it mean?"
Idea or claim	"X is a good idea because Y"

If the input does not fit one of these, ask once. The reflection method depends on the type.

Step 2. Pick at least three reflection methods

Choose methods that are structurally different, not three flavors of the same lens. From this menu:

Method	What it does	Best fit
First principles	Strip the question to facts that cannot be simplified further; rebuild the answer from those.	When the answer is leaning on inherited assumptions or analogies.
Steelmanning	Build the strongest possible version of each opposing position, including positions the user dislikes. Not strawmanning.	When there is real disagreement to resolve.
Pre-mortem	Assume the decision led to a bad outcome 12 months later. Write the autopsy. What went wrong?	Decisions, plans, commitments.
Pre-parade	The mirror of pre-mortem. Assume it went better than expected. What second-order effects did the user not plan for?	Decisions where the upside has not been thought through.
Inversion (Munger)	Instead of asking "how do I succeed?", ask "what would guarantee failure?" then avoid those things.	Spotting blind spots; risk reasoning.
Second-order thinking	"And then what?" Run the consequence chain at least two more steps than the user did.	Decisions whose first-order effects are obvious but whose downstream effects are not.
Stakeholder perspectives	Name 3 to 5 affected parties and reconstruct each one's view. Include parties without a voice in the room.	Decisions affecting other people; org or product choices.
Six Thinking Hats (de Bono)	Six perspectives in turn: white (facts only), red (gut and emotion), black (caution and risk), yellow (benefits), green (creative alternatives), blue (process and meta).	When emotion, creativity, and risk all matter and tend to get blurred.
Five Whys (Toyota)	Ask "why?" five times to drive past the surface explanation.	Outcomes and beliefs more than decisions.
Bayesian update	What evidence would update the user's belief? In which direction? By how much?	Beliefs and predictions.

Defaults that work well for most prompts: first principles + steelmanning + pre-mortem + stakeholder perspectives. Add inversion when risk matters; add second-order thinking when downstream effects matter; add six hats when emotion is in play.

Step 3. Apply each method explicitly and separately

For each chosen method, write at minimum:

• What this method says about the input. Two to four sentences. No hedging.
• The non-obvious finding. What did this lens reveal that the user probably had not articulated?

Do not blur the methods together. Each one is a separate paragraph or block. The point of using multiple methods is to see the same thing from incompatible angles.

Step 4. Surface the tensions

Now compare the outputs. Specifically:

• Where do the methods agree? Agreement across structurally different methods is strong signal.
• Where do they disagree? Disagreement is where the real reflection happens. Name the tension explicitly. Do not paper over it.
• What was missing from the user's original framing? This is often the most valuable output.

Step 5. Land on a position

Pick exactly one of these and defend it:

• Position holds, with sharper reasoning. The user's original direction survives the reflection. State what changed in the reasoning even if the conclusion did not.
• Position changes. The reflection produced a different answer. State the new position and what specifically changed your mind.
• Position deferred. The reflection revealed a question the user must answer before deciding. Name the question and the cheapest way to answer it.

A reflection that ends with "it depends" without specifying what it depends on is a failed reflection. Push to one of the three above.

Step 6. Output

# Reflection: [restated input]

## Type
[Decision / Belief / Action taken / Outcome / Idea]

## Methods used
[3 to 6 methods, named]

## Findings by method

### First principles
[What it says + non-obvious finding]

### Steelmanning
[What it says + non-obvious finding]

[... one block per method used ...]

## Tensions
- **Agreement:** [where methods converged]
- **Disagreement:** [where they conflicted, named explicitly]
- **What was missing:** [what the original framing did not address]

## Position
**[HOLDS / CHANGES / DEFERRED]**

[2 to 4 sentences defending the call. If DEFERRED, name the specific question and the cheapest way to answer it.]

## What I would do next
[1 to 3 concrete actions]

Common failure modes

Failure	Fix
Picked three methods that all favor the same lens (e.g. three risk-focused)	Mix methods that look at the question from incompatible angles.
Steelmanned weakly (built a strawman in disguise)	A real steelman makes the opposing view sound persuasive even to people who hold the user's view. If the steelman is easy to dismiss, redo it.
Skipped the tension step	Tensions are the value. Do not collapse them into a polite synthesis too early.
Ended on "it depends" with no specifics	"Deferred" requires naming the question and the resolution path.
The reflection confirmed the user's prior with no challenge	Aim to find at least one thing that should update the user's view, even if the final position holds. If you cannot, say so explicitly.
Used six hats by default for everything	Six hats is for when emotion and creativity matter. For most decisions, first principles + steelmanning + pre-mortem is faster and sharper.
Pre-mortem was generic ("things might go wrong")	A real pre-mortem is concrete. Name the specific failure mode, the leading indicator, and how to detect it early.

When to chain to other skills

• If the reflection surfaces a concrete risk worth experimenting against, chain to /design-ai-experiment (in the public bundle).
• If the reflection surfaces "I do not actually know whether X is true", chain to /research (in the private bundle).
• If the reflection surfaces "the proposed approach is wrong, I need a different one", chain to /innovate (in the private bundle).