Big Idea

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupéry, Terre des hommes (1939)

Distill the central claim before authoring any summary-shaped output. Every hero subtitle, commit subject, PR title, ADR title, slide title, executive summary, and skill description should carry a Big Idea: a testable thesis that answers "what changes for the reader?", not an enumeration of what's inside the artifact.

Generalized from chart-big-idea, which specializes this discipline for chart authoring. This skill covers everything else.

When to Fire

When NOT to Fire

• Plain body prose — Big Idea authoring is for headlines, not paragraphs. Body prose defends the Big Idea; it isn't one.
• Bullet lists inside a doc — each bullet doesn't need its own thesis. The section header carries the Big Idea if any bullet does.
• Code comments — unless the comment IS a thesis (rare — most code comments explain how, not why anything changes).
• README intro paragraphs — those get to be longer than one sentence. Use Big Idea for the README's title tagline, not its opening paragraph.
• Chart workflow — when called by chart-big-idea, complete the shared distillation here and return the claim, audience, and stance. Do not load chart-big-idea again: the caller owns the Chart Brief and chart-specific constraints.

The four-step distill (plus emit)

Skipping any step is why summaries drift back to tactical enumeration. Run all four before writing the sentence.

1. Read for an existing Big Idea

Scan the source artifact (doc body / commit diff / ADR argument / slide content) for the central claim already stated. Often the Big Idea is buried in a middle paragraph or half-said in a conclusion. If it's there, extract; if not, distill from scratch.

2. Distill the claim

What is THE one thing this artifact argues? Not "what topics does it cover" — what claim does it make?

Test: if someone read only this sentence and nothing else, what would they know that they didn't before?

3. Story arc

Name the narrative shape — it informs the sentence's grammar and tense:

4. Audience + stakes

Who reads this artifact, and what changes for them?

• A Big Idea that names the reader's decision (implicitly or explicitly) is thesis-shaped.
• A Big Idea that names only the topic is TOC-shaped.

Test: read the draft and ask "so what?" If nothing changes for the reader, revise.

5. Stance

Is this Big Idea:

• Consolidating consensus — confirming what the reader already believes. Safer, less punchy, room for qualifiers.
• Challenging a norm — contesting a default assumption. Higher risk, higher payoff, strip qualifiers.

Analogous to TRADITIONAL vs. INNOVATIVE in chart-big-idea. The stance sets qualifier budget: consolidating leaves in "often"/"usually"; challenging strips them out.

6. Emit and compress

The Saint-Exupéry rule is the actual gate. Draft the Big Idea, then apply the removal test: try deleting each sentence. If deleting it leaves the claim intact, delete it. Repeat until removing another sentence would break the claim. What remains is the Big Idea.

Length ceiling depends on format:

Count the draft's sentences with the script, not by eye: node scripts/count-sentences.cjs <draft-file> --ceiling <N>, where N is the format's ceiling from the table above. The gate reads the script's count.

Discipline for every sentence that survives the removal test:

• Answers "what changes for the reader?"
• Names a specific claim, not a topic so the claim is testable.
• Someone could reasonably argue against it; if not, it's a truism, not a thesis.
• Concrete over abstract: carry a name, number, or contrast where possible.
• No TOC enumeration: no bulleted-list-as-sentence.
• No hedge stacking: pick one hedge or none.
• No compression theater: if a semicolon or colon is doing the work of a full stop and the second clause could stand as its own sentence, split it. Compression is real only when the removal test would break the claim.
• American English by default (if your project defines a language rule in copilot-instructions.md, follow it — Alex ACT itself uses American English). Use color, behavior, center, catalog, license, analyze, favor, honor, defense. Avoid colour, behaviour, centre, catalogue, licence, analyse, favour, honour, defence. Three carveouts stay: the [behaviour] commit-tag API string, ACT framework canonical terms, and ported material that retains its source spelling.
• No AI-tells. Alex ACT bans em-dashes as sentence separators in shipped prose; the full 29-pattern catalog is in humanizer. No em-dashes as sentence separators (use commas, colons, semicolons, parentheses, or full stops instead); no filler intensifiers (comprehensive, robust, leverage, seamlessly, delve into, tapestry, weave, testament); no load-bearing as a synonym for important / central / key (see humanizer Pattern 7 for the technical-vs-decorative carveout); no performative openers (Certainly!, Great question!, Let me...); no meta-description (This document explains..., The following is...); no ceremonial rule-of-three parallelism used as decoration rather than argument. The fixed-string part of this check (banned intensifiers, performative openers, meta-description, em dashes) is mechanical: run node scripts/lint-ai-tells.cjs <draft-file> and read its hits instead of scanning by eye. The judgment tells (rule-of-three, compression theater) stay with the reader.

Anti-patterns

Worked examples

From the 2026-07-28 hero-copy sweep on this repo. Note the shape: before is enumeration of contents; after is a compressed thesis (one or two sentences, per the removal test) with a subject verb and a because or so.

Cross-domain examples (not from a real commit — showing the shape)

Commit-message subject (arc: diagnostic; stance: challenging):

• Before: refactor: update fetch logic to handle timeouts
• After: [behaviour] fetch: 3s timeout replaces indefinite hang on unreachable release

PR title (arc: prescriptive; stance: consolidating):

• Before: Update dependencies
• After: Bump marked to 12.0.0 to unlock the token-object renderer API needed by mermaid-in-code-fence support

ADR title (arc: comparative; stance: challenging):

• Before: ADR-014: Mall v1 to v2 migration approach
• After: ADR-014: Mall in-place bump to 3.0.0 (not fork-and-freeze) because 5 of 25 heirs currently route through the affected surface

Related

• chart-big-idea — chart specialization. Both skills share the same six-step arc with offset numbering: chart-big-idea Step 0 (read context) → this skill's Step 1; chart-big-idea Steps 1-4 → this skill's Steps 2-5; chart-big-idea Step 5 emits a Chart Brief while this skill's Step 6 emits prose.
• Skill descriptions ARE Big Ideas — the frontmatter description field's "what + when" is the thesis + trigger of the skill's Big Idea.
• communication-craft — sibling skill for feedback, audience, and elicitation. Communication craft frames the whole message; Big Idea frames only the headline.
• humanizer — the 29-pattern AI-tell catalog and voice replacements. Big Idea authoring routes through humanizer for the AI-tell check before emit.
• problem-framing-audit — different discipline: audit the frame BEFORE solving. Big Idea distills the claim AFTER solving. Both cite the same "is this the right thing?" test but at different phases.

Falsifiability

This skill has failed if any of the following occur:

• Decorative steps: the four-step distill (context read → claim → arc → stance → emit) consistently produces identical output to skipping steps 3–5 — the extra steps are ritual, not method
• Drifts from parent: chart-big-idea upstream evolves in a way this skill can't accommodate — the specialization relationship broke

Would Revise If

• A domain surfaces where step 3 (story arc) doesn't map cleanly to the five listed arcs → extend the table with the missing arc, or reduce to arcs-are-optional guidance