presentation-builder

Codex compatibility note:

• Invoke $skill-name: load the registered .agents/skills/<name>/SKILL.md and execute it with Codex tools; no separate Skill tool or Claude mode switch is needed. Author .claude/**; mirrors are generated.
• Track steps before execution and keep progress/evidence current. Explicit skill requests execute their protocol. Use the native question tool for required questions.
• Map foreign tool names to available host capabilities. A name mismatch needs no approval; an actually unavailable required capability stops with its step/evidence and a user question before adaptation.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Preserve protocol order unless the user approves a deviation. Workflows use $start-workflow: gates stay fixed; other steps may flex with logged reasons and evidence.

[BLOCKING] Execute the declared steps in order. Keep one task in_progress; mark each task completed with evidence immediately after it returns. [BLOCKING] If task tools are unavailable, maintain an equivalent tracker in the working response or a disposable report under tmp/reports/. [BLOCKING] Do not claim browser behavior passed when only static inspection was possible.

Quick Summary

Goal: Turn any subject and source material into a clear, audience-specific presentation whose story, visuals, notes, and runtime behavior are all reviewable.

Summary:

• Frame audience/goal/environment and evidence boundaries; build a source ledger; select a subject-appropriate narrative archetype and slide map.
• Create and critique a subject-grounded design plan; generate semantic, self-contained HTML with stable slide/purpose/note markers.
• Guarantee the presenter runtime: complete notes, notes toggle, keyboard navigation, accessible state, explicit edit mode, local draft persistence, reset, export, overview, fullscreen, print, and reduced motion.
• Run static validation, browser/manual rehearsal when available, and a final evidence report that distinguishes PASS from NOT VERIFIABLE.

Default output: One self-contained HTML deck. If another format is requested, keep a companion editable HTML deck unless the requested artifact itself satisfies the runtime contract.

Non-negotiables: Every slide has a job, title, source/rationale, and detailed speaker notes. The deck always includes a visible notes toggle and an explicit edit mode with editable prose and notes, local draft persistence, reset, and clean export.

Workflow: frame audience/goal/environment → research and source claims → choose narrative archetype → write slide map → make a subject-grounded design plan → generate → validate → manually rehearse/review → report evidence and limits.

Utilities: node .claude/skills/presentation-builder/scripts/create-presentation.cjs <deck.json> <output.html> generates a self-contained contract-compliant starter deck; node .claude/skills/presentation-builder/scripts/validate-presentation.cjs <deck.html> [--profile=presenter|review] performs deterministic static checks against one conformance profile (default presenter; review makes only the five editing checks advisory — references/web-runtime-contract.md §9). Run both utility test files after changing them.

Key Rules:

• MUST ATTENTION give every slide a single job, stable ID, meaningful title, rationale, and non-empty notes.
• MUST ATTENTION keep notes detailed enough for presenter handoff: talk track, why, evidence/caveat, timing, transition, and question.
• MUST ATTENTION provide visible Notes and Edit mode controls with stateful accessible semantics.
• MUST ATTENTION protect structure and persist edits as a namespaced local draft with reset and clean export.
• ALWAYS preserve keyboard navigation and a visible progress/status path.
• ALWAYS run static validation, then verify browser behavior separately when a browser is available.
• NEVER invent subject claims, precision, sources, audience, or design rationale.
• NEVER claim interactive, offline, fullscreen, persistence, or accessibility behavior from static markup alone.