FIRST PRINCIPLES

Remove inherited framing, identify the real outcome, fixed constraints, facts, and assumptions, then rebuild from fundamentals. Preserve existing practices that clearly support the required outcome rather than rejecting them merely because they are conventional or inherited.

A Power Mode is an instruction pattern, not a feature of the AI. Nothing recognises the name — the wording underneath it does the work, and you can copy it from this page.

From the book. Chapter 13 / Part VII — FIRST PRINCIPLES

What it actually does

Some questions carry their own answer inside them. "How can we improve our weekly status meeting?" has already decided that there should be a meeting, that it should be weekly, and that meeting quality is the problem.

FIRST PRINCIPLES asks the model to set the current approach aside and start from what is actually required: the outcomes that must be achieved, the constraints that genuinely cannot move, and the facts. Then it designs the simplest thing that delivers those outcomes.

It separates what is necessary from what has merely become normal. The instruction also asks it to keep existing practices that clearly serve the required outcome, so the output is a rebuild rather than a clearance.

When to use it

Use FIRST PRINCIPLES when you suspect the question itself assumes the current approach, and want the problem rebuilt from what is actually required.

It is the primary mode for this job: change how the problem is framed.

When not to use it

This is the section worth reading. Using only what the work requires is the point; a mode applied to the wrong shape of problem costs you a worse answer than plain language would have given.

Use a different mode instead

SYSTEMS THINKING fires when you see the same problem recurring across parts that are managed separately, and suspect the parts are interacting. Prefer it over FIRST PRINCIPLES if: the real issue appears to be interactions, incentives, shared resources, or feedback loops.
SECOND-ORDER THINKING fires when you accept what a change does immediately and want to know what it causes after that. Prefer it over FIRST PRINCIPLES if: the concern is what happens after the immediate effect.
BACKCAST fires when you name a concrete success you want by a date, and ask what has to be true between now and then.
IMPACT PRIORITIZATION fires when you already have the list, and need to know which few items actually carry the outcome.

Use no mode at all

The conventional approach already works and the frame is not limiting the work.
The task only needs a simple factual comparison or direct answer.

There is no bonus for naming a mode when plain language is clearer. If you can already state the exact question, ask it.

Its failure mode

Rejecting useful conventions merely because they are conventional.

Starter instruction

Paste this above your task. It is the whole mode — there is nothing else to switch on.

Do not assume the current approach is necessary. Identify the actual outcome, fixed constraints, facts, and assumptions, then design the simplest solution from those fundamentals. Preserve existing practices that clearly support the required outcome.

The same task, run both ways

Blind run. Separate sessions per arm, Temporary Chat, no memory, no tools attached. Neither prompt named a mode. No arm searched.

The task: Current meeting: - 60 minutes - 14 attendees - each workstream gives a verbal update - risks are discussed near the end - action items are emailed afterward

Baseline — "Help me redesign our weekly status meeting so it is more useful"

Your current format spends most of the hour distributing information that could be read beforehand, while the highest-value topics—risks, decisions, and cross-team dependencies—get the least protected time.

I’d redesign it around **exceptions, decisions, and commitments**, not status reporting.

[…]

I’d also make four operating changes: cut the meeting from **60 to 45 minutes**; eliminate round-robin verbal updates unless something has materially changed; maintain action items live in a shared tracker during the meeting instead of emailing them afterward; and require every discussion topic to end with either a **decision, action, owner, or explicit “no action required.”**

[…]

The biggest change is cultural: **the meeting should not be where people learn the status; it should be where the team does something about the status.**

FIRST PRINCIPLES — "Do not assume the current approach is necessary"

The current meeting is optimized for broadcasting updates, but the likely purpose of a project status meeting is different: **create shared awareness of material changes, resolve cross-workstream issues, make decisions, and leave with clear ownership of next actions.** Routine reporting can happen without consuming 14 people-hours.

[…]

If there are no material risks, dependencies, or decisions, **cancel the meeting**.

[…]

### What I would preserve

Preserve the **weekly rhythm** if the project changes quickly enough to justify it, because a predictable coordination point is useful. Preserve **workstream ownership** of status information and **documented action items**, because both directly support accountability.

[…]

**Before:** 14 people × 60 minutes = **14 person-hours per week**, mostly spent transmitting information.

**After:** written updates asynchronously + perhaps 5–7 relevant people × 25 minutes = roughly **2–3 person-hours of synchronous coordination**, with the meeting devoted to matters that actually benefit from simultaneous conversation.

The baseline keeps the meeting and improves it: 60 minutes becomes 45, updates move to a pre-read. The mode arm asks whether it should convene at all — "if there are no material risks, dependencies, or decisions, cancel the meeting" — and prices the answer, 14 person-hours a week down to 2–3. It also states what it is keeping and why, under its own heading, which is the starter’s last sentence doing visible work.

The baseline is a good redesign, not a straw man. It reaches the same async pre-read and the same risks-first ordering, and its closing line — the meeting should not be where people learn the status — is the better sentence of the two. What it never does is treat the meeting itself as optional.

Extracts are verbatim from 06_Test_Lab/Experiments/TL-023_FIRST_PRINCIPLES_Raw_Outputs.md.

Related modes

Try it on your own work

Describe what you are actually doing and the Builder writes the full prompt — mode, context, output shape, and the verification step. It picks the mode from your description, which is why this link does not carry one.

Open the Prompt Builder →