---
name: "skill-deck-parity"
type: skill
description: >-
  Review a produced deck against convention-deck and its approved narrative
  outline, and write a plain-language verdict Aled can act on without opening the
  file. Use this whenever running the deck-parity pass, or when a deck ticket in
  In Review carries PR-1SM and names a rendered deck — render the slides to
  images and review the sequence, not just each slide: archetype variety and
  weight rhythm, hierarchy within each slide, on-brand fit against
  convention-aesthetic and the venture's convention-brand, and whether the action
  titles still read as the argument. Sibling to skill-qa and skill-design-parity;
  owned by Prism. Review only — never edits, advances, or ships the deck. Trigger
  it whenever the task is to QA a deck, check deck design quality, or check that
  a deck matches its outline. Surfaced by APP-559.
license: CC BY-NC-SA 4.0
---

# deck-parity

A design-quality review pass for decks — the pair of eyes that confirms a produced deck is actually good, made legible to Aled without him opening the file and clicking through forty slides. Sibling to `skill-qa` and `skill-design-parity`: same shape, same gate discipline, a deck lens.

The gap it fills is specific. The pptx skill's built-in QA catches **mechanical** defects only — overflow, overlap, contrast. Nothing reviewed a deck for design quality, so a deck with flat hierarchy, no rhythm, and no argument passed QA clean and shipped (APP-559). Mechanically correct and generic is exactly what a mechanics-only check certifies, and it certified it confidently. This pass reviews the things a slide-by-slide mechanical check structurally cannot see.

This is **review only**. It compares the deck against its intent and reports divergences. It never edits the deck and never changes ticket state.

## Trigger

Poll for issues in In Review carrying `PR-1SM` where the ticket names a **rendered deck** and its **approved narrative outline** (`skill-deck-narrative`). Also invoked ad hoc on any produced deck. Delivery projects only; never the Pipeline team.

**No approved outline, no comparison.** If the ticket names a deck but no approved outline, the deck was built without the two-stage gate — that is itself the finding. Note it on the ticket for Aled and stop; do not reverse-engineer an outline and review against your own invention, which would launder a process breach into a clean pass. (Same rule as `skill-design-parity`'s missing-design-reference stop.)

## Dedup — one verdict per deck build

Keyed on the deck's build identity, not elapsed time, so the review re-runs after a bounce where production re-renders. `skill-qa` and `skill-design-parity` key on the PR head commit SHA; a deck is a file rather than a diff, so the equivalent key is the **SHA-256 of the rendered deck file, first 8 characters**.

1. **Compute the hash** of the rendered deck file as delivered.
2. **Scan existing ticket comments** for one beginning `[deck] BUILD: <hash8>` with the same hash. That is the dedup key.
3. **If a match is found:** skip silently — no comment, no state change. The verdict exists; Aled's gate is the next action.
4. **If no match:** proceed with the full review.

Every verdict comment **must** begin with:

```
[deck] BUILD: <hash8>
```

## Behaviour

**Render the deck to slide images first, and review the images — never the source.** A deck is a visual artefact and its defects are visual: a font that silently substituted, a title that overflowed, a slide whose weight is wrong. None of that is legible in the file's structure, and reviewing the source is how a deck passes review looking nothing like what the audience will see.

**Then review the sequence, not just the slides.** This is the pass's central discipline and the reason it exists. Every defect the mechanical QA misses is a property of the *run* — rhythm, variety, escalation, whether the argument builds — and a checker that walks slides one at a time will pass all of them individually and miss all of them collectively. Lay the images out in order and read them as a deck.

**The checklist:**

* **Archetype variety** — every slide maps to one of `convention-deck`'s ten archetypes; no invented layouts; no two consecutive slides on the same archetype.
* **Weight rhythm** — opens and closes on Tier 1; a Tier 1 breather every 4–6 slides; **no equal-weight runs** (no three-plus consecutive slides at one tier); no more than two consecutive Tier 3. This is the named defect from APP-556 and the first thing to check.
* **Hierarchy within each slide** — the title, evidence, and caption tiers are distinct and read in that order. Everything on `convention-deck`'s five-step scale, nothing below body size, one family in two weights. A slide where everything is the same size has no hierarchy, whatever its content.
* **One idea per slide** — a title needing an "and" is two slides.
* **On-brand** — against `convention-aesthetic` (quiet over loud, editorial over commercial, and its anti-patterns) and the venture's `convention-brand` instance. Near-monochrome ground, exactly one accent, used for meaning.
* **Deck anti-patterns by name** — equal-weight runs, title-and-bullets, decorative accent bars, label titles, chart-as-dump.
* **Font fidelity** — did the brand face render, or did the renderer substitute silently? Check the images, not the source. An unrecorded substitution is a defect; a recorded, deliberate one is not (`convention-deck`).
* **Narrative** — do the action titles, read top to bottom and nothing else, still carry the whole argument? And do they match the approved outline, or did sections drift during production?

**On the narrative check: delegate, do not re-derive.** The *structure* question — which structure, does it fit the purpose, is it carried to the end — belongs to `skill-deck-narrative` Pass 3. Call it, and report its verdict as part of this one. This pass owns the design question and checks the titles against the approved outline; it does not form a second, independent opinion on structure. One structure judgement, one source.

Then:

1. **Post the verdict comment on the Linear ticket** (the canonical record). Begin with `[deck] BUILD: <hash8>`.
2. **Attach the rendered slide images** where the surface allows, so Aled can see what was reviewed without opening the file.

## Verdict

Two modes, mirroring `skill-design-parity`:

* **On-system** — a plain statement that the deck holds up, naming what was compared: the structure detected and its fit, the rhythm across the run, the hierarchy, the brand fit. Enough for Aled to approve without opening the file. Note anything out of scope or not covered by the outline.
* **Divergences to fix** — the specific gaps, each with: what diverges, **where** (the slide number), how it differs from `convention-deck` or the outline, and what would bring it on-system. Specific and actionable, so a bounce is self-contained.

Say what is wrong in terms of the deck, not the canon: "slides 4–9 all carry the same weight, so nothing in the section lands — make slide 6 a big-number and slide 9 a section break" beats "violates rhythm rule 5". Aled acts on it without opening the file.

**Hand off to Aled.** Once the verdict is posted, assign the ticket to **Aled**, leaving the label `agent:PR-1SM` and the state **In Review**. Do **not** advance, ship, or send the deck — that is Aled's action.

## Reads

The rendered deck, the approved outline from `skill-deck-narrative`, `convention-deck` (the archetypes, tiers, scale, rhythm rules, anti-patterns), `convention-aesthetic`, and the venture's `convention-brand` instance.

## Guardrails

- **Review only.** Never edits the deck, the outline, the template, or the design system. It reports; production fixes on a bounce.
- **Never ships or sends the deck**, never changes the ticket's **state** (stays In Review), never changes the `agent:*` label (stays `PR-1SM`). The one thing it sets is the **assignee to Aled**.
- **Review the images, in sequence.** Never review the source file, and never review slides in isolation — the defects this pass exists to catch are properties of the run.
- **No approved outline is a finding, not a licence.** Never invent an outline to review against.
- **Structure is delegated** to `skill-deck-narrative` Pass 3, never re-derived here.
- A parity pass makes deck quality legible; it does not sign off the deck. Sign-off is human (Pattern A).
- Scope to delivery projects only. Never touches the Pipeline team's work.
- **Taste signals are captured, not applied.** Where Aled's verdict on a deck reveals a taste signal, file a `FRICTION:` note naming `convention-aesthetic` or `convention-deck` per the taste-capture loop — never edit canon on the back of one verdict.

## Setup

- Claude Code Desktop, Schedule, New remote task — or run alongside `skill-qa` and `skill-design-parity` in the review lane.
- Connectors: Linear (read the ticket, write the verdict); access to the rendered deck and a means of rendering slides to images.
- Routine prompt: "Run the deck-parity skill."

Owned by **Prism** (`PR-1SM`) — the independent review and quality role. Add to Prism's composition in `agent-prism` and `agent-roster` when this lands (APP-559).

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.