create-pitch-deck

create-pitch-deck

Read the input document (idea/requirements document) passed via $ARGUMENTS,business planning expertand generate planning proposal slides for a PO (product owner) approval meeting as self-contained HTML (single file).

The reason this skill exists is to create slides that make it easy to grasp "why it is necessary and what the winning strategy is" before prototype development, and by incorporating user feedback and revisions, to detect expectation gaps before development. Therefore, the deliverable must always include"Assumptions and Interpretation" at the beginningand **"Matters requiring approval and matters to confirm" at the end** (for details, see the "Slide Structure" section below).

The assumed usage scenario is "the user is the PO, and the AI brings materials to the approval meeting and explains them."In the first half, explain the problem to be solved and the solution method, and in the second half, explain specifically what kind of screens and what kind of operation flow it will involve, and obtain approval from the POstructuring it with this explanatory flow in mind.It is not an imitation of a static layout; rather, the screens actually move and the explanatory text is highlighted in conjunction with themis the essence of quality, and it is assumed that it will be displayed fullscreen in a browser and actually advanced with the keyboard while explaining.

Persona

The executing agent acts as a business planning expert and always works while asking itself the following.

Why now (market and timing)
Whose pain, and what kind of pain, does it solve
What is the differentiation and winning strategy? Is that a fact grounded in the input document, or an ungrounded hypothesis
Does the explanation concretely convey to the PO "this screen is used in this situation in this way"
What is known from validation (PoC), and what is still unvalidated
What points might the PO be unsure about when making a decision to approve (state them explicitly as approval items and confirmation items)

Recommended execution timing

The optimal time is after the idea document and validation plan (including PoC results) are settled andbeforeentering prototyping/full development. If validation (PoC) results are available, they can be reflected as winning.items[].label: "事実" . If there is a flow for defining behavior and detailed specifications,execute this skill immediately before that, and use the approved materials as input for specification definition(to reduce rework after approval).

Coordination: consistency with create-design-doc (concept-brief.md and recommended execution order)

This skill and create-design-doc are made consistent through the shared agreement document concept-brief.md (the schema is references/concept-brief-schema.md). This is a mechanism to prevent the situation where deliverables created separately by planning (this skill) and design (create-design-doc) end up "saying contradictory things"; both skills have the same procedure (equivalent to Step 1 and Step 9).

Recommended execution order: create-design-doc → create-pitch-deck。 Because this skill's "screen and operation flow" (screen_flow) The slide is create-design-doc generates by rendering at actual size and importing wireframes/*.html , run create-design-doc first.

When executed in reverse order(this skill has already been executed first): screen_flow is temporarily wireframe: null ＋ note: "create-design-doc 未実行のためテキスト概略のみ" generated by (see Step 6).create-design-doc After runningwith the screen materials in place, re-executethis skill. Set the actual file path for the corresponding screen_flow for the entry's wireframe in the deck spec and add steps(an array of CSS selectors and descriptions for the elements you want to highlight); then simply re-executing Steps 7-8 will insert a "working screen demo".
To reliably share between the two skills, explicitly specify the samethe same --brief <path> in both invocations (the default value differs directly under each skill's deliverables directory, so it is not shared automatically unless specified).--brief It is recommended to specify the directory directly under the input document directory(e.g., ideas/<name>/concept-brief.md）。

Usage

Pass the path of the idea/requirements document (directory or file list) as an argument. If unspecified, confirm with the user.

If the output destination is not specified by the user, _/pitch-deck/<deck-name>.html
--theme dark|light switches the color theme between light and dark (default dark. To preserve the atmosphere of an "immersive full-screen presentation"). Override the main color, accent, etc. in the spec's brand to match the tone and manner of concept-brief.md
--brief <path> can specify the location of concept-brief.md (default <output の親ディレクトリ>/concept-brief.md. Specifying directly under the input document directory is recommended)
Priority order when reading large input documents: When a directory is passed, first README.md(overview/ status) -> decision gate "Decision" section (finalized conclusions) -> Go/No-Go criteria and success criteria comparison table (02-poc-plan.md , etc.), and then read the main body
Example use: When using the idea review flow (01-brainstorm.md 〜 03-poc/) as input, ideas/<name>/ pass it as is

Slide structure (first half fixed + second half variable, 10-12 slides)

First half (fixed, in this order): Cover / Premises and interpretation / Issues / Solution approach / Scope (In/Out) / Winning strategy。

Second half: Screen and operation flow（screen_flow, 2-4 slides. For each scenario scene, explain "in this scene, this screen is used like this") -> Verification plan/current status -> Matters requiring approval and confirmation。

The bullet points and cards on each slidefragmentas → appear one at a time with the key, and when they run out, proceed to the next slide (the current position is highlighted, already-read items are dimmed). For details on role, required fields, ordering contract, and HTML operation specifications, refer to references/deck-spec.md , and for the design philosophy of the presentation, refer to references/presentation-patterns.md .

flow

Step 1: Check concept-brief.md

--brief Check the path specified by <output の親ディレクトリ>/concept-brief.md(default

If it exists: Read it as a required input. If you sense a contradiction with the results of the document reading in Step 2, do not overwrite concept-brief.md without permission; instead, make the contradiction explicit and confirm with the user.
If it does not exist: Based on the document reading in Step 2, draft it using the references/concept-brief-schema.md template. Attach a source to each item. Present it to the user at the same time as the Step 4 outline confirmation, and after obtaining approval, write out the finalized version.

Step 2: Read and interpret the input documents

Read the target documents and grasp the purpose, requirements overview, PoC results, and unresolved questions (for priorities, refer to Usage). From the "Product Tone & Manner" in concept-brief.md, decide the selection policy for the spec's brand（primary/accent , etc.) and --theme dark|light .

Step 3: Search for create-design-doc deliverables

create-design-doc Search with wireframes/*.html to determine whether has already been generated(do not hard-code the default path design/wireframes/*.html ; the user may have changed --output ). If found, use it when creating the screen_flow in Step 6. If not found, create only a text outline plus notes for the screen_flow in Step 6.

Step 4: Present the outline and obtain user approval (mandatory gate)

Present to the user together: the titles + one-line summaries of the first six slides, each of the screen_flow slides in the second half (scenario scene name, whether a wireframe is used, candidate elements to highlight), the outline of the verification plan and approval items, the color theme (--theme and primary color), and the Step 1 concept-brief.md draft (if drafted).Do not proceed to Step 5 until approval is obtained. Do not generate without approval.

Step 5: Assemble the deck spec (JSON)

references/deck-spec.md Create the spec according to the schema of

Numbers and facts must only be quotations from the input documents. Do not fabricate
winning.items[].label の "事実" はlimited to actual measurements and survey results recorded in the input documents. Note caveats in text . All other claims must be included in "仮説" make it (事実 items (numbers are automatically given a count-up effect)
approval.items(items requiring approval and confirmation) should be 3 to 5.kind: "承認" separates items to be finalized as policy fromkind: "確認" items requiring the PO's judgment
Keep the amount of text in each fragment (bullet/item) small and bold (one message per fragment). Long text causes overflow within the slide (detected by the validator in Step 9 at the time each fragment is displayed)

Step 6: Assemble the screen_flow slides

Create 2 to 4 slides per scene in the scenario, following the policy below.

Step 3 で wireframes/*.html is found: specify the wireframe file corresponding to the scene wireframe に relative path under the directory of the spec file(absolute paths and ../ escaping is SpecError. Wireframes not under the spec directory should be copied to wireframes/ etc. before referencing).narrative with an introduction, andsteps with an array (one or more items) of "the CSS selector of the element you want to highlight (id/class etc., ones that exist in the wireframe implementation)" and "an explanatory text of what that element means". As steps advance, the target element in the wireframe is spotlighted, and the corresponding explanation is emphasized
If not found: set wireframe: null、note に "create-design-doc 未実行のためテキスト概略のみ" etc., andnarrative outlines the scene with text only (in this case, do not give it steps )

Step 7: Prepare a venv and install Playwright

First python3 exists.

command -v python3 >/dev/null || echo "python3 が見つからない"

If not installed, abort the process and guide the installation method (macOS: brew install python3. Other environments: check the official setup procedure for each environment or ask the environment administrator. Do not guide commands that require privilege escalation).

python3 -m venv "_/pitch-deck/.venv" 2>/dev/null || true
"_/pitch-deck/.venv/bin/pip" install -q playwright
"_/pitch-deck/.venv/bin/playwright" install chromium

To avoid polluting the global environment, always install into a venv dedicated to the skill. The venv location (_/pitch-deck/.venv) may be a temporary work area outside the repository, and the path is not fixed.If a venv has already been created (with playwright installed; a venv created when runningcreate-design-doc is also fine), you may reuse it without recreating it（pip install is an idempotent operation that does not break the existing environment, so running it without checking for existence is harmless).playwright install chromium downloads the browser body (over 100MB), so it takes time.

In the command examples below, the venv's Python is denoted as "${PITCH_DECK_VENV_PY}"(e.g. _/pitch-deck/.venv/bin/python3).

Step 8: Generate the HTML slides

"${PITCH_DECK_VENV_PY}" "${CLAUDE_SKILL_DIR}/scripts/build_slides.py" \
  --spec "<deck-spec.json>" \
  --output "<output.html>" \
  --theme dark

${CLAUDE_SKILL_DIR} is not expanded or not set, read it as the absolute path of the directory where this SKILL.md file is located (e.g. skills/create-pitch-deck）。

build_slides.py works with only the standard library (embedding wireframes is also Pillow-independent. .screen_flow.wireframe self-containedness and inline JS safety are checked at this point. <script> inside wireframes is completely prohibited, and the spotlight effect is injected at embedding time), so the venv in Step 7 is for the next Step 9 (Playwright verification).

SpecErrorIf it fails with (exit code 1), fix the spec or wireframe according to the error message and run it again.

Step 9: Verify

"${PITCH_DECK_VENV_PY}" "${CLAUDE_SKILL_DIR}/scripts/validate_slides.py" \
  "<output.html>" --screenshots-dir "<output の親ディレクトリ>/screenshots"

If FAIL, fix the spec or HTML, regenerate, and then rerun the validator. Do not treat it as complete until it PASSes.--screenshots-dir is specified, PNGs for all slides and all fragment steps (slide-<n>-step-<s>.png. For slides without fragments, slide-<n>-<role>.png) are output for confirmation.

Step 10: Mutual consistency check with concept-brief.md

Cross-check the generated spec and artifacts against concept-brief.md.

Whether there are contradictions in the problem definition, target users, scope, and solution concept
create-design-doc Cross-check consistency between the artifacts (if discovered in Step 3), the winning strategy, and screen design / inclusion of out-of-scope features / inconsistency in terminology and naming / omissions in mapping between problems and solutions

If a contradiction is detected, do not automatically fix either concept-brief.md or this slide; present to the user whether to "fix concept-brief.md or fix this slide."

Step 11: Feedback reflection loop

When reflecting user feedback, fix the spec (and concept-brief.md if necessary), and rerun Steps 8–10.create-design-doc If is run later, return to Step 6 and screen_flow の wireframe/steps insert .

Verification

After generation, always run the validator and confirm completion using the following 5-stage gate (.claude/rules/verification.md compliant).

Identify: validate_slides.py Consider completion upon execution and exit code of
Execute: "${PITCH_DECK_VENV_PY}" "${CLAUDE_SKILL_DIR}/scripts/validate_slides.py" "<output.html>" --screenshots-dir "<dir>" Newly run
Read: Check the entire output (PASS/FAIL, failure list) and exit code.--screenshots-dir Visually check the PNGs of the main steps output to (especially screen_flow spotlight movement)
Verify: Confirm that there are 0 failures, that there is no breakage or highlight position misalignment in visual screenshot checks, and that there are no unresolved contradictions in the Step 10 mutual consistency check
Declare: Declare completion only when the validator PASSes and visual inspection and mutual consistency checks are done. Do not claim completion based on guesses such as "it will probably pass"

validator（validate_slides.py) must at minimum check the following.

Number of slides and role order contract (DOM data-role attribute)
While actually transitioning through all slides and all fragment steps with the → key, the currently displayed slide itself overflows (scrollHeight/scrollWidth が clientHeight/clientWidth not exceeding
screen_flow Whether exactly one expected spotlight is applied within the iframe at each step (detection of selector mismatch or failure to clear). Whether the HTML inside the iframe also has no external resource references or dangerous JS patterns
Prohibited identifiers for external resource references and inline JavaScript (eval・innerHTML, network API, etc. window['eval'] Bracket notation like this is also detected by substring matching)・inline handlers in the parent HTML: zero. Scripts inside the wireframe (srcdoc) are allowed only for the exact spotlight injection script match
Clamping at the end・R returning to the beginning・transition on click・at fragment 0 the ← going back works as specified
The second slide contains "Assumptions", and the final slide contains "Approval" plus 3–5 approval/confirmation items
@media print hides the navigation elements and all fragments become visible

Common failures

Problem	Workaround
Writing differentiators as assertions	Any claim in the input document that lacks numerical/measured evidence must always be made `label: "仮説"` . "Facts" are limited to recorded measurements and research results
Text overflows within a slide	`document.documentElement` , it is detected by the overflow of the `.slide` element itself that is currently displayed (`html`/`body` の `overflow:hidden` , and the documentElement side does not change). Reduce the amount of text in one fragment. The font size has been adjusted with `clamp()` , but it does not shrink indefinitely
screen_flow の `steps[].selector` does not exist in the wireframe	The validator detects this as zero spotlights. Check the wireframe implementation (id/class) before writing the selector
iframe を `transform: scale()` even if scaled down with `.slide` overflows	scale does not reduce the occupied layout size. Wrap the iframe in a `overflow:hidden` wrapper fixed to the actual size after scaling (`build_slides.py` の `.screen-frame` see the implementation. If following it, do not change it)
Approval items become a formality	Make the 3–5 items "specific matters you actually want the PO to judge/confirm." Do not make them vague requests
They say they want to import it into Google Slides	Explain the method of pasting the PNG of each slide and each step (`--screenshots-dir` output) into Google Slides one by one as images (this skill does not generate PPTX)

Notes

The generated HTML is a single file and self-contained (no CDN, external fonts, or external image references. screen_flow の wireframe は srcdoc embedded in the same document)・variable structure of 10–12 slides (fixed 8 slides + screen_flow 2–4 slides)
The role, required fields, and order are the references/deck-spec.md contract
The venv is a build tool, not a generated artifact._/ If placed under_/ は .gitignore , do not commit it (already in
If the report target includes confidential information or non-public actual figures, confirm with the user in advance that the output destination is not a public area
The output destination directory (_/pitch-deck/ , etc.) does not exist, create it with mkdir -p before writing (build_slides.py は --output automatically create the parent directory of)

Final report

Upon completion, report the following concisely.

The absolute path, file size, and number of slides of the generated HTML, and--theme
validation result（PASS/FAIL）
--screenshots-dir the absolute path of (all step PNGs)
The path of concept-brief.md, and whether it is a new draft or an existing load
create-design-doc The incorporation status of deliverables (number of slides with wireframe linkage / number of slides with text only because not executed)
The mutual consistency check result of Step 10 (presence or absence of contradictions)
A one-sentence summary of the deck

Example:

企画提案スライド（HTML）を生成しました:
<absolute-path>/pitch-deck.html（29KB、11枚、theme=dark）

Validation: PASS
スクリーンショット: <absolute-path>/screenshots/（36枚、ステップ単位）
concept-brief.md: <absolute-path>/concept-brief.md（既存読込）
画面と操作の流れ: 3枚中2枚は create-design-doc の wireframes/*.html を実寸連動、1枚は
create-design-doc 未実行のためテキスト概略のみ
相互整合チェック: create-design-doc の成果物と用語・スコープの矛盾なし
内容: 徒歩圏内おつかい代行という課題に対し、3画面で完結する解決アプローチを提案

Reference files

Read only when necessary.

references/deck-spec.md — deck spec (JSON) schema, slide roles, HTML operation specifications, and validation rules
references/presentation-patterns.md — Design philosophy of presentation patterns such as fragments and spotlights (generalized from a close reading of reference sites)
references/concept-brief-schema.md — concept-brief.md's schema (create-design-doc shared with)
samples/pitch-deck-sample.json — Example deck spec entry (fictional idea "Otsukai Panda Bin".screen_flow Includes 2 with wireframe × and 1 without)
samples/wireframes/ — Wireframe for embedding referenced by the sample spec

Execution in a sandbox environment

The main flow of this skill (Steps 1–6, Step 8, Steps 10–11) can be executed in a sandbox environment. build_slides.py is completed with only the standard library and does not use the network. What requires the network is Step 7's pip install playwright と playwright install chromium(only during initial setup. Not needed from the second time onward when reusing an already installed venv), and Step 9's Playwright launch process (it only operates the file:// HTML with local Chromium and performs no external communication, but the initial browser download requires the network). Execute only these commands with the sandbox disabled. The default output destination (_/pitch-deck/) and the default brief path are both inside the workspace, but if you specify an absolute path or a relative path containing --output / --brief in ../ , it may write outside the workspace, so in that case choose the output destination at your own responsibility.