Producing a slide deck
This guide walks producers (sales, GTM, SE, partner managers) through producing a Verdigris slide deck against the cell’s spec. Read this when you have an engagement that needs a deck and you’re not sure where to start.
If you’re not sure which cell or genre fits, start with the /pick-cell-and-genre skill (source on GitHub; .claude/skills/ paths are not rendered into the docs site) or the index.md decision tree.
Step 1 — Pick the genre
The slides cell defines five genres, each calibrated to a specific engagement context. Pick one before opening a template.
| Genre | Audience | Engagement state |
|---|---|---|
pilot-kickoff |
Customer team executing a signed pilot | Contract signed; first artifact after signature |
customer-101 |
Prospect’s initial evaluator | First substantive meeting; pre-contract |
customer-201 |
Prospect’s technical evaluator | Post-101; pre-pilot diligence |
partner-enablement |
Partner AE / channel manager | Co-sell motion; partner needs Verdigris-fluency |
internal-team |
Verdigris-only | Weekly status, prep, post-mortems, board updates |
If the situation doesn’t fit any of these, do NOT improvise a sixth genre on the spot. Pick the closest, document the deviation, and propose a new genre via the adversarial-review workflow.
Step 2 — Pick the density mode
Every deck declares a presentation density mode. The mode determines word budgets per slide, headline/body ratio, visual dominance, captions, and whether speaker notes are required.
Three modes:
live-spoken— presenter carries narrative; deck supports. ~30 words/slide. Hero visuals at 60%+ slide area. Speaker notes required.dual-use— live presentation that will also be re-read async. ~80 words/slide. Balanced visuals. Speaker notes optional.leave-behind— no Verdigris presenter; deck IS the talk. ~150 words/slide. Sentence-level captions on figures. Speaker notes not used.
Per-genre defaults (from each genre’s frontmatter):
| Genre | Default density |
|---|---|
pilot-kickoff |
dual-use |
customer-101 |
live-spoken |
customer-201 |
leave-behind |
partner-enablement |
leave-behind |
internal-team |
dual-use |
Override when the delivery context warrants. Two equivalent paths depending on artifact format:
HTML decks (the canonical produced artifact for the slides cell): set data-density on the body tag.
<body class="vd-slide-deck"
data-genre="customer-201"
data-confidentiality="CUSTOMER-CONFIDENTIAL"
data-density="live-spoken"> <!-- override; this 201 is being delivered live -->
Markdown drafts (rendered to HTML by Jekyll): declare in YAML frontmatter; the layout emits the equivalent data-density attribute on body.
---
genre: customer_201
density: live-spoken # override; emitted as data-density on body
---
Both paths converge at data-density on the body tag, which is what the linter and compliance audit read. The full density spec lives in pilot-kickoff.md § Presentation density.
Step 3 — Anonymization checklist (only if the deck will ship publicly)
Default: real customer / partner decks stay private. They are CUSTOMER-CONFIDENTIAL, PARTNER-CONFIDENTIAL, or INTERNAL ONLY (per genre default) and ship via secure channel.
If the deck will be shared as an example in examples/ — to teach the cell to other producers — it must be fully anonymized. See examples/README.md for the 7-point checklist (customer name, site nicknames, equipment IDs, vendor names, dollar amounts, Verdigris team names, channel identifiers).
The discipline is engagement-shape preservation with full identity substitution: keep the technical content fully (case study metrics, integration patterns, voice recipes), substitute every identifying string with a placeholder.
Confidentiality-tier overrides require a structural rationale. If the deck declares data-confidentiality on <body> that does not match the genre default (e.g., customer-101 defaults to PUBLIC but the deck contains content that warrants CUSTOMER-CONFIDENTIAL), <body> MUST also carry a data-confidentiality-rationale="..." attribute with a non-empty justification. HTML comments don’t count — the audit reads attributes, not comments. Enforced by composition.persuade-slide-deck.confidentiality-rationale (Z2O-1463).
Step 4 — Fill the canonical structure (and gather visuals first)
A common failure mode is to author 20+ text-only slides, then realize the genre canon requires diagrams and screenshots that nobody has produced. Gather visuals first; let the prose wrap around them.
Required visuals by genre — composition.persuade-slide-deck.visuals-required (Z2O-1461) enforces a per-genre floor on non-logomark <svg> / <img> / <figure> elements:
| Genre | Visual floor | What the canonical structure expects |
|---|---|---|
customer-101 |
1 | Hero visual on the “what we do” slide |
customer-201 |
3 | Architecture diagram (position 3) + 2-3 real sample-output screenshots (operator dashboard, alert/anomaly view, API response) |
pilot-kickoff |
2 | Architecture diagram + pilot-timeline visual |
partner-enablement |
2 | Architecture diagram + objection-handling decision tree |
internal-team |
0 | No contract — whatever the meeting needs |
A deck shipping with zero qualifying visual elements (other than the logomark) is a structural failure caught at audit time.
Don’t ship placeholder-only slides either. composition.persuade-slide-deck.placeholder-density (Z2O-1462) fails any body slide where more than 50% of body content is <span class="vd-template">[FIELD: ...]</span>. Placeholders are fine for slot-fill (anchored metrics, decision dates, named contacts), not as the entire body of a slide.
Open the genre spec for the canonical slide structure:
pilot-kickoff.md— 12-20 slides, 18 canonical positions; the primary genre that other genres referencecustomer-101.md— 15-25 slides, 12-position structure tuned to first-meeting registercustomer-201.md— 20-35 slides, 14-position structure tuned to technical-eval registerpartner-enablement.md— 20-30 slides, 15-position structure for co-sell traininginternal-team.md— 8-15 slides, deltas-only against pilot-kickoff with internal voice mix
Each spec carries:
- The required slide structure (canonical order; required vs per-engagement)
- A decision framework for where to land in the bounds (floor / default / ceiling per axis)
- The voice recipe (which voice profiles carry which slides, in what proportions) — for
customer-201, seecustomer_201_deckin voice/recipes.yaml (lands as of Z2O-1460) - Diction adjustments specific to the genre
- Template-vs-produced contract (placeholders + how producers fill them)
Step 5 — Validate
Three checks before delivery. All run from the repo root.
Validate the rule structure:
npm run validate:rules
Catches token / rule schema issues independent of any specific deck.
Lint the deck for density violations:
npm run lint:slide-density categories/slides/examples/{your-file}.html
Catches per-mode word-count violations (live-spoken slides over ~36 words, dual-use over ~96, leave-behind over ~180). Filed under Z2O-1418. Exit 0 = clean.
Run the per-artifact compliance audit:
npm run audit:compliance -- categories/slides/examples/{your-file}.html
Catches violations of the 17 composition rules under composition.persuade-slide-deck in rules/visual-rules.yml: arc count + single-turn + max-low-energy, coupling type-floor + dark-bookends + chart-colors, logomark consistency, confidentiality marking, confidentiality rationale (Z2O-1463), role-not-name templating, absolute dates, table formatting, density-mode-required, density-word-cap, density-speaker-notes, visuals-required (Z2O-1461), placeholder-density (Z2O-1462). Resolve all critical findings before delivery. Should-fix findings are judgment calls.
For a private deck not in the repo, run the audit against a copy in /tmp/:
npm run audit:compliance -- /tmp/your-deck-draft.html
Step 6 — GTM review gate
Some genres need GTM review; others don’t. Default by genre:
| Genre | GTM review required |
|---|---|
pilot-kickoff |
Yes — this is the customer team’s first artifact after signature; quality is load-bearing on the engagement |
customer-101 |
Yes — this is the brand’s first impression on a new prospect |
customer-201 |
Yes — technical evaluators are reading slides three times; imprecision is costly |
partner-enablement |
Yes — partner AEs cite this for months; their customer conversations depend on it |
internal-team |
No (Verdigris-internal; no external-audience risk) |
The GTM reviewer is typically the engagement lead (sales) or the partnerships lead (partner-enablement). Async approval logged in the relevant Linear ticket or a Slack thread is the canonical record.
For example artifacts in examples/ that are fully anonymized: GTM review is not required because the content is fictional or scrubbed of customer identifiers.
Step 7 — Render to PDF
Slides are authored as HTML; the deliverable is usually a PDF the customer team can drop into a meeting, attach to an email, or print. Plain chrome --print-to-pdf produces blank pages on the slides stylesheet (paged-media context drops most slide content; verified against the canonical examples too). Use the build script (Z2O-1464):
npm run render:slides -- categories/slides/examples/{your-file}.html /tmp/{your-file}.pdf
Full-page viewport screenshot at 1280×(720·N) → slice at 720px boundaries → assemble into a paged PDF at 13.333in × 7.5in (matches the slides.css @page declaration). Each slide ships as one rasterized page; text is not selectable, but the layout is faithful. If cmd-F-able text is required, distribute the HTML directly.
Sanity-check before circulating:
qlmanage -t -s 1280 -o /tmp/ /tmp/{your-file}.pdf # macOS thumbnail of page 1
open /tmp/{your-file}.pdf # eyeball every slide
If the title slide thumbnail shows only the logomark, the render bug bit you — re-run; do not ship.
Step 8 — Ship
Once validated, rendered, and (where applicable) GTM-reviewed:
Filename: {type}-{audience}-{topic}-{YYYYMMDD}-v{N}.{ext} per the sales-collateral production guide. Versioning vs refresh rules live there too.
Confidentiality marking: every slide carries the marking in the footer band. Tier varies by genre (PUBLIC / CUSTOMER-CONFIDENTIAL / PARTNER-CONFIDENTIAL / INTERNAL ONLY); presence is mandatory.
Distribution channel by tier:
- PUBLIC (customer-101): can ship on the Verdigris website, in marketing emails, in conference handouts. No restriction.
- PARTNER-CONFIDENTIAL (partner-enablement): partner portal with explicit access OR encrypted email to the partner AE. Audit trail in the partner CRM.
- CUSTOMER-CONFIDENTIAL (pilot-kickoff, customer-201): Drive folder with explicit access (preferred — auditable, revocable) OR encrypted email to the customer team. Drive folder is canonical.
- INTERNAL ONLY (internal-team): Verdigris-internal Drive only. Never attached to a sales-CRM record.
Never:
- Post a CUSTOMER-CONFIDENTIAL or PARTNER-CONFIDENTIAL deck in a shared Slack channel (even internal #team-z2o)
- Attach a customer-201 deck to a CRM record where access is broader than the engineering audience
- Ship without the confidentiality tier marked on every slide
- Skip the validate / lint / compliance-audit pipeline for a customer-facing deck
See also
index.md— cell overview + decision treepilot-kickoff.md— primary genre spec; carries the canonical density sectioncustomer-101.md,customer-201.md,partner-enablement.md,internal-team.md— genre deltasexamples/— shipped reference examples + anonymization disciplineworkflows/sales-collateral— production guide spanning all collateral types (decision tree, naming, distribution, versioning)- /pick-cell-and-genre — genre selection skill (source on GitHub)
- voice/recipes.yaml — per-genre voice recipes