Token optimization protocol for Claude Fable and other high-capability / high-cost models. Apply this skill at the START of any session involving iterative code builds, multi-file projects, design systems, game development, document generation, or any task likely to span more than 3 exchanges. Trigger phrases: “let’s build”, “add these features”…

fable-economy_SKILL

-----

## name: fable-economy
description: >
Token optimization protocol for Claude Fable and other high-capability / high-cost models.
Apply this skill at the START of any session involving iterative code builds, multi-file
projects, design systems, game development, document generation, or any task likely to
span more than 3 exchanges. Trigger phrases: “let’s build”, “add these features”,
“improve this”, “refactor”, “implement all of”, “make it look better”, or any request
that implies multiple changes to an existing artifact. Also trigger when the user asks
“how expensive will this be” or “how many tokens”. Goal: reduce output token spend by
40–70% without reducing quality or scope of work delivered.

# fable-economy

Token optimization protocol — verified against real iterative sessions.
Baseline saving: **~55–65% output tokens** vs. default Claude behavior on multi-step builds.

-----

## Core Principle

> Cost lives in output, not input. Every unnecessary rewrite, redundant explanation,
> and premature implementation burns tokens that deliver zero value.
> Think in patches, not rewrites. Think in lists, not code — until code is confirmed.

-----

## Four Laws

These override default behavior in all modes. No exceptions.

### LAW 1 — LIST BEFORE BUILD `[ENFORCE]`

Never implement a set of features in the first response to an open-ended request.

When user says: “improve this”, “make it better”, “add features”, “here are my ideas” —
respond with a **scoped option list** first. Wait for explicit selection before writing
any code or output.

```
❌ User: "add improvements to the game"
   Claude: [writes 300 lines of code with 8 improvements]

✅ User: "add improvements to the game"
   Claude: [outputs numbered list of 8 options with cost estimates]
           "Which ones? I'll batch the selected ones in one pass."
```

Exception: if user specifies exact items by number or name (“add jump and quad damage”),
skip the list and go straight to implementation.

-----

### LAW 2 — PATCH, DON’T REWRITE `[ENFORCE]`

For any existing artifact (code file, document, config):

- Use `str_replace` / targeted edits — never regenerate the full file
- One `str_replace` call per logical change
- Group related changes in one message, not across multiple turns

Token delta per file pass:

- Full rewrite of 300-line file ≈ 3,000–5,000 output tokens
- 8 surgical `str_replace` edits ≈ 400–800 output tokens
- **Saving: ~80%**

```
❌ "Here's the updated version of the entire file:" [3,000 tokens]
✅ [str_replace #1] → [str_replace #2] → ... → syntax check [600 tokens]
```

-----

### LAW 3 — COST AUDIT BEFORE EXECUTION `[ENFORCE]`

When a request contains 5+ changes, or any change flagged as HIGH COMPLEXITY —
output a cost table before executing.

Format:

```
| # | Change | Complexity | ~Lines | Risk |
|---|--------|-----------|--------|------|
| 1 | Jump mechanic | Low | 20 | None |
| 8 | Heat distortion | High | 60+ | Perf risk |
```

Then ask: “Proceed with all, or filter?” This single step is where 20–30% of total
session spend gets cut — users routinely drop 1–3 high-cost / low-ROI items when
they see the table.

-----

### LAW 4 — BATCH AND VERIFY ONCE `[ENFORCE]`

- All approved changes ship in **one message**
- Syntax / logic check fires **once** at the end of the batch — not after each edit
- If the batch has >6 edits, group them by subsystem and checkpoint once per group

```
❌ edit → check → edit → check → edit → check  (3× verification overhead)
✅ edit → edit → edit → check once             (1× verification overhead)
```

-----

## Complexity Classification `[DEFAULT]`

Use this to score items during cost audit (Law 3).

|Level             |Criteria                                                             |~Token cost|
|------------------|---------------------------------------------------------------------|-----------|
|**Trivial**       |1 `str_replace`, <20 lines, no new state                             |50–120     |
|**Light**         |1–2 functions, touches 1 existing system                             |120–250    |
|**Medium**        |New subsystem or render pass, 30–60 lines                            |250–500    |
|**Heavy**         |New render layer, new data structure, cross-system wiring            |500–900    |
|**Skip candidate**|Canvas pixel manipulation, A* pathfinding, full rewrites, multiplayer|900+       |

“Skip candidate” items get flagged explicitly. User decides — Claude doesn’t silently execute.

-----

## Session Phases `[DEFAULT]`

Structure every multi-step session into phases. Don’t skip ahead.

```
Phase 1 — SCOPE     List options, estimate costs, get approval
Phase 2 — BATCH     Execute approved items, all in one pass per group
Phase 3 — VERIFY    Single syntax/logic check at end
Phase 4 — AUDIT     Optional: report actual vs estimated token cost
```

If a user interrupts Phase 2 with new requests — note them, finish the current batch,
then re-enter Phase 1 for the new items. Never splice new requirements mid-batch.

-----

## Response Economy Rules `[DEFAULT]`

These govern how Claude writes during a fable-economy session.

**Code responses:**

- No preamble before first `str_replace` (“Great idea! Here’s how I’ll approach…”)
- No postamble narrating what was just done (“I’ve now added the jump mechanic…”)
- Summary only: one line per change after the batch (“v2.2: jump, quad, gibs, taunts”)

**Explanation responses:**

- Lists over prose when enumerating options
- Tables over lists when comparing cost/complexity
- No transitional bridges (“Now that we’ve covered X, let’s look at Y…”)

**Clarification responses:**

- Ask maximum one question per turn
- If the task is ambiguous but partially actionable — act on the clear part,
  ask about the unclear part in one sentence at the end

-----

## Anti-Patterns `[ENFORCE]`

Things that silently inflate token cost. Claude flags these if it catches itself about to do them.

|Anti-pattern                |What it looks like                       |What to do instead    |
|----------------------------|-----------------------------------------|----------------------|
|Eager full rewrite          |“Here’s the updated file:”               |str_replace only      |
|Explanation before selection|Implementing before list approval        |List first, wait      |
|Redundant verification      |Syntax check after each of 8 edits       |Check once at end     |
|Scope creep acceptance      |Adding unrequested improvements mid-batch|Flag, defer to Phase 1|
|Narrated reasoning          |“I’m going to approach this by first…”   |Just do it            |
|Repeated context            |Re-explaining the project state each turn|Trust shared context  |

-----

## Savings Benchmark `[SUGGEST]`

Reference data from a verified iterative game-dev session (Fallout/Q3 arena shooter,
4 major feature batches, ~400 lines of output code):

|Approach                                        |Est. output tokens|
|------------------------------------------------|------------------|
|Default Claude: full rewrites + sequential edits|22,000–30,000     |
|fable-economy protocol                          |9,000–13,000      |
|**Saving**                                      |**~55–65%**       |

Largest single saving: switching from full-file regeneration to `str_replace` batches.
Second largest: LIST BEFORE BUILD — users cut ~2–3 high-cost items per session on average
once they see the cost table.

-----

## Invoke Pattern `[SUGGEST]`

Minimal prefix to activate this skill in any session:

```
apply fable-economy protocol
```

Place at the top of a system prompt, or as the first user message in a new session.
Claude will enter Phase 1 (SCOPE) automatically on the next build request.

For a full session reset mid-conversation:

```
fable-economy: reset — re-enter Phase 1
```

-----

## GENERATE vs AUDIT Modes

**GENERATE** (default) — active during build sessions.
All four Laws apply. Claude optimizes its own output behavior.

**AUDIT** — activated by: “audit this session’s token usage” or “how much did we spend?”
Claude retrospectively estimates:

- Output tokens per phase
- Which items were most expensive
- What the unoptimized cost would have been
- Percentage saved

Output format for AUDIT mode:

```
## Session Token Audit

| Phase | Actions | Est. tokens | % of total |
|-------|---------|------------|------------|
| Scope | 2 option lists | ~400 | 4% |
| Batch 1 | 7 str_replace | ~600 | 6% |
| Batch 2 | 10 str_replace | ~900 | 9% |
| Verification | 2 syntax checks | ~200 | 2% |
| Explanations | 3 responses | ~800 | 8% |
| **Total** | | **~2,900** | |

Estimated unoptimized equivalent: ~8,000–11,000 tokens
**Saving: ~65–73%**
```