CtrlK
BlogDocsLog inGet started
Tessl Logo

jbaruch/speaker-toolkit

Seven-skill presentation system: ingest talks into a rhetoric vault, run interactive clarification, generate a speaker profile, create presentations that match your documented patterns, produce the deck illustrations + thumbnail visual layer, create and publish talk-content Agent Skills with talk pages to a Jekyll shownotes site, and verify a recorded screencast against its storyboard. Includes a 113-entry Presentation Patterns taxonomy (83 observable: 64 patterns + 19 antipatterns; 30 unobservable: 21 patterns + 9 antipatterns) for scoring, brainstorming, and go-live preparation.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

phase2-architecture.mdskills/presentation-creator/references/

Phase 2: Rhetorical Architecture — Detail

Plan Analog Before Going Digital

Architecture decisions in this phase happen at the conceptual level — mode, opening pattern, narrative arc, sectioning, pattern strategy. These are best worked out away from slideware. Reynolds is emphatic: opening a presentation tool during planning prematurely commits the author to a template, a layout, and a default font when those decisions should still be fluid.

When the author is making architecture decisions in this phase, encourage analog tools — paper sketches, whiteboard diagrams, Post-it notes — for working through the structure before any slide is created. The five-step Reynolds workflow keeps slideware out of the picture for the first four steps: brainstorm → group/identify the core → analog storyboard → sketch visuals → only then transfer into slideware. Architecture decisions in this phase belong to steps 1–3; slideware belongs to Phase 5. See patterns/prepare/concurrent-creation.md for the full workflow.

The Joint Selection Process

This phase is a conversation, not a monologue. Use AskUserQuestion for each instrument selection. One decision per turn. Never combine multiple decisions into a single message — see the interaction-rules steering rule.

For each decision:

  1. Extract the options from the vault summary (sections 2-13) and speaker profile (instrument_catalog). The vault is the living source — new instruments appear as more talks are parsed.
  2. Present the options via AskUserQuestion with brief descriptions
  3. Recommend based on the spec — put the recommended option first with "(Recommended)"
  4. Wait for the author's choice before moving to the next decision

Mode Selection Logic

Read presentation_modes[] from the speaker profile. Each mode has a when_to_use field — use these to build a selection logic table dynamically. Present the modes with their descriptions and match signals from the spec.

Decision #2: Engine & Theme Sourcing

Pick the deck's tooling (pptx template vs presenterm terminal-markdown) and theme right after Mode — engine depends on the mode's typical_engine and constrains Slide Design, Template Patterns, and Illustration Strategy (presenterm has no pptx layouts; the illustration pipeline assumes pptx). Deciding it late forces re-litigation.

Source the choice via the shared wizard: idea-sourcing-wizard.md. Engine-specific bindings:

  • Reads: profile → presentation_engines[] (roster + usage_count/out_of), the chosen mode's typical_engine, recent talks' outline.yaml engine, WebSearch (trends), author-supplied references.
  • Presents: the multi-select source menu, proposals spanning the checked sources, then a single-select picking the final engine (+ theme pointer).
  • Quick-default: resolve engine by precedence — chosen mode's typical_engine → highest-usage presentation_engines entry → pptx; set engine_source: "quick-default"; proceed immediately with a one-line note.
  • Writes: talk.engine (closed enum pptx|presenterm), talk.deck_theme (free-string pointer), talk.engine_source (provenance).
  • Summary-only / no-profile: present a flat two-option pptx/presenterm menu with hard-coded when-to-use; no usage tiers, no "your usual"/"series" sources; quick-default → pptx.

Theme stays a thin provenance pointer — the deck's look is owned by design_rules and, for illustrated decks, the illustration STYLE ANCHOR. Do not build a named deck-theme registry here.

Opening Pattern Selection Logic

Read instrument_catalog.opening_patterns[] from the speaker profile. Each pattern has a best_for field. Match to the spec's audience warmth, venue size, and context.

Narrative Arc Templates

Read instrument_catalog.narrative_structures[] from the speaker profile. Each has acts and time_allocation. Present the options with their time splits and best-for context.

Persuasive vs. Informative Architecture — Sparkline or Narrative Arc?

Before presenting narrative-arc templates, ask one upstream question: is this talk primarily persuasive or primarily informative?

  • Persuasive = the audience is being asked to do or believe something different after the talk (sales pitches, strategic-direction announcements, fundraising, organizational change, advocacy keynotes, investor pitches).
  • Informative = the audience needs to understand something but is not being asked to act on it differently (tutorials, technical deep-dives, scientific explanations, status updates, postmortems).

For persuasive talks, present sparkline (per patterns/build/sparkline.md) as the default top-level structural option. The sparkline's two named turning points (Call to Adventure, Call to Action) and "new bliss" close are purpose-built for moving audiences to action. Stack with one of the contrast-driven sub-structures inside the middle (problem-solution, compare-contrast, cause-effect, advantage-disadvantage).

For informative talks, present the existing narrative-arc templates (three-act and variants) as the default. The three-act structure suits content that needs to be understood; the sparkline is overkill and can feel manipulative when there's no genuine action to take.

The two patterns can coexist: an informative talk can have a small sparkline-shaped closing argument, and a persuasive talk can have informative sections inside its middle. But the choice of top-level structure matters because it shapes time allocation across the three sections — sparkline allocates ≤10% to "what is" baseline and most of the time to the persuasive middle; narrative-arc typically allocates ~25-50% to the middle, with longer setup and resolution.

When the mastery_and_novelty domain is available and classifies narrative-arc or sparkline as regular/signature, surface that authorized preference but do not let it override the persuasive-vs-informative diagnostic. Never infer the preference from raw tags or occurrence rows. A speaker accustomed to narrative-arc tutorials switching to a sales pitch should switch to sparkline for that talk; the architecture should match the talk's purpose, not the speaker's habit.

Action Typology — Pre-Plan the Call to Action

When sparkline is selected (or whenever the talk includes a call-to-action moment), pre-plan the audience's action diversity at the architecture level. Per patterns/build/call-to-action.md, every audience contains four action-temperament types — Doer (instigates activities), Supplier (provides resources), Influencer (changes perceptions), Innovator (generates ideas) — and the call-to-action must address at least one ask per type.

This is an architecture-phase concern (not a content-phase one) because the asks shape the entire backward-design of the talk: if you can't name a credible Doer ask, the talk lacks an actionable thesis; if you can't name an Influencer ask, you haven't accounted for audience members who can't directly execute but can spread the idea. Write the four asks before writing any other content; the rest of the talk is in service of making them feel earned.

Decision #11: Pattern Strategy

Read patterns/_index.md for the current taxonomy. Use only the catalog-history source selected by Phase 0's emitted history_source. When its status has history_enabled: true, authorize each derived lane independently through available_classification_domains / domain_available(domain). Never infer a domain from profile recency, schema tolerance, Section 15 prose, classification_fields_available: true, or opportunity_rows_available: true. Profile schema v4 and Section 15 v2 are occurrence-only; profile schema v5 and Section 15 v3 are policy-bound.

When mastery_and_novelty is available, present patterns in 4 tiers:

PATTERN STRATEGY for "{talk title}"
===================================
YOUR TOOLKIT (signature):
  ✓ Narrative Arc (22/24 talks) — recommended for this format
  ✓ Bookends (18/24) — strong with this audience
  ✓ Expansion Joints (20/24) — essential for 45→20 min adaptation

WORTH CONSIDERING (contextual):
  ○ Talklet (3/24) — good fit for the 20-min constraint
  ○ Foreshadowing (7/24) — pairs well with your arc style

NEW TO YOU:
  ★ [NEW] Preroll — display bio/topic on screen before you start
  ★ [NEW] Seeding the First Question — plant an easy Q for Q&A

SHAKE IT UP:
  ⚡ [WILD CARD] Red, Yellow, Green — audience voting with colored cards
  ⚡ [WILD CARD] Cave Painting — one giant canvas instead of slides

WARNINGS:
  ⚠ [CONTEXTUAL] Dual-Headed Monster — co-presented talk, define handoff points
===================================

Tier logic:

  1. Signature — current-cohort mastery_levels.signature entries, always shown.
  2. Contextual history — current-cohort mastery_levels.regular or mastery_levels.occasional entries matching the talk context.
  3. New to You — current-cohort never_used_patterns / mastery_levels.never_tried, filtered by relevance and marked [NEW]. This set is exact: never use first detection in the newest talk or not_yet_observed as evidence of novelty.
  4. Shake It Up — exactly 1–2 current-cohort never-tried options used as provocations, not prescriptions.

Current-cohort strengths requires mastery_and_novelty; underused_patterns requires underuse; signature_combinations requires signature_combinations; and by_mode requires modes. Pattern or antipattern movements, score/breadth trend, and score drivers require trends. Never infer one domain from another.

Antipattern warnings. Derive contextual warnings from the spec (co-presented → Dual-Headed Monster, dense content → Bullet-Riddled Corpse, new format → Shortchanged, etc.). Catalog recurrence filtering and [RECURRING] labels belong to Phase 4's emitted recurring_antipatterns output. Do not recreate them during architecture. Current-outline detections always receive [CONTEXTUAL] and remain available without history. Explicit source_lane: "non_pattern" guardrails remain independent of this catalog lane.

Mastery-domain-disabled / summary-only mode: Pattern taxonomy still works — patterns come from the reference files alone. Present a flat relevant-patterns list without the four history tiers, usage statistics, novelty claims, or strengths. Do not call taxonomy entries "new to you" merely because mastery history is unavailable. Other policy-bound domains may still authorize their own narrow claims; contextual antipattern warnings always apply. Section 15 v3 can restore only the domains listed by its complete explicit provenance contract. Section 15 v2 is occurrence-only narrative/audit context, not tier authorization.

Across profiles, a catalog/scoring generation change resets occurrence and classification comparison. Within one generation, a changed policy_semantic_sha256 resets classification comparison. Neither boundary is speaker improvement or regression.

Enhance decisions 3-10 with pattern cross-references as shared vocabulary: when recommending an opening pattern, reference the taxonomy ID; when selecting a narrative structure, note which Presentation Patterns it maps to (e.g., "problem-solution" = Narrative Arc + Triad).

Decision #12: Illustration Strategy (when applicable)

Not every talk needs generated illustrations — demo-heavy, data-heavy, or screenshot-driven talks may not. When the author wants AI-generated illustrations, delegate to the illustrations skill for the full collaboration (optimization priorities, format vocabulary, a priority-driven model shortlist, style proposals grounded in vault visual_style_history, a style × model exploration render, visual continuity devices):

Skill(skill: "illustrations")

The skill writes the approved style_anchor block into outline.yaml, then returns control to Phase 2. Continue with the next decision (or the architecture gate) once the skill returns.

Slide Budget Calculation

Read guardrail_sources.slide_budgets[] from the speaker profile. Match the spec's duration to the closest budget entry. Read pacing for WPM and slides/min targets.

skills

presentation-creator

references

alternate-entry-flows.md

deck-editing-setup.md

deckops-spec.md

idea-sourcing-wizard.md

pattern-history-authorization.md

phase0-intake.md

phase1-intent.md

phase2-architecture.md

phase3-content.md

phase4-guardrails.md

phase5-slides.md

phase6-publishing.md

phase7-post-event.md

SKILL.md

README.md

tile.json