# Beat Method

The shaping layer between extraction and voice. Owns: how extracted material gets locked as commitments for the voice layer to fill.

## Beat = type + job + slot

Every beat has three parts:

1. **Type** — the CATEGORY tag from extraction Pass 3 (CLAIM / REFRAME / MECHANISM / EVIDENCE / STORY / APHORISM / PIVOT / OBJECTION).
2. **Job** — the one-line purpose. What this beat must accomplish for the reader. The OUTCOME the reader registers.
3. **Slot** — what voice fills in. The actual prose, written in the operator's voice to fulfill the beat's job. No fixed length budget at this layer (no channel slot type) — the beat's natural density determines length.

## Beats are commitments, not content

Adopted verbatim from `/book-writer`. Every beat names the OUTCOME (what the reader registers / what shift lands). The voice layer brings the specific words.

**Failure mode**: editor packs the beat with specifics — "use this example," "cite this stat," "phrase it this way." Voice layer has nothing to invent; editor has quasi-written the prose by pre-selecting all the content. Voice goes flat.

**Correct shape**: each beat = one sentence naming the OUTCOME. Voice layer brings the words from training data + operator's anchor.

| Content brief (wrong) | Commitment (right) |
|---|---|
| "Open with: 'Most founders think X but the data shows Y.'" *(content pre-written)* | "Opening CLAIM beat — invert the conventional wisdom. Reader registers: I had this backwards." *(outcome)* |
| "Cite the 2019 sleep-deprivation cohort study on reaction time" | "EVIDENCE beat — land the empirical anchor. Reader registers: this isn't speculation." *(outcome)* |
| "Use the night-shift nurse example for circadian disruption" | "STORY beat — concretize the mechanism via a lived example. Reader registers: this is biology, not a lifestyle choice." *(outcome)* |

The right-column beat tells voice WHAT must land. Voice brings the words.

## Inject specifics into a beat (the exceptions)

- **Operator-unique content** — a coined term, a proprietary scene, a customer's exact words. List as MUST-APPEAR.
- **Load-bearing constraint** — callback to a specific prior beat, specific phrasing for argumentative reasons. Name it literally.
- **Operator has strong preference** — "use the night-shift nurse example specifically, not just any anecdote." Name it.

Otherwise: state the outcome, let voice bring the words.

## Density (no fixed budget, but density still matters)

`/beat-writer` doesn't have channel-specific slot types or constraint budgets — the channel isn't picked yet. But beats still have natural density:

| Density anchor | Words per beat | When it fits |
|---|---|---|
| Aphoristic | 30–80 | Standalone insight, claim, callout |
| Punchy | 80–200 | Quick reveal, mid-paragraph turn |
| Argumentative | 200–400 | One claim with reason + example |
| Developed | 400–600 | Mechanism walk, deep unpack |

Pick density per beat's job. Don't lock a uniform target — variation IS the rhythm.

## The handoff to /authors-voice

When a beat is locked (typed, job-committed), delegate prose to `/authors-voice` Apply Protocol with the OPERATOR'S DEFAULT ANCHOR (personal voice):

1. **Assemble the brief** — TASK = the beat's commitments (semantic, outcome-shaped — what must land, not how to phrase). Optional: cadence prescription for high-stakes prose. Preservation scope = pure generation (no source prose) unless rewriting existing material.
2. **Use the default anchor** — `/authors-voice` Apply Protocol loads `voice/anchor.md` automatically (operator's default). No anchor swap; this skill uses personal voice — that's the point of the channel-agnostic draft.
3. **Spawn the minion** via `/authors-voice` Apply Protocol — opus, general-purpose subagent, assembled skeleton.
4. **Receive prose**, patch any NEVER violations or brief-error meta-references (Apply Protocol step 6), integrate into the Draft doc by `docId`.
5. **Hand off to `/polish`** for the 90/100 push, then `/anti-ai`, then a naive-reader pass (the `/congruence` skill if installed, otherwise read the draft as a first-time reader and fix jargon / broken flow inline).

The editor (this skill) NEVER writes prose directly. Same Rule 1 as `/authors-voice`.

## Pipeline position

```
Extract → Beat Map (this doc) → Voice Pour via /authors-voice → Polish → Anti-AI → Congruence
                                                                                       ↓
                                                                              Optional: Refactor to channel-master
```

Full pipeline: `pipeline.md`. Refactor handoff: `refactor.md`.

# Extraction

Pull beats out of the operator before any prose is written. Same query-first, 5-pass discipline used by `/book-writer` — extraction is the foundation of every channel-master writer, including this channel-agnostic one.

## Query-first principle

The editor PULLS from the operator. The editor does NOT propose beats from its own intuition.

**Failure mode**: editor reads the source material → proposes 3 candidate angles → operator rejects all 3 because they came from outside the operator's head. Wasted turn, content the operator doesn't recognize as theirs.

**Correct move**: editor asks one focused question → operator talks → editor captures verbatim → structures from the operator's words.

Default to query. Proposing is OK only when (a) the operator explicitly asks for candidates, or (b) the proposal is mechanically derived from operator-owned source material ("your concept doc lists 5 mechanisms; I'm proposing each becomes a beat — does that fit?").

## DUMP prompts (open-ended, channel-agnostic)

Since the channel isn't fixed yet, the DUMP questions stay generic:

- "What's the counter-intuitive thing here?"
- "What's the part you keep coming back to in conversation?"
- "What's the reversal — the moment the reader expected X and gets Y?"
- "What's the part you'd put on a t-shirt?"
- "What's the scene from your own life that lands a piece of this?"
- "What's the part where you go 'wait, but...'"
- "What's the strongest claim you're willing to make?"
- "What's the example that makes this concrete?"
- "What did you almost not say?"

Wide net — 20–40 raw beat-candidates. No filtering. If the piece later becomes web copy or a tweet thread, channel-specific extraction will add channel-tuned questions; for now, get the raw material out.

## The 5-pass (channel-agnostic)

Same shape as `/book-writer`. The CATEGORY tags are a channel-agnostic superset.

### Pass 1: DUMP

Already done. 20–40 raw beat-candidates captured verbatim, no filtering.

### Pass 2: TENSION

For each raw beat, tag:
- **What question does this beat ANSWER?** (the tension it resolves)
- **What question does this beat OPEN?** (the tension it primes)

Beats with no open question are dead ends — fine at piece-close, otherwise cut/merge.
Beats with no answered question are non-sequiturs — find the prior beat they should follow, or cut.

A clean beat: answers ONE question, opens ONE question.

### Pass 3: CATEGORY

Tag each beat with one of (channel-agnostic superset):

- **CLAIM** — assertion, promise, position-take
- **REFRAME** — old information re-seen in a new light
- **MECHANISM** — how / why something works
- **EVIDENCE** — proof for a prior claim (data, citation, study, lived experience)
- **STORY / SCENE** — lived experience that grounds an abstraction
- **APHORISM** — compressed claim, single-sentence beat
- **PIVOT** — directional turn (now we look at X)
- **OBJECTION** — the friction handled, named and dissolved

Confirm the mix is right. All EVIDENCE reads academic; all APHORISM reads tweet-thready; all MECHANISM reads textbook. Variety matters — typically 30–40% CLAIM/REFRAME, 20–30% EVIDENCE/MECHANISM, 10–20% STORY/SCENE, 10–15% APHORISM, with PIVOT and OBJECTION as connective tissue.

### Pass 4: SEQUENCE

Order beats by reader flow. Each beat's OPENED question becomes the next beat's TENSION.

Watch for:
- Broken sequences (beat N opens a question beat N+1 doesn't answer)
- Premature reveals (payoff lands before setup primes the anticipation)
- Stacked openings without payoff (keeps promising, never delivers)
- Stacked payoffs without new tension (peaks then flatlines)

The right sequence is dopamine-optimal — each beat hands the reader to the next.

### Pass 5: COMPRESSION

State each beat as ONE sentence. No constraint budget at this layer (no channel slot type yet). The test: if you can't compress a beat to one sentence, it's mush OR it's two beats stuffed in one. Split or cut.

## Final artifact

After all 5 passes: a flat sequenced list of typed beats (5–30, depending on piece scope), each one sentence, each categorized. The Beat Map.

Stored in OpenWriter as `Beats — <Doc Name>` per `openwriter-surface.md`.

## When to skip extraction

- **Operator already has tight beats locked elsewhere** — load them, skip to write
- **Single-paragraph piece** — extraction is overhead the piece can't earn back
- **Pure paraphrase / rewrite of existing prose** — go straight to `/authors-voice` rewrite mode
- **Seed content provided as a draft** — treat the seed as DUMP material; run Pass 2–5 only

For everything else (new piece, major rework, scattered ideas): extract first. Drafting without extraction produces shapeless prose that's hard to refactor into any channel later.

# OpenWriter Surface

Where `/beat-writer` drafts live. Same container + two-doc pattern as `/blog-writer`, scoped to the "uncommitted draft" use case.

## Workspace layout

```
[Project] Drafts/                      (workspace, one per project; reuse existing if present)
└── <Doc Name>/                        (per-draft container)
    ├── Beats — <Doc Name>             (extraction output + locked beat map)
    └── <Doc Name>                     (Draft doc — the poured prose)
```

The workspace name `[Project] Drafts` is the default. If the project already has a generic writing workspace (`[Project] Writing`, `Drafts`, `Pad`, etc.), use that instead. Don't proliferate workspaces.

## Per-draft container

Each draft lives in its own container with two sibling docs.

**Container name:** matches the draft's working title (rename as the title sharpens)

**Two docs inside:**

| Doc | Title | Content type | Purpose |
|---|---|---|---|
| Beats | `Beats — <Doc Name>` | `notes` | Beat map (typed beats with jobs, in sequence) |
| Draft | `<Doc Name>` | `notes` | The poured prose |

Beats reshape → Draft re-pour. Two-doc separation makes targeted re-pours cheap AND matches the convention every channel-master expects — so refactor handoff is clean.

## Doc lifecycle (one draft, in call order)

| Step | When | Tool call | Notes |
|---|---|---|---|
| 1 | First draft for project | `create_workspace({ name: "[Project] Drafts" })` | Skip if existing writing workspace fits |
| 2 | New draft work begins | `create_container({ workspace_id, name: "<provisional title>" })` | Rename later as title sharpens |
| 3 | Start of extraction → beat map | `create_document({ container_id, title: "Beats — <Doc Name>", content_type: "notes" })` → `populate_document` | Beats doc — holds extraction + locked beat map |
| 4 | Start of voice pour | `create_document({ container_id, title: "<Doc Name>", content_type: "notes" })` → `populate_document({ content: "" })` | Draft doc, populated empty initially |
| 5 | Per beat, during pour | `/authors-voice` Apply Protocol minion (operator's default anchor) writes into Draft doc by `docId` (NOT by active view) — pending decorations | Opus, general-purpose subagent. Silent-build pattern same as `/blog-writer` |
| 6 | Polish phase | `/polish` reads from Draft doc, writes rewrites as pending decorations | |
| 7 | Operator review | Operator accepts pending decorations in OpenWriter Review tab | |
| 8 | (Optional) Refactor | Channel-master reads Beats + Draft, re-shapes into its own container | See `refactor.md` |

## Silent build

Never call `switch_document` or any view-control MCP as part of the workflow. The agent builds containers + docs + populates by `docId`. The operator watches the activity feed and file tree to follow progress; navigates to specific docs when they want to read output. View stays under operator control.

Only honor an explicit operator instruction ("open the Beats doc", "show me the Draft") with a `switch_document` call.

## Naming convention

- Workspace: `[<Project>] Drafts` (e.g., `[Orchestrator] Drafts`) — or reuse an existing writing workspace
- Container: matches the draft's working title (rename as it sharpens)
- Beats doc: `Beats — <Doc Name>`
- Draft doc: `<Doc Name>` (no prefix)

Same convention as `/blog-writer` — chosen on purpose so refactor handoff to a channel-master is trivial.

## Reshape loop

Edit Beats doc → identify affected beats → re-pour ONLY those beats in Draft doc → re-polish affected beats.

The doc separation makes this trivially cheap. Never re-pour the whole draft when one beat changed.

## What happens on refactor

When a draft gets refactored to a channel-master (see `refactor.md`):

- The original `[Project] Drafts/<Doc Name>/` container is LEFT IN PLACE (source of truth, not deleted)
- The channel-master creates a NEW container in its own workspace (`[Project] Blog/<New Container>/`, `[Project] Copy/<Page Name>/`, etc.)
- The channel-master reads the existing Beats + Draft as source material; re-shapes per its own discipline

The Drafts workspace is the "uncommitted layer." Channel workspaces are the "committed" layer.

# Pipeline

End-to-end workflow when `/beat-writer` is invoked. Phases run in order; each commits before the next.

## Phases

```
1. INTENT     — what's the operator writing about?
2. EXTRACT    — 5-pass from operator's head
3. SHAPE      — beat map (commitments locked, sequence locked)
4. WRITE      — /authors-voice Apply Protocol (operator's default anchor)
5. POLISH     — /polish to 90/100 per beat
6. ANTI-AI    — /anti-ai scrub
7. CONGRUENCE — naive-reader pass (/congruence if installed, otherwise inline)
8. (OPTIONAL) REFACTOR — hand off to channel-master if a channel becomes obvious
```

## Phase detail

### 1. INTENT

What's the operator writing about? Why now? Who's the (loose) audience?

Reading signals (in priority order):
- Topic clear from the prompt → start extraction
- Seed content provided (an idea, a draft, a paste) → use as DUMP seed (Pass 1 collapsed)
- Open-ended ("write me something") → ask ONE clarifying question

If genuinely ambiguous, ask one focused question. Don't menu-dump.

### 2. EXTRACT

5-pass per `extraction.md`. Output: 5–30 typed beats in sequence, stored in `Beats — <Doc Name>` in OpenWriter.

### 3. SHAPE

Lock the beat map per `beat-method.md`. Each beat = type + job + slot commitment.

No channel template at this stage — the beat list is the shape. Channel-masters re-shape later if refactor happens.

### 4. WRITE

Delegate per-beat to `/authors-voice` Apply Protocol with operator's default anchor. No anchor swap (this skill = personal voice).

For each beat:
- Assemble TASK brief (semantic commitments, optional cadence prescription, preservation scope)
- Spawn `/authors-voice` minion (opus, general-purpose subagent)
- Patch any NEVER violations on returned prose
- Integrate into Draft doc by `docId`

Editor never writes prose; every beat-to-prose pass is a minion dispatch.

### 5. POLISH

For each section / load-bearing beat, invoke `/polish`. Score 0–100; rewrite to 90+. Delegate, don't duplicate.

### 6. ANTI-AI

Run `/anti-ai` on the full draft. Strip em-dash density, contrastive formulas, AI fingerprints.

### 7. CONGRUENCE

Naive-reader pass: run `/congruence` if installed; otherwise re-read the draft as a first-time reader. Surface jargon, broken flow, undefined terms.

### 8. REFACTOR (optional)

When the draft's destination becomes clear, hand off to the appropriate channel-master per `refactor.md`:
- `/blog-writer` (long-form post)
- `/x-writer` (thread or article)
- `/newsletter-writer` (email section or full newsletter)
- `/copy-writer` (web copy — only if you have it installed; not bundled with OpenWriter)
- `/book-writer` (chapter / vignette in a book project)

OR stay as a personal doc / journal / note in OpenWriter.

## Internal dispatch logic

| Operator says | Phases that run |
|---|---|
| "write something about [topic]" | 1 → 2 → 3 → 4 → 5 → 6 → 7 |
| "I have this idea: [seed]" | 1 → 2 (seed = dump start) → 3 → 4 → 5 → 6 → 7 |
| "extract beats from [topic]" | 1 → 2 → 3 only |
| "pour these beats: [list]" | 4 → 5 → 6 → 7 (skip 1–3) |
| "polish this draft" | 5 → 6 → 7 only |
| "turn this into a blog post / thread / newsletter / page / chapter" | 8 (refactor handoff) |
| "/beat-writer" alone | 1 → ask one clarifying question |

## Reshape loops

Beat reshape → re-pour. If the operator wants to change the beat structure:
- Update the Beats doc (Phase 3)
- Re-run Phase 4 ONLY for affected beats
- Re-run Phase 5 on those beats
- Skip 6–7 unless the change was material

Don't re-pour the whole draft when one beat changed. Two-doc separation makes targeted re-pours cheap.

## Phase gates (block until satisfied)

- Phase 3 cannot start without Phase 2 output (no beats → no shape)
- Phase 4 cannot start without locked beats (no commitments → shapeless prose)
- Phase 5 cannot start without a draft (nothing to polish)
- Phase 8 (refactor) requires Phase 7 complete (don't refactor an unpolished draft — the channel-master gets garbage)

## When phases collapse

- **Single-beat write** (one paragraph from a clear commitment): skip 2–3 → run 4–5 only
- **Polish-only request**: run 5–7
- **Refactor-only**: skip everything except Phase 8

## What to do on the FIRST draft of a project

The first draft in a new project carries setup cost:

1. INTENT: clarify topic + scope
2. EXTRACT: full 5-pass
3. SHAPE: lock beat map
4. WRITE: full /authors-voice pour per beat
5. POLISH every beat
6. ANTI-AI + CONGRUENCE

The next draft in the same project skips workspace setup. Drafting takes 10–30 minutes depending on scope.

# Refactor

How to migrate a `/beat-writer` draft into a specific channel when the destination becomes clear.

## When to refactor

The draft has been poured and polished. The operator now sees where it goes:
- "This wants to be a blog post" → `/blog-writer`
- "This is a thread" → `/x-writer`
- "This is this week's newsletter" → `/newsletter-writer`
- "This is the new pricing page hero" → `/copy-writer` (if installed — not bundled with OpenWriter)
- "This belongs in Chapter 4 / is a vignette" → `/book-writer`

OR the draft stays as a personal doc — refactor is OPTIONAL. Plenty of drafts deserve to stay drafts.

## Refactor pattern (general)

The channel-master reads the existing Beats + Draft docs and re-shapes into its own container.

```
[Project] Drafts/<Doc Name>/             (original — left in place as source)
├── Beats — <Doc Name>
└── <Doc Name>

                ↓ refactor handoff

[Project] <Channel>/<New Container>/      (new — channel-master scaffolds)
├── Beats — <New Container>               (re-shaped for the channel's tag vocabulary)
├── <New Container>                       (re-poured / restructured for the channel)
└── (channel-specific extras: images, blogContext, etc.)
```

The original draft is NOT deleted. Refactor produces a new container in the channel-master's workspace; the original stays in `[Project] Drafts` as the source. If multiple refactors happen (operator forks the draft to blog + thread), each lands in its own channel workspace.

## Per-channel refactor protocols

### → /blog-writer

1. Operator says "make this a blog post."
2. Load Beats + Draft from `[Project] Drafts/<Doc Name>/`.
3. `/blog-writer` runs its `beats` mode against the extracted material — re-tags with blog CATEGORY (CLAIM / REFRAME / MECHANISM / EVIDENCE / DEMO / SCENE / OBJECTION / APHORISM / PIVOT), adds title + preview + slug as B0 commitments.
4. `/blog-writer` runs its `draft` mode — per-beat dispatch through `/authors-voice` with the per-site anchor (if blog has one) OR operator's default anchor.
5. Polish, image, integrate per `/blog-writer`'s pipeline.

Original `[Project] Drafts/<Doc Name>/` stays untouched.

### → /x-writer

1. Operator says "thread this" or "turn this into an X article."
2. `/x-writer` reads Beats + Draft.
3. Maps to thread / article format per `/x-writer`'s progressive disclosure (Fischerian hooks, anti-performance writing, paragraph-based medium form).
4. Per-tweet / per-section polish, image generation if requested, schedule.

### → /newsletter-writer

1. Operator says "this is this week's newsletter" / "send this to the list."
2. `/newsletter-writer` scaffolds the newsletter doc with the project's newsletter structure.
3. Drops the existing draft as a section (or full body) per the newsletter's beat conventions.
4. Runs gather → review → send pipeline.

### → /copy-writer (if installed)

Not bundled with OpenWriter — skip this section if you do not have a /copy-writer skill.

1. Operator says "this is the new [page-type] copy" / "make this our homepage hero."
2. `/copy-writer` reads the existing Site Brief + the Beats doc.
3. The draft prose can seed page-level extraction (Pass 1 DUMP), but the 5-pass re-runs with copy-specific tags (PROMISE / PROOF / OBJECTION / DIFFERENTIATION / URGENCY / ANCHOR / AUTHORITY / STORY / IDENTITY).
4. New beat map per the page-type template, NEW pour with the copy-writer anchor (10-masters blend).

**Important**: `/copy-writer` uses a different VOICE ANCHOR (the masters) than `/beat-writer` (operator's personal voice). Refactor to `/copy-writer` is NOT a simple lift — the prose gets re-poured. Beats and ideas carry; words don't.

### → /book-writer

1. Operator says "this goes in chapter N" or "this is a vignette for the book."
2. `/book-writer` reads Beats + Draft.
3. Slots the material into the appropriate Chapter container or Vignette library doc.
4. Re-runs beat methodology at chapter scope if material extends beyond a single beat.

## What carries vs what changes (refactor truth table)

| Element | Carries to refactor target | Changes per channel |
|---|---|---|
| Source ideas (DUMP material) | YES | — |
| Beat outcomes (commitments) | YES | Re-categorized per channel tags |
| Beat sequence | PARTIALLY | Re-sequenced per channel flow |
| Prose | YES (for `/blog-writer`, `/newsletter-writer`, `/book-writer`, `/x-writer` — same operator anchor) | NO for `/copy-writer` (re-poured in masters anchor) |
| Voice anchor | YES for personal-voice channels | NO for `/copy-writer` (uses masters anchor) |
| Length / density | LOOSE | Re-shaped per channel's natural form |

## When NOT to refactor

- **Draft is for personal use** — journal, note-to-self, working memo → leave in Drafts
- **Draft is exploratory thinking that didn't crystallize** → archive or delete
- **Draft fits multiple channels equally well** → pick one OR fork (run two refactors, kill the weaker output later)

Refactor is optional. The whole point of `/beat-writer` is to let the operator write before they commit to a channel.

## After refactor

The operator can:
- Keep both the original draft (in Drafts) AND the channel-shaped version (in the channel workspace) — useful for "show your work" or for forking later to a second channel
- Archive the original draft if the channel version supersedes it
- Delete the original if it was purely a scratch / exploration

Channel-master skills don't auto-delete the source draft. That's an operator decision.