--- name: "skill-deck-narrative" type: skill description: >- Selects a narrative structure for a deck by purpose, executes it as an action-title outline against the structure's definition in convention-deck-narrative, and evaluates an existing deck against whichever structure it appears to use. Three passes — Select, Execute, Evaluate. Use before drafting any deck outline for skill-visual-production or the pptx skill, and to review a built or supplied deck for structural fitness. Takes audience, occasion, and the one-sentence takeaway as required inputs; tags each outline line with an archetype and weight tier from convention-deck; gates on Aled approving the outline before any design starts. Owned by Pixel, read by Reach and Sonar with voice supplied per domain. Surfaced by APP-557 and APP-562. license: CC BY-NC-SA 4.0 --- # deck-narrative The argument before the artwork. Decks have been laid out slide by slide with no arc, because nothing in canon forced a story spine before layout — this skill is that force. It picks the structure the deck's purpose calls for, turns it into an action-title outline, and can read an existing deck back to tell you which structure it is following and where it breaks. The structures themselves live in `convention-deck-narrative`; this skill is the behaviour that selects, applies, and checks them. ## Trigger Three ways in: * **Before any deck outline is drafted** — for `skill-visual-production`, the pptx skill, or any deck at all. This is the standing case, and it is not optional: deck production takes an approved outline as input and refuses a cold "make a deck about X" (APP-558). * **On a supplied or already-built deck** whose structure is in question — a client's deck, a draft that is not landing, a deck someone else made. * **Called by `skill-deck-parity`**, which delegates the structure question here rather than re-deriving it. ## Behaviour Three passes. Pass 1 and 2 run together when authoring; Pass 3 runs alone when reviewing. ### Inputs — required before Pass 1 Three, and the skill does not start without them: * **Audience** — who is in the room, and their relationship to the subject. Not a job title; what they already believe and what they can decide. * **Occasion** — the setting and the time available. A 10-minute exec slot and a 40-minute keynote are different structures for the same content. * **The one-sentence takeaway** — what the audience should be able to say afterwards, in one sentence. If this cannot be written, there is no deck yet, and no amount of structure will supply one. Missing inputs are **asked for, never assumed**. A guessed audience produces a deck that is structurally sound and aimed at nobody, which is worse than an obviously unfinished one because it survives review. ### Pass 1 — Select (purpose to structure) 1. **Name the purpose** from the inputs. The takeaway usually names it: an ask is a pitch, a number is an update, a choice is a decision brief. 2. **Match the purpose to a structure** using the selection table in `convention-deck-narrative`. The table is held there, not here, so that adding a structure is a one-file change and the rationale sits beside the definition. 3. **Where the table offers two**, separate them on the entries' *Use when* fields — on the audience's relationship to the subject, never on preference. 4. **Where the deck serves two purposes**, say so rather than blending: it is two decks, or one deck with a stated primary purpose and the secondary demoted to appendix. A blended structure serves neither. 5. **State the choice and the reason** in one line at the top of the outline. Pass 3 and `skill-deck-parity` both read it; an unstated structure cannot be evaluated, only guessed at. ### Pass 2 — Execute (structure to action-title outline) 1. **Read the matched structure's full entry** in `convention-deck-narrative` — section order and job, slide split, opening and closing instruction, proof placement. 2. **Lay out the sections** in the entry's order at the entry's ratios, scaled to the deck's actual length. Never drop a section to fit; a dropped section is what every entry's *common failure* describes. 3. **Write every slide's title as an action title.** This is universal — it applies to all eleven structures, and it is the discipline the whole outline is judged on. An action title states the slide's claim ("Hiring is the risk to Q4"), never its topic ("Q4 Update"). The test is that **reading the titles top to bottom, and nothing else, must carry the whole argument.** If the titles read as a table of contents, the deck has a layout and no argument. 4. **Apply the opening and closing instructions literally.** They are where most structures are won or lost, and they are the most likely things to be quietly rationalised away — the agenda slide in particular grows back unless it is refused by name. 5. **Place the proof where the entry says.** Proof placement is a structural decision, not what is left over after the argument is laid out. 6. **Tag every outline line with an archetype and weight tier** from `convention-deck`. This is what sets rhythm at the narrative stage, where fixing it is free, rather than discovering at render time that ten slides all weigh the same (APP-556, APP-557). 7. **Check the tagged outline against `convention-deck`'s rhythm rules** before the gate — opens and closes on Tier 1, a breather every 4–6, no two consecutive slides on one archetype, no run of three at one tier. A rhythm failure at this stage is a re-tag; at render stage it is a rebuild. 8. **Source voice from the domain, not from here.** `convention-deck-narrative` sets the order; the domain's own convention sets the register — `convention-mrp-voice` for Mr P, the venture's brand voice elsewhere. Structure and voice compose without touching. This is the `agent-content-engine` pattern: one structure skill, voice supplied per domain. ### The gate — outline approved before any design **No design work starts until Aled approves the outline. Two-stage, always: narrative first, render second.** The outline goes to him with the structure named, the reason for it, the action titles, and the archetype tags. Approval of that outline is what `skill-visual-production` takes as its input. The gate is here rather than at render because an outline is cheap to argue with and a rendered deck is not — once slides exist, the conversation becomes about the slides, and a structural objection arrives too late to act on without discarding work. Rendering ahead of approval is the failure this skill exists to prevent, and it stays a failure however finished the thinking feels. ### Pass 3 — Evaluate (read-only) A structural review of an existing deck. Same shape and same discipline as `skill-qa` and `skill-design-parity`: read-only, plain language, never a rewrite. 1. **Detect the structure**, if any, from section order and the opening/closing pattern, using each entry's *detection signal* in `convention-deck-narrative`. Where the deck names its own structure, verify rather than accept it. 2. **Check the stated or inferred purpose against the structure actually used**, and flag any mismatch. Three-Act on a 12-slide business deck and ABT at deck level are the two named mismatches; both are reselections, not fixes. 3. **Check the structure is carried to the end**, using that entry's *evaluation signals* and its *common failure* by name. A structure abandoned at slide 8 is the normal way this breaks — the opening is deliberate and the close is whatever was left. 4. **Where an approved outline exists**, check the built deck against it: do the action titles still read as the argument, and did sections survive production intact? 5. **Write the verdict** in the format below. ## Verdict format Reuses the `skill-qa` / `skill-design-parity` verdict shape rather than inventing one — same two modes, same plain-language bar, same review-only boundary. What it does **not** inherit is their PR-head-SHA dedup key: those passes are bound to a pull request and this one is not. Where Pass 3 runs inside a Linear deck ticket, dedup on the rendered deck's build identity as `skill-deck-parity` defines it; where it runs ad hoc on a supplied deck, there is nothing to dedup against. * **Structurally sound** — a plain statement of the structure detected, that it fits the stated purpose, and that it is carried to the end. Name what was checked so the review is visibly real. Note anything the structure does not cover. * **Breaks to fix** — the specific gaps, each with: the structure detected, where it breaks (the slide or section), how it departs from the entry, and the **specific fix**. Not a rewrite — this skill reports; the author fixes. Every verdict states four things: **structure detected, fit to purpose, where it breaks, specific fix.** Plain language throughout — Aled acts on it without opening the deck. ## Reads `convention-deck-narrative` (the structure definitions, the selection table, the detection and evaluation signals), `convention-deck` (the archetypes and weight tiers for tagging, and the rhythm rules), `convention-audit` (for A1 consulting decks — the Finding → Theme → Opportunity → Initiative ladder, carried by the What / So What / Now What structure), and the domain's voice convention. ## Ownership and who reads it **Owned by Pixel** (`P1-XEL`), sitting upstream of `skill-visual-production` and feeding the pptx build (APP-562, which supersedes APP-557's open Reach-vs-Sonar question). The reason it is one skill rather than one per role: the *behaviour* — pick a structure, apply it, check it — is identical whether the deck is a Reach campaign pitch or a Sonar consulting brief. What differs is the structure selected and the voice it is written in, and both are already parameterised — the structure by purpose via `convention-deck-narrative`, the voice by domain. **Reach** (`R3-ACH`) and **Sonar** (`SO-N4R`) read this skill rather than owning variants of it; Sonar's consulting decks additionally carry the audit ladder through the What / So What / Now What entry. This is the `agent-content-engine` pattern, and splitting the skill by role would duplicate the loop to vary two inputs that are already inputs. ## Relationship to skill-deck-parity They share a boundary and must not both hold it. **This skill's Pass 3 owns the structure question** — which structure, does it fit the purpose, is it carried through — and runs on any deck, including ones we did not make. **`skill-deck-parity` owns the design question** — archetype variety, weight rhythm, hierarchy, brand — and runs as Prism's gate on a deck we produced. Where deck-parity needs the structure verdict, it **calls this pass and reports the result**; it never re-derives it. One structure judgement, one source. ## Guardrails - **Never render ahead of the gate.** No design work, no slides, no template fill until Aled approves the outline. Two-stage always. - **Never start without the three inputs.** Ask for audience, occasion, and the one-sentence takeaway; never assume them. - **Action titles are not optional.** Titles that read as topics are the defect, not a style preference. - **Never drop a section to fit a length.** Scale by ratio; a dropped section is the structure's named failure. - **Never invent a structure.** Select from `convention-deck-narrative`. A deck that fits none of the eleven is a signal to capture a new structure to the Pulse queue, not to improvise one mid-run. - **Pass 3 is read-only.** It detects, judges, and names the fix. It never rewrites the deck, and it never advances or ships anything. - **Structure here, voice there.** Never restate a domain's voice rules in an outline. - Propose-only to canon: friction with a structure's definition is a `FRICTION:` capture naming `convention-deck-narrative`, never an in-place edit. ## Setup Invoked ad hoc by Pixel, Reach, or Sonar before any deck outline; called by `skill-visual-production` as its required input; called by `skill-deck-parity` for the structure verdict. No schedule — this fires on a deck, not on a clock. Owned by **Pixel** (`P1-XEL`). On finish, run skill-ops-retro capture on this run's friction: **search the Pulse queue first and add the evidence to a same-root note if one exists, otherwise file a new FRICTION note** for the drain pass to assess, in capture step 3's literal shape — team Apps, project os.Claude, `FRICTION:` title, labels `task` + `work:configuration` + `PUL-5E`, Backlog, unassigned — filing the friction, never the run report.