ebi-process

name	ebi-process
description	Recursive improvement process. Triggers: 'EBI', 'make it better', 'improve this', 'iterate on this'. Use proactively after completing significant work.
upgraded	"2026-07-02T00:00:00.000Z"
doctrine	v1.1
verified_commit	247ac7cbec7bb4ea9e5e79d0613a8295a2fd49cd

EBI - Even Better If

A structured, recursive improvement process that transforms good work into exceptional work through disciplined iteration.

Why This Exists

Most improvement processes are shallow - one round of "what could be better?" followed by implementation. The EBI process is different because it's recursive and compounding. Each round reveals possibilities that weren't visible before. The fifth round of EBI consistently produces insights the first round couldn't have imagined, because the work has evolved enough to reveal deeper opportunities.

The name comes from a simple reframe: instead of asking "what's wrong?" (which triggers defensiveness), ask "what would make this even better?" (which triggers creativity). This isn't just semantics - it fundamentally changes the quality of ideas generated.

The deeper truth: The best EBI sessions aren't just iterating. They're discovering. When you run 5-8 rounds on something meaningful, a moment arrives where an improvement reframes the entire work - where you realize the page itself is proof of concept, or the structure reveals a pattern you didn't consciously design, or removing something makes everything else stronger. That moment is the real payoff. Everything in this skill is designed to make that moment more likely.

The EBI Process

Phase 0: Set the North Star (Optional but Powerful)

Before diving into improvements, consider: Is there a gold-standard reference for what this work aspires to be? An Awwwards winner for a design. A Paul Graham essay for copy. A Stripe API for developer experience. A specific competitor's best work.

If a reference exists, name it: "North Star: [reference]. What makes it exceptional: [1-2 specific qualities]."

This anchors every round. Instead of improving in a vacuum, every improvement can be measured against: "Does this move us closer to [reference] quality?" This is optional - skip it when the work is genuinely novel or when a reference would constrain rather than inspire.

Phase 1: What's Working

Before improving anything, explicitly identify what's working well. This isn't politeness - it's strategic. Understanding what works prevents you from accidentally breaking it during improvement, and it reveals the principles behind success that can be applied elsewhere.

Genuinely engage with the work. Don't just audit it - recognize what's strong. This phase builds creative energy for what follows.

Ask yourself:

• What made me pause and think "that's actually really good"?
• What patterns or approaches are worth preserving because they're doing real work?
• What would the user miss most if it were removed?
• What surprised me about how well something works?

Present these as a brief "What's Working" section - 3-5 bullet points. Each should feel like a genuine observation, not a checkbox. "The emotional arc from skeptic to believer in sections 4-7 creates real tension" beats "Good structure."

Phase 2: Generate Improvement Ideas (Even Better If)

Every round must have a named theme - a specific lens that forces depth over breadth. Don't just scan for "what's better." Each round asks a fundamentally different question about the work.

Selecting a Round Theme:

Choose a theme appropriate to the current round number and context. Early rounds fix the obvious. Middle rounds restructure and deepen. Late rounds find the transformative. Use the Progressive Depth Ladder:

Round	Depth Level	Focus	Question	Technique
1	Surface	Fix what's broken or missing	"What would a sharp-eyed colleague flag in review?"	Checklist audit against domain standards
2	Structure	Strengthen the foundation	"Is this organized to maximize its purpose?"	Reorder, regroup, eliminate redundancy
3	Craft	Elevate quality and polish	"What separates good from great here?"	Side-by-side with North Star reference
4	Resonance	Emotional impact and delight	"How does this make someone feel?"	Walk through as the end user, moment by moment
5	Innovation	Adjacent ideas and techniques	"What would make this award-winning?"	Cross-pollinate from other domains (what would a filmmaker do? a game designer? an architect?)
6	Synthesis	Connect the dots across all previous rounds	"What pattern connects the best improvements so far?"	Review all previous rounds for a unifying principle
7	Provocation	Challenge the most sacred assumption	"What if the opposite of our core approach were true?"	Deliberately argue against the strongest element
8+	Transformation	Reframe the whole approach	"What would this look like if we started over with everything we now know?"	Imagine rebuilding from scratch with accumulated wisdom

Domain-Specific Lens Libraries:

Select lenses from the domain that fits the work. These replace the generic dimension checklist. Full lens lists (Design/Visual, Copy/Content, Code/Technical, Strategy/Planning, Plans/Specifications) live in references/lens-libraries.md; load that file when picking a round's lens.

For each round, announce the theme: "Round N - [Theme Name]: [One-line description of what this lens examines]"

Diverge Then Converge: Internally generate 15+ raw ideas, then ruthlessly cut to the best 7-12. The cutting is where quality lives. Don't present the user with everything - present the best. If you cut a bold idea that felt too risky, mention it as a "wild card" at the bottom.

Thinking Tools - use at least 2 of these per round to push past surface-level ideas:

• Inversion: "What would make this actively worse?" Then check if the opposite is missing.
• Audience Rotation: Step into the end user's shoes. What confuses them? What delights them? What do they skip entirely?
• First Principles Challenge (rounds 4+): "Is the approach itself right, or am I just polishing the wrong thing?"
• Evidence Over Opinion: High-impact improvements should cite a reason - data, precedent, user behavior, competitive benchmark - not just "this feels better."
• Constraint Flip: "What if I had half the space? No images? A 5-second attention span?" Constraints expose hidden assumptions.
• 10x Test (use at least once per EBI session): "What would this look like if it had to be 10x more effective at its core purpose?"
• Remove to Improve: "What can I delete that would make the remaining work stronger?" Sometimes the best improvement is subtraction.

Fresh Eyes (rounds 4+): Adopt a perspective the creator would never naturally take. Think as a competitor analyzing this, a journalist writing about it, a first-time user encountering it cold, or a skeptic looking for reasons to dismiss it. Name the perspective you're using.

Generate 7-12 specific improvement ideas, each with:

• A clear, actionable title
• One sentence explaining the improvement
• Impact rating: 🔴 High | 🟡 Medium | 🟢 Low
• Effort rating: ⚡ Quick | 🔨 Moderate | 🏗️ Significant

Sort by impact (highest first), then by effort (quickest first within same impact level).

Starting at Round 3+, include at least one improvement that answers: "What would make this not just good, but the kind of thing someone screenshots and shares?"

Phase 3: Propose and Confirm

Present the improvements to the user in a clear format:

## EBI Round [N] - [Theme Name]

### What's Working
- [Genuine observation about what's strong, with why]

### Even Better If
| # | Improvement | Impact | Effort |
|---|------------|--------|--------|
| 1 | **Bold visual hierarchy**: Replace flat section headers with gradient-accented billboard typography that creates natural scroll rhythm | 🔴 High | ⚡ Quick |
| 2 | ... | ... | ... |

**Recommended**: Implement items 1-N (highest impact, manageable effort).

Shall I proceed with these improvements?

Wait for the user to confirm, adjust, or select which improvements to implement. (Quick, Autonomous, and Orchestrated modes skip this wait, and so does ANY run inside a subagent: a subagent has no user, so it applies its mode's default and reports what it did instead of pausing.)

Phase 4: Implement

After confirmation, implement all approved improvements. Work through them methodically:

Implementation Order:

1. Quick wins first (⚡ effort) - build momentum, show immediate progress
2. Related improvements together - group changes that touch the same areas
3. Deep work last (🏗️ effort) - tackle with full attention after quick wins are done

For each improvement implemented:

• Verify it doesn't break what was working (Phase 1 items)
• Run the domain verification workflow for your context (see Adaptation by Context below)
• Apply the Stakeholder Test: "Would the person who cares most about this work notice and appreciate this change?" If no, reconsider whether it's actually high-impact.
• Note what was done with a brief before/after when the change is non-obvious

Cross-Round Threading: When implementing in rounds 2+, explicitly note how improvements build on previous rounds. "Round 1 fixed the structure; this round deepens the emotional impact within that structure." This creates a narrative of compounding improvement, not just a flat list of changes.

Phase 5: Recurse Until Done

After implementing improvements, automatically run the EBI process again on the improved work. This is the key differentiator - the recursion.

Momentum Beat: Between rounds, provide a one-line energy statement that celebrates what just happened and builds anticipation: "Round 2 gave this structural backbone. Now Round 3 is going to make it sing."

Selecting the Next Round's Theme: Consult the Progressive Depth Ladder. Move deeper, not wider. If Round 1 was Surface fixes, Round 2 should be Structure, not more Surface. Each round should feel like zooming into a different layer of the work.

Each subsequent round should:

• Acknowledge what the previous round improved (cross-round threading)
• Look for NEW opportunities revealed by the changes
• Go deeper using the next theme from the Depth Ladder
• Consider the work as a whole system, not just individual parts
• Actively seek the Breakthrough Moment: In every EBI session of 3+ rounds, there should be a point where an insight reframes the entire work - not just "add this" but "wait, what if the whole approach shifted?" When this happens, name it explicitly: "Breakthrough: [insight]". This is usually the most valuable moment in the entire EBI process.

Present each new round the same way (What's Working > Even Better If > Propose).

When to stop:

• The user says "this is good" or "let's move on"
• The improvements in the latest round are all 🟢 Low impact
• Fewer than 3 improvements survive the diverge-then-converge cut (see Phase 2's "Diverge Then Converge") at Medium-or-above impact. ("Be honest about this" is a secondary sanity note, not the operative rule: apply the count, don't just self-assess.)
• Five rounds have been completed (suggest stopping, but offer to continue)

Cumulative Impact Tracking: After each round, maintain a running total so the user sees the compounding value:

## EBI Summary - [N] Rounds Complete | [Total Improvements] Changes

### Round 1 - [Theme Name]: [One-line summary]
- [List of changes made]
- Impact: [count] 🔴 High, [count] 🟡 Medium, [count] 🟢 Low

### Round 2 - [Theme Name]: [One-line summary]
- [List of changes made]
- Impact: [count] 🔴 High, [count] 🟡 Medium, [count] 🟢 Low

### Cumulative: [total] improvements ([high] high-impact, [med] medium, [low] low)
### Transformation arc: [How the work evolved from Round 1 to Round N - what emerged that wasn't visible at the start]
### Key insight: [The single most important thing learned through the process]

Adaptation by Context

The EBI process doesn't just use different questions per domain - it uses different verification workflows. These are mandatory, not advisory.

Code/Technical:

• Focus: performance, readability, error handling, edge cases, test coverage, API design
• DONE MEANS: build passes, tests pass, no new lint errors, no regression on what Phase 1 flagged as working.
• VERIFY: run the project's existing test command (from package.json, Makefile, or CI config) and the build command; if neither exists, run the changed file through its interpreter or compiler directly.
• EVIDENCE: paste the exit code and the last 10 lines of test/build output. If tests fail, the round is not complete.
• Prototype Bold, Ship Safe: Try one aggressive refactor or optimization per session. If it breaks things, revert immediately.

Writing/Content:

• Focus: clarity, flow, voice, structure, audience fit, emotional impact
• DONE MEANS: word count is flat or intentionally changed (no accidental bloat), redundancy check passes, voice matches Phase 1's "What's Working" observations.
• VERIFY: run wc -w on the file before and after the round; if the project has a readability or style linter (e.g. Vale, a house style script), run it. If none exists, state "no automated readability check available" rather than skipping the line.
• EVIDENCE: paste the before/after word count and, if applicable, the linter's pass/fail output.
• Billboard Test: Can any phrase work at 80px type? If not, the copy may lack punch.

Design/Visual:

• Focus: hierarchy, contrast, spacing, consistency, emotional response, accessibility, responsiveness
• DONE MEANS: a screenshot exists at actual size for at least the primary breakpoint, responsive behavior is checked at mobile/tablet/desktop, and the squint test (step back - does the hierarchy hold?) passes.
• VERIFY: take a screenshot (or use the project's screenshot tool/preview harness) at each breakpoint the work targets; note the tool and dimensions used.
• EVIDENCE: attach or reference the screenshot file paths and the breakpoints covered.
• Prototype Bold, Ship Safe: Mock up one adventurous idea per round before committing. A rough sketch of the right direction beats a polished version of the wrong one.

Presentations:

• Focus: narrative arc, visual impact, information density, pacing, memorability, call-to-action clarity
• DONE MEANS: the deck reads coherently start to finish for a first-time viewer, and the call-to-action is unmissable.
• VERIFY: read or view the deck end to end in presentation order (not editing order); time the read and note where attention would drop.
• EVIDENCE: state the read time and name the slide/section where the call-to-action appears.

Strategy/Planning:

• Focus: assumptions, risks, alternatives, measurability, alignment, simplicity, communication clarity
• DONE MEANS: someone who wasn't in the room can read the plan and act on it without follow-up questions, and a pre-mortem has been run.
• VERIFY: run the pre-mortem explicitly: "It's 6 months later and this failed. Why?" and write down at least 2 concrete failure paths.
• EVIDENCE: paste the pre-mortem failure paths identified and whether each is now mitigated or accepted as a known risk.

Quality Gates - The "Never Ship Worse" Principle

Never ship a version you wouldn't honestly recommend over the last one.

This is the most important lesson from real-world EBI application: improvement attempts can make things worse. V4 can be worse than V2. Adding features can break fundamentals. Ambition without verification creates regressions.

After EVERY round of implementation, before presenting to the user:

1. Verify fundamentals still work. If it's code, does it compile and run? If it's a presentation, is all text readable? If it's a document, does it still make sense cover to cover?
2. Compare against the previous version. Would you honestly recommend this version over the last one? If there's ANY doubt, investigate before shipping.
3. Check for regressions in what Phase 1 identified as working. If "clean readable typography" was in the What's Working list and the new version has contrast issues, you've regressed.
4. If the new version is worse, say so and revert. "I implemented the improvements but the result is worse because [specific reason]. Reverting to the previous version and trying a different approach." This is the correct response - not shipping broken work.

The hierarchy of priorities during EBI:

1. Works correctly (no bugs, no broken features)
2. Readable/usable (fundamentals preserved)
3. Better than before (actual improvement, not just change)
4. Impressive (the wow factor)

Never sacrifice a higher priority for a lower one. A boring version that works beats an impressive version that's broken.

Anti-Patterns to Avoid

• Improvement theater: Adding complexity just to show you're improving. If it's good, say it's good.
• Regression through over-iteration: No version should ever be worse than what came before. If it is, go back.
• Scope creep disguised as improvement: EBI improves the existing work. It doesn't add new features unless they directly strengthen the original intent.
• Perfectionism paralysis: Five rounds is usually enough. Shipping good work beats endlessly polishing.
• Ignoring what works: Every improvement round must start with what's working. This prevents the common failure of "improving" something into mediocrity by losing what made it special.

EBI Modes

The goal is to make the work genuinely better - not to perform the ritual of improvement. Stay honest, stay specific, stay focused on what matters.

Standard Mode (default)

3-5 rounds, 7-12 improvements per round, themed by the Progressive Depth Ladder.

Deep Mode

When the user says "deep EBI" or "really push this":

• 5-8 rounds, 12-15 improvements per round
• Late rounds (6+) attempt transformative reframings, not just polish
• Still respect Quality Gates - ambition without execution is regression

Quick Mode

When the user says "quick EBI" or time is limited:

• One round only
• 3-5 improvements, highest impact only
• Implement immediately, no confirmation step needed
• Phase 5 (Recurse) does NOT execute in Quick Mode: the process ends after the Phase 4 quality-gate check. One round means exactly one.

Autonomous Mode

When the user says "EBI this autonomously" or "keep improving until it's great":

• Run the full process without pausing for confirmation between rounds
• Present a complete summary at the end showing all rounds and all changes
• Stop at 5 rounds or when improvements become marginal
• Still respect Quality Gates at every round

Ideation Mode

When EBI is applied to ideas, plans, or strategies (not finished work):

• Phase 1 (What's Working) becomes "What's strongest about this direction?"
• Improvements focus on strengthening the concept, not polishing execution
• Encourage bold pivots - ideas are cheap to change, finished work is not
• Use Thinking Tools aggressively: Inversion, Constraint Flip, and 10x Test are especially powerful on ideas
• The Breakthrough Moment is more likely in Ideation Mode - actively seek the reframe that makes the idea 10x better
• Quality Gates shift: instead of "does it work?" ask "is this the right thing to build?"

Orchestrated Mode (PM Mode integration)

When running under PM Mode (global CLAUDE.md) or inside /goal, EBI distributes across the model tiers instead of running in one context:

• The main loop (Fable) is the EBI DIRECTOR: it picks the mode and round budget by stakes, names each round's theme from the Progressive Depth Ladder, adjudicates findings, enforces the Quality Gates, and owns synthesis. Direction and judgment are the only Fable-priced steps.
• Stakes-to-mode table (source of truth for the mode/round-budget pick; matches CLAUDE.md rule 8 verbatim so this skill is self-sufficient without cross-document recall):

Stakes signal	Mode	Round cap
Every builder/architect self-runs a Quick-mode round on its own artifact before returning	MICRO	Not counted against any cap
Substantial work: find (critics, round theme as lens) + judge (main loop) + fix (builders) until a round has no High/Medium findings	STANDARD	5
Ship gates and production/money/customer surfaces	DEEP	8, walking the Depth Ladder, until only Low remains

• DEEP mode only: from round 4 onward, one of the two (or three) critic seats runs at model: opus instead of sonnet; keep the other seat(s) at sonnet. This is a floor, not a specific-model mandate: a stronger available model already satisfies the step.
• Idea generation is delegated: 2 critic agents (Sonnet; add a third data-fidelity seat when the work embeds or transforms data) each take the round's theme as their assigned lens, drawing from the Domain-Specific Lens Libraries (references/lens-libraries.md). Their BLOCKER/MAJOR/MINOR verdicts map to High/Medium/Low impact.
• Implementation is delegated to builder agents (Sonnet). The "never ship worse" verification runs on the worker or a scout.
• Workers additionally self-run Quick Mode on their own artifacts before returning (micro-EBI), so orchestrated rounds start from already-polished inputs.
• Rounds 2+ are delta-focused: re-examine the changed surface plus a regression check against the round-1 "What's Working" list, not the whole artifact from scratch.
• Convergence: stop on a clean round (no High or Medium findings), on the mode's round cap, or on thrash (a round re-raises vetoed or previously fixed items). Thrash escalates to director judgment, never to another blind round.
• Discretion gate: High and Medium findings auto-apply by default (CT's standing directive), but the director adjudicates every round's list first and may veto any finding with a one-line logged reason (violates intent, scope, brand, or the never-ship-worse gate). Vetoes appear in the round summary.
• Round caps are HARD under orchestration: Standard stops at 5 rounds, Deep at 8 (or earlier on a clean round). The base "suggest stopping, but offer to continue" condition does not apply; the director stops, full stop.
• Workers NEVER pause for confirmation: Phase 3's wait is replaced by the director's adjudication in orchestrated rounds and skipped entirely inside worker self-EBI (Quick Mode).
• Critics invoke this skill for REFERENCE ONLY (Depth Ladder and lens vocabulary). They do not execute its phases, implement nothing, and keep their own adversarial output format.
• Micro rounds (worker self-EBI) do not count toward the round caps; they are per-artifact polish. A full deep gate intentionally totals dozens of Sonnet-tier invocations across critics, builders, and self-rounds; the director announces the projected scale before starting one.

Specified Round Count

When the user says "run N EBI rounds" or "do 5 rounds of EBI":

• Honor the exact count requested - don't stop early, don't suggest stopping
• Space themes across the requested rounds using the Progressive Depth Ladder
• If more rounds are requested than the ladder has levels, cycle back through with deeper variations
• Present cumulative summary after the final round

Quick Reference

Phases: 0 (North Star) > 1 (What's Working) > 2 (Even Better If) > 3 (Propose) > 4 (Implement) > 5 (Recurse or Stop)

Depth Ladder: Surface > Structure > Craft > Resonance > Innovation > Synthesis > Provocation > Transformation

Thinking Tools: Inversion, Audience Rotation, First Principles, Evidence Over Opinion, Constraint Flip, 10x Test, Remove to Improve

Modes: Standard (3-5), Deep (5-8), Quick (1), Autonomous (up to 5), Ideation (ideas not artifacts), Orchestrated (distributed across PM Mode tiers), Specified (honor exact count)

Every round must have: A named theme, 7-12 improvements (diverge 15+ then converge), impact/effort ratings, at least 2 thinking tools

Every session should seek: The Breakthrough Moment - the insight that reframes everything