Plan Copy

---
name: plan-copy
description: Run the strategy stage for one project — re-derive the project's own judged buyers, problems, and statistics from the original research records, build multiple high-level strategies the owner picks among, fan the options inside the picked strategy, then write the three plan files (Reader.md, Brief.md, Proof.md) the writer executes against. TRIGGER when a project needs its strategy set before writing, or when a level needs its commissioning workspace-root Brief.md written before researchers run. DO NOT TRIGGER to gather the evidence a plan cites (the research skills), to build offer options (draft-offers), or to write the copy (the write skills).
---

# Plan Copy

One Process: run the strategy stage by re-deriving the project's own judged files from the original research records, building MULTIPLE high-level strategies the owner picks among, spreading the options inside the picked strategy, then writing the three plan files a writer executes against — Reader.md, Brief.md, Proof.md. Build only from the product's business facts plus graded research records — never from a desk guess. High-level strategies come first as the divergent layer; option sets run only inside the pick; the files are written from the settled direction. Wireframing is a production output, not part of this stage.

The stage is DIVERGENT, never a one-to-one chain from one problem to one answer. It works with BUILDING BLOCKS — problems, buyer groups, offers, positionings, angles — judged FIRST as rated inventories and RECOMBINED SECOND into rated strategies. The project's own `Problems.md` rates each problem against each buyer group, so the stage opens on a measured landscape of problem-by-buyer pairings, not a single problem for a single buyer. High-level strategies — each a problem-by-buyer pairing recombined with an offer shape and a positioning — are built and rated against that whole landscape, and the options inside a picked strategy recombine against it too; nothing is derived one-to-one from a single block.

Nothing here is true or false. Every problem, buyer, offer, positioning, and strategy carries a 1-to-100 rating with its reasoning (see grading) and its existence rating from the reality attack (see check-reality). Every rating RIDES to the owner's pick; nothing is auto-removed for a low rating. The owner picks against the numbers and their reasoning.

## The project re-derives its own judged files

The workspace holds judged root files — `Buyers.md`, `Competitors.md`, `Problems.md`, `Statistics.md` — written by the judging step after research. A project does not copy them. It re-derives its OWN `Buyers.md`, `Competitors.md`, `Problems.md`, and `Statistics.md` from the ORIGINAL research records under `research/`, scoped to this project's job, so the project's judgments can differ from the workspace default.

### Re-derive from the original research records, never from the root judged files
The project's `Buyers.md`, `Competitors.md`, `Problems.md`, and `Statistics.md` are built from the research records under `research/<subject>/`, each rating carrying its arithmetic (grading) and its citations to those records. Never copy a rating from the root judged files — re-derivation is what lets a project judge the same evidence for its own scope. The root files are a reference for what evidence exists, not a source to duplicate.

### Rate every problem against every buyer in the project's Problems.md
The project's `Problems.md` carries one rated row per problem-by-buyer pairing: the problem statement in the buyer's words (from the research records), the buyer group it is rated against (a `Buyers.md` group), the research record that evidences it, the product records that address it, the pairing's grading (rating with arithmetic, plus the market measurements), the problem's existence rating from the reality attack, and its frequency and heat for that group. A problem rated against every group, never one problem for one buyer: this is the measured landscape the strategies and every option set recombine against. A problem with NO product record that addresses it is rated unaddressed, not dropped — an unaddressed problem is copy territory too, the wedge an offer may open.

## Commission research when a level needs it

When a level commissions research, the strategist writes the workspace-root commissioning `Brief.md` for the chief to dispatch researchers against; the research skills consume it. The commissioning brief lives at the workspace root, never inside `research/` — it is research's INPUT, and placing it inside research's output tree crosses the phase boundary. The brief carries the owner's PROBLEMS stated as plain facts and the starting DOMAINS those problems sit in (setup) — nothing else. It never names a persona, a target buyer, a product fact, a competitor, or the specific sources, communities, and review sites to mine. The buyer, the sources, and the competitor set are research OUTPUTS: the research phase discovers them inside each thread's `discovery/`.

### Carry the problems and their domains, nothing else
The brief carries the owner's problems in his words — a problem is just a problem, not owned, not sized, not validated — and the starting domains they sit in, citing setup's captured facts. Stating a problem does not bias the sweep: the discover pass enumerates what people actually voice, and the judged `Problems.md` rates the owner's problems as hypotheses among the rest. The brief never names a buyer or a specific venue — those the sweep finds.

### Keep Reader.md and Brief.md to one screen
Reader.md and Brief.md are one file, one thing, one screen. Overflow in either is a strategy failure, not a reason for a bigger file — a field that will not fit is a field not yet decided. Proof.md is exempt: it is a roster, as long as the piece's assertable facts and no longer. Each template below carries its own fill-rule header naming who fills it and from what; that header is written once here, never repeated by the consumers that open the file.

### Reject an overflowing Reader.md or Brief.md at write time
At write time (1e), if either Reader.md or Brief.md exceeds one screen, a field is undecided. Cut back to the settled picks; never ship the overflow to make the file look complete.

### Keep everything but the five fields out of Brief.md
Brief.md carries the five fields — Problem, Offer, Mechanism, Positioning, big idea — and nothing else. Every other kind of content has its own home: pick rationale lives in the strategy file marked with the pick; a guardrail folds into the field it bounds instead of standing as its own section; a note the strategy gate raised belongs in the gate record (`findings/StrategyGate.md`). Fold each into the field it sharpens and drop the provenance; a standalone rationale, an inline pick-id tag, a duplicated guardrail section, or a reference back to the gate is a field that failed the one-screen test.

## 1. Build and gate the high-level strategies

The strategist builds MULTIPLE high-level strategies, the owner picks one, and the options are fanned inside that pick. This replaces any sequential chain that fixes the offer, then builds positioning on it, then the Mechanism, then the big idea — that order collapses divergence, forcing every later option set into the orbit of the first pick and producing four polished variations of one argument. A strategy is one complete direction: a problem-by-buyer pairing named out of the project's rated `Problems.md`, an offer shape, and a positioning, built and graded as one whole. The set of strategies is the divergent layer — it spans genuinely different combinations, so the owner sees real alternatives, not one idea reworded.

### Attack existence before building, and let ratings ride
The reality attack runs on the project's re-derived `Problems.md` and `Buyers.md` (check-reality), product-blind, and returns an existence rating per item to the chief. Nothing is removed by that rating: a low-rated problem or buyer still carries into `Problems.md` and can seed a strategy, its existence rating riding alongside so the owner picks with it visible. The chief holds any fabrication finding and corrects the record or the rating. The 1d strategy gate re-checks construction, never first-runs the attack.

### Derive the buyer hypotheses before 1a
Before the first pick, the strategist derives the buyer hypotheses — WHO the buyers are and their awareness — from the project's `Buyers.md`, and takes a PROVISIONAL sophistication read (finalized at 1d, per step 3). Derive them by procedure, not by guess: one `Buyers.md` group becomes one hypothesis, read with its self-name, the situation its members share, and their words. The buyer-quote records those group entries cite are the evidence, never read raw for who the groups are. Which groups form one hypothesis is the strategist's JUDGMENT — labeled as judgment in the 1d packet and gated as judgment by check-strategy, never presented as a fact from the evidence. The number of hypotheses is the number of groups the inventory carries, never a target count picked in advance; a hypothesis with no group behind it is invented. Each hypothesis cites the `Buyers.md` group it rests on, which cites the buyer-quote record IDs behind it, so every field traces to captured buyer speech. The WHO is a research OUTPUT and stays uncertain: the hypotheses are plural, written into the project's `Buyers.md` as the strategy-side reading, and reviewed by the owner like any other guess about the market. They are Reader.md's raw material AND the routing input the strategies sort against: the strategies are designed to the buyers already derived, not the reverse.

### Grade every strategy and option
Every strategy and every recombination reaches the owner graded per the grading skill (see grading): its computed rating with the arithmetic shown, its existence rating, and its market measurements. Strategies and options are compared on those numbers and their reasoning, never on an agent's disposition or a bare true/false. A strategy's rating is the minimum of its parts' ratings (see grading), never an invented strategy number. A pick presented as "this is the right one" without its grading is not decidable and fails the gate.

- **a. Build the strategies** — recombine the graded building blocks into whole strategies: each names one `Problems.md` problem-by-buyer pairing, an offer shape (draft-offers supplies the offer shapes), and a positioning. Fan the strategies across genuinely different intervention types, not field combinations of one — strategies sharing an intervention type collapse the divergence even when problem, buyer, offer shape, or positioning differ, so name each strategy's intervention type. Grade each whole per the grading skill, refute them in a fresh adversarial context the way ideate refutes options, and iterate the survivors → 3–5 whole strategies reach the owner. Write them to the project's `strategies/` folder, and mark the owner's pick in that same folder — it is the strategy artifact check-strategy cites. An offer shape's limitations (deadline, seat cap, bonus window) are campaign work set in Campaign.md, never part of a strategy.
- **b. Owner picks one strategy** — the owner picks one whole direction. The pick fixes the problem-by-buyer pairing, the offer shape, and the positioning for everything downstream.
- **c. Fan the options inside the pick** — inside the picked strategy, each option point runs its own ideate set and its own owner pick: the Mechanism (see mechanism), the big idea (see big-idea), and any remaining offer detail. An option set varies only its one point; the strategy's problem, buyer, offer shape, and positioning stay fixed.
- **d. Assemble and gate** — the strategist assembles into one packet: the `strategies/` set carrying ALL strategies (each with its problem-by-buyer pairing, offer shape, positioning, intervention type, and grading) so the gate sees the whole set it must judge for breadth PLUS the picked strategy (its pairing named out of the rated landscape with its measurements, its offer shape, its positioning) — where a post-pick offer or positioning change was made, the newly picked strategy is the one that carries, never the original plus a patch — PLUS the option picks (Mechanism, big idea, any refined offer detail) PLUS the derived buyer hypothesis, the awareness read, and the now-FINALIZED sophistication read, each carrying its citations (the hypothesis its `Buyers.md` group, sophistication the competitor records counted against the settled promise class, awareness its stated arrival context or its OPEN marker), PLUS each pick's rating and market measurements, PLUS the three declared strategist judgments labeled as judgment — the buyer clustering, the promise-class grouping, and the objection order. The chief hands this packet to a fresh-context buyer-reviewer running check-strategy, which judges exactly what the packet carries. A blocking finding sends the selection back. Only after the gate passes does the strategist write any plan file.
- **e. Write the files** — the strategist writes Reader.md, Brief.md, and Proof.md from the settled picks, only after check-strategy's 1d findings stub (`findings/StrategyGate.md`) exists and carries no unresolved blocking findings on the current selection. Reader.md's Audience, Awareness, and Sophistication transcribe the gated values — the write step copies what the gate judged, it never re-derives them. No stub, no file: the stub is the gate's findings record, and files proceed only when it holds no blocking findings.

### Flag thin breadth to the chief, never auto-stop
A healthy set of strategies spans at least 2 distinct problems and at least 2 distinct buyer groups. Below either minimum the strategist does not stop on its own: it FLAGS the thin breadth to the chief — which problems and groups are thin and what evidence they lack — and the chief decides, proceeding thin knowingly (recorded as chief-assumed in Decisions.md and surfaced in the proposal) or resuming research by commissioning the next work. The flag lives in the strategist's return and the chief's dispatch, never in a persisted file; nothing downstream references it. A one-problem set is flagged the hardest — three intervention labels on one problem is convergence, never divergence — but the call to proceed or re-commission is the chief's, not an auto-stop. The 1d strategy gate still judges breadth as a review and may block; that blocking finding is the review's job, and the chief resolves it.

### Keep the resumed research divergent, never a confirmation campaign
When the chief resumes research from a gap report, the work it commissions is a divergent set of next research threads, not a campaign to rescue the problems and groups that were thin. This rule is that commissioning's single home:
- At least HALF the proposed next work is FRESH blank-slate discovery — new groups or new venues the round never touched — entered blind, seeking whatever it finds, not what the plan hopes.
- Rescue work, which revisits a thin problem or group, is LABELED as rescue and capped BELOW half, so fresh discovery always outweighs confirmation.
- A problem is paired only with a group whose speakers SELF-NAME that membership in the evidence — never a membership inferred to unblock the breadth check.
- No destination language: the plan never names a "nearest pairing", a target combination, or the direction it hopes the next round lands. It lists where to look, never what to find.

### Keep the strategy layer and the option layer separate
The set of strategies is the divergent layer — everything varies there: different problems, buyers, offer shapes, and positionings recombined into whole directions. An option set (ideate) varies ONLY its one point inside the already-picked strategy, holding the strategy's problem, buyer, offer shape, and positioning fixed. Never vary a strategy's blocks inside an option set, and never let the strategy layer collapse into variations of one direction — strategies of one intervention type are one direction.
Never: fixing the offer first, then building positioning, Mechanism, and the big idea on top of it as a sequential chain — the collapse this whole-strategy order exists to prevent.

### Replace the whole strategy on a post-pick offer or positioning change
The offer shape and positioning are fixed by the picked strategy. A post-pick change to either is not an option set and not a patch: it produces a NEW whole strategy (a fresh strategy-layer set and a new owner pick). Assembly then carries only the newly picked strategy, never the original plus an appended change.

### Route each owner pick where it governs
Each pick lands where it governs. A workspace-wide call is handed to the chief, who records it in Decisions.md via record-decision — the strategist never writes Decisions.md. A campaign call the strategist writes into Campaign.md; a piece call into that piece's Brief.md and the strategy file marked with the pick. Campaign-level strategy runs once per campaign; each piece still gets its own Reader.md.

### Author Campaign.md for a campaign
IF the project is a campaign, the strategist authors Campaign.md once the picks settle: the Goal; the Offer the campaign carries, with its limitations named here (the deadline, seat cap, or bonus window that limit access this campaign); and the Timeline — one line per piece naming the piece, when it runs, and where it sends the person. Order the Timeline page-before-ad when an ad quotes the page's promise, so the page the ad points to exists first.

### Dispatch a cold-read probe while shaping a pick
cold-read is a probe the strategist may run at any pick by DISPATCHING the buyer-reviewer to run it — the strategist cannot fire the probe itself. Hand the buyer-reviewer the exact material (one sentence or idea), the reader frame you build from the buyer hypothesis and buyer-quote evidence, and ONE question, in a fresh blank-slate context. The reaction returns in conversation — advisory, never a kill vote, never a section order. A reaction that changes a selection is recorded by the strategist in that strategy file. Reactions to WRITTEN drafts are buyer-review's job, never cold-read's.

## 2. Fill Reader.md — who the piece is for

Fill-rule header (Reader.md): INPUT, produced by the copy-strategist from graded buyer evidence before writing. Written per piece, always — awareness and sophistication are placement-specific.

- **Audience** — the one buyer this piece is for, in their own segment.
- **Awareness** — what the reader already knows, on the ladder in step 3.
- **Sophistication** — how many times the market has heard the promise, on the ladder in step 3.
- **Language bank** — the buyer's own words for the problem, the desire, and the objection, pulled verbatim from graded buyer evidence — the vocabulary the piece speaks in, never a generic paraphrase.
- **Objections in order** — the reasons the Reader hesitates, sequenced as they arise.

### Fill Reader.md with the reader's questions, never the product's
Every question and objection in Reader.md is one the reader actually carries, traced to problem research — never a question that conveniently sells the product. And the reader never arrives pre-wanting the product's angle: people are curious and want their problems solved, and the copy's job is to build the desire, not assume it walked in the door.

### Declare the strategist's judgments as judgment, gated at 1d
Three calls in the strategy stage are the strategist's JUDGMENT, not evidence-derived facts: the buyer clustering (which groups form one hypothesis), the promise-class grouping (which competitor claims count as the same promise, setting sophistication), and the objection ORDER (the sequence the reader's hesitations are answered in). Each rests on evidence — the quotes exist, the competitors exist, the objections exist — but how they are grouped or sequenced is the strategist's call. Label each as judgment in the 1d assembly packet and gate it as judgment at 1d; never present any as read from the evidence. The evidence gives the objections; the strategist gives their order — and the same holds for the clusters and the groupings.

Template:
    Reader.md — INPUT · copy-strategist · from graded buyer evidence
    Audience / Awareness (ladder step) / Sophistication (ladder level) / Language bank / Objections in order — as above.

### Read awareness from a stated arrival context, or mark it OPEN
Awareness needs a stated arrival context: an owner answer about where the reader comes from — asked at setup and again when the level commissions research — or a `Campaign.md` Timeline line naming what sends the reader here. With one in hand, read awareness from where the reader arrives and what they already run. With neither, awareness is OPEN — logged as an owner question in `OpenQuestions.md`, never filled by a default. A product with zero customers has no product-aware readers of itself — no one is aware of a product no one has used — so rate the reader product-aware only of the category and the incumbents they already hold.

### Draft a campaign's Timeline before 1d so awareness has its source
For a campaign, a piece reached from another piece in the campaign gets its arrival context from the Timeline line that names its sender. So draft the Timeline before the 1d gate — a draft is enough — so each piece's awareness read has its source when the gate judges it. A piece whose sender is not yet placed keeps its awareness OPEN; the draft never forces a default.

### Build the buyer as a buying situation
The buyer is a buying situation, not a bag of complaints: the incumbent stack they run now, the workaround that already failed them, the trigger event that put them in-market, and the switching threshold that would move them. Build each from graded evidence. Complaint fragments assembled into a persona describe a mood, not a buyer about to switch.

## 3. Match awareness and sophistication

The awareness ladder (what the reader knows) and the sophistication ladder (how tired the market is of the promise) are the master variable that sets the lead, the headline, and the proof. Both live in one home — copywriting's [awareness reference](../copywriting/references/awareness-and-sophistication.md). Name the reader's rung on each into Reader.md's Awareness and Sophistication fields from that reference.

### Diagnose sophistication by counting the promise class
Read the sophistication rung from evidence, not feel: count how many `Competitors.md` records make the same promise class the piece will make. The count is a strategy-stage judgment, not a captured claim: it is carried in the 1d assembly packet, and Reader.md's Sophistication field cites the competitor records counted directly — never written back into the research records as a new record. The count is the diagnosis — more competitors on the same claim is a higher sophistication level, per the ladder — so the rung rests on captured competitor evidence, never a guess at how tired the market is.

### Provision the sophistication read before 1a, finalize it at 1d
The promise class being counted is fixed by the picked strategy's offer shape and positioning (1b), so a sophistication read taken before the strategies are built is PROVISIONAL — a hypothesis on the promise the piece will make. It is FINALIZED in the 1d assembly packet, once the picked strategy's offer shape and positioning define the promise being classed, by re-counting the competitor records against that settled promise class. Which competitor claims fall in the same promise class is the strategist's JUDGMENT — the grouping — labeled as judgment in the 1d packet and gated as judgment by check-strategy, never presented as a fact from the evidence.

## 4. Fill Brief.md — the argument this piece makes

Fill-rule header (Brief.md): INPUT, marketing only, produced by the copy-strategist from the settled picks. Carries these five fields and nothing else.

- **Problem** — the problem this piece sells the solution to, stated in the Reader's terms.
- **Offer** — the offer that invites the Reader in: the one result and the terms that carry it. Only an offer the owner picked for publication may appear.
- **Mechanism** — how the Process is presented: the named, distinctive way the product works that makes the offer feel unlike every other claim. The Process itself lives in the product facts, never here.
- **Positioning** — the category (the shelf the buyer shops), the named alternative this wedges against, the difference the buyer can feel, and who it is for and NOT for. It must answer "why not keep my current stack" — name what the product replaces and what stays, so the reader sees the switch is bounded, not a rip-out. Owner law: "your promise isn't unique, your proof is" — the wedge is the proof, not a bigger claim.
- **Big idea** — the one fresh, charged idea the whole piece hangs on. Prefer one Big Domino belief over a list of small ones.

### Generate one claim per positioning, never an and-compound
A positioning carries ONE claim. The strategist obeys this while generating the positioning options — a two-claim, "and"-compound positioning is not generated in the first place. Mechanical detection of "and"-compounds and em dashes lives in `scripts/copycheck.py`, owned outside the strategy layer; the strategist's job is to not produce them, not to rely on the script to catch them.

### Cite the positioning's named alternative or leave it OPEN
The named alternative the positioning wedges against must cite a `Competitors.md` record — or a buyer-named alternative from the buyer-quote records, matched to a competitor. With no citation the field is OPEN, logged as an owner question in `OpenQuestions.md`, never invented to complete the field. An invented rival wedges the positioning against a competitor that may not exist.

Template:
    Brief.md — INPUT · copy-strategist · marketing only
    Problem / Offer / Mechanism / Positioning / Big idea — as above.

## 5. Curate Proof.md — every fact the piece may assert

Fill-rule header (Proof.md): INPUT, curated by the copy-strategist; researchers add typed entries by template.

Every fact this piece may assert is typed and points into the research records under `research/`. Nothing outside Proof.md is quotable by a writer — a writer wanting more escalates to the chief, never mines `research/` directly.

- **Type each entry** one of: `owner` / `product` / `buyer-quote` / `industry` / `competitor`. Owner facts are first-class evidence.
- **Cite each entry by its research-record ID** — the stable leading ID the records assign (P28, V46), never a line number. A line number drifts as the records grow; the ID does not. The prefix names the record set that holds it: P → product records, V → buyer-quote records, C → competitor records, O → owner records, S → statistics records. No fact without a citation into captured, graded research.

### Hold each fact's wording to its evidence state
A fact enters Proof.md worded no stronger than its evidence backs — the writer cannot say more than the fact states. This is the same bar check-claims enforces on the draft (see check-claims); curating Proof.md to it keeps the writer from a claim the gate will only reject later.

IF no customer results exist for the product:
### Commission proof-of-operation instead of inventing outcomes
When the product has no customer results, the proof gap is filled by commissioning proof-of-operation artifacts as research work, not by a fabricated customer outcome — what those artifacts are is research-product's proof-of-operation step. Internal code facts substantiate the writer that the product does what it claims; they are not buyer-facing proof on their own. The commission is a product-scoped assignment the chief dispatches to research-product directly — never folded into the commissioning `Brief.md`, which carries the owner's problems and their domains for the market track and would pull product facts into a phase that runs blind to them.

### Sign no plan on thin research
Every field across the three files rests on evidence, not a guess. Proof.md cites product facts (from research-product or the fact files) for what the product is and does, AND market and buyer evidence for the audience and for each objection. A field resting on a desk guess sends the plan back to research before it is signed.

Template:
    Proof.md — INPUT · copy-strategist curates · researchers add typed entries
    - <fact> — type: owner|product|buyer-quote|industry|competitor — record: <record-id>

## 6. Gate new positions and offers to the owner

A NEW position or offer is the owner's, not publishable by the plan alone — it is picked as part of a whole strategy at stage 1b (and refined inside the pick at 1c), never invented in the files. A product fact (how the product works) is not an approved public offer; only offers the owner picked for publication may appear in copy as offers.

### Mark a beat dependent on a missing owner fact, never answered
A beat whose honest answer needs an owner fact the owner has not given is marked DEPENDENT on its named OpenQuestions.md entry in the plan file that carries it, and drafted as the open dependency it is. It is never written as settled to make the plan read complete.

Verification: the project re-derived its own Buyers.md, Problems.md, and Statistics.md from the original research records, each rating carrying its arithmetic and record citations, never copied from the root judged files; Problems.md rated each problem against each buyer group, traced each to addressing product records, recorded unaddressed problems, and carried each item's existence rating from the reality attack; the reality attack ran product-blind and its ratings rode alongside without removing anything; the buyer hypotheses derived from the Buyers.md groups, one per group, each citing its group entry; whole strategies were built and graded as the divergent layer, filed to strategies/, and the owner picked one, the options (Mechanism, big idea, remaining offer detail) were fanned through ideate inside the picked strategy with offer shape and positioning held fixed (a post-pick offer or positioning change filed as a new whole strategy and a new pick, assembly carrying only the newly picked strategy), and each pick was routed to where it governs; the 1d assembly packet carried the strategies/ set with ALL strategies (each with its problem/buyer/offer shape/positioning, intervention type, and grading) and named the picked strategy's pairing out of the rated landscape, carried the buyer hypothesis, the awareness read, and the finalized sophistication read with their citations, PLUS the option picks PLUS each pick's rating and market measurements PLUS the three declared judgments labeled as judgment, and check-strategy challenged the packet before any file was written; the commissioning brief carried only the owner's problems and their starting domains, citing setup's captured facts, and named no buyer or specific venue; Reader.md transcribes the gated audience, awareness (its stated arrival context or an OPEN owner question) and sophistication (citing the competitor records counted), the language bank, and the objections whose ORDER is declared strategist judgment; Brief.md carries the Problem, Offer, Mechanism, Positioning, and big idea and nothing else; Proof.md types every fact and points each at a research record; each file fits one screen and carries its producer in its header; and no field rests on a guess.