Dashi PPT

Dashi PPT generates static HTML horizontal-sliding PPTs. When using this skill, first organize the user's natural language requirements into a JSON plan, then call the local project generator to output

index.html

and

assets/

Version

Current version:

0.4.11

Before completing a user request and preparing the final response, run:

bash

node <skill-root>/scripts/check_latest_version.mjs

If the script outputs content, append the output to the end of the final response to remind the user to update; if there is no output or the check fails, remain silent and do not mention the version check.

Skill Directory

The directory where the current

SKILL.md

resides is the Skill root directory, referred to as

<skill-root>

below.

Built-in generator directory:

<skill-root>/project

Render scripts:

macOS / Linux:

<skill-root>/scripts/render_goal_deck.sh

Windows PowerShell:

<skill-root>/scripts/render_goal_deck.ps1

Version check script:

<skill-root>/scripts/check_latest_version.mjs

Generation Principles

This Skill generates 3 template solutions and 1 Agent-customized solution for each logical page, outputting HTML PPTs that can be opened offline.

The first three template solutions follow the principle of "lock the template and fill in the copy": retain the original visuals, structure, quantity, visibility, emphasis, color scheme, chart type, and image slots of the selected page components, only replacing visible text content. Do not modify any non-copy props unless the user explicitly requests to adjust page properties. The fourth solution is customized by the Agent within the visual language of the current theme based on the page content, and is not a template candidate.

Result acceptance is a default process. After each generation, judge whether the final product meets the user's goal; by default, check the goal, content, structure, obvious visible issues, and delivery completeness, do not perform screenshot aesthetic retouching, and do not rework repeatedly due to ordinary line breaks. Only expand to visual QA when the user explicitly requests "visual retouching", "100% check", or "adjust until I'm satisfied".

Usage Rules

Node.js 20+ and npm are required to run the generator; the render script will install dependencies in the Skill's built-in
```
project/
```
directory during the first generation. Use
```
render_goal_deck.ps1
```
for Windows (directly in PowerShell, not via WSL/bash); use
```
render_goal_deck.sh
```
for macOS / Linux.
Style selection question: The user-visible response must embed the Markdown image of
```
<skill-root>/assets/skill/theme-style-grid.png
```
, first expand the absolute path; this is the built-in style image for response display, and cannot be written into
```
goal.json
```
or any media field; list the currently available styles and minimal "suitable scenarios/audiences", and do not only mention the style image in internal progress prompts.
Confirm two things before starting: theme style, whether images/videos are needed. When the user does not clearly express this and it is not an overall commission, ask for confirmation first and wait for a reply, do not make selections on behalf of the user; only make selections on your own in non-interactive environments (scripts/batch processing), and list the selected options and reasons in the delivery instructions.
Commission mode: Only when the user explicitly delegates the whole task ("you decide everything", "don't ask, just start") can you select the theme, default to HTML, and default to not using image-gen, and finally explain the assumptions. When the user only says the content/copy is "random" or "feel free to draft", only draft the content; do not change the given style, page count, media, etc. without permission, and follow the previous rule to ask first for unspecified items.
For non-interactive/one-time execution (cannot follow up): If no style is specified, select an accepted theme based on the content theme; if there is no real material and image generation is not possible, prioritize pages without media slots and do not use image-gen; finally explain all assumptions.
Deck language follows the user's communication language: For non-Chinese users, add
```
"language": "en"
```
at the top level of
```
goal.json
```
; write all copy fields in the target language, and overwrite all default Chinese copy on the page (including decorative fields like "Thank you for reading" on the ending page), no Chinese content shall remain. The editor interface language automatically follows the system language of the opener, and can be manually switched in the upper right corner, no need to handle it during generation.
Delivery format: Default is HTML; "Generate PPT", "Make a PPT", "Create a PPT", "Make ppt" mean PPT presentation format. Only deliver PPTX files when the user explicitly specifies
```
PPTX
```
,
```
PowerPoint
```
,
```
Editable PPTX
```
,
```
Export PPTX
```
,
```
PPT format
```
, or "Format/file type is PPT/PPTX".
PPTX files: Still generate HTML first and start the local preview service, then call the local HTTP export service; finally only provide the PPTX file path or download result.
Currently available styles:
```
theme01
```
Neumorphism Style,
```
theme02
```
Glowing Purple-Green Style,
```
theme03
```
Light/Dark Code Style,
```
theme04
```
Glass Candy Style,
```
theme05
```
Color Spectrum Chart Style,
```
theme06
```
Dark Atlas Style,
```
theme07
```
Cool White Research Style,
```
theme08
```
Black Gold Experimental Style,
```
theme09
```
Deep Blue Magazine Style,
```
theme10
```
Golden Index Style,
```
theme11
```
High-Energy Growth Style,
```
theme12
```
Sound Wave Neon Style.
Do not select
```
theme10
```
for ordinary automatic selection; only use it when the user explicitly specifies it, or when the content is strongly related to financial/investment indexes and inspect confirms it can be filled.

```
theme01
```
Neumorphism Style | Suitable for: Product introduction / Enterprise reporting | Audience: Startup teams / Product managers
```
theme02
```
Glowing Purple-Green Style | Suitable for: Tech conferences / AI/Autonomous driving/Robot themes | Audience: Tech company founders / Technical leaders
```
theme03
```
Light/Dark Code Style | Suitable for: Technical solutions / Developer conferences | Audience: Engineers / Technical managers
```
theme04
```
Glass Candy Style | Suitable for: Youthful brands / Consumer products | Audience: Brand teams / Designers
```
theme05
```
Color Spectrum Chart Style | Suitable for: Data reports / Market analysis | Audience: Data analysts / Consultants
```
theme06
```
Dark Atlas Style | Suitable for: High-density data display / Strategic analysis | Audience: Strategic teams / Investors
```
theme07
```
Cool White Research Style | Suitable for: Research reports / White papers | Audience: Research institutions / Consulting teams
```
theme08
```
Black Gold Experimental Style | Suitable for: High-end launches / Brand proposals | Audience: High-end brands / Creative directors
```
theme09
```
Deep Blue Magazine Style | Suitable for: Brand stories / Interviews | Audience: PR teams / Media editors
```
theme10
```
Golden Index Style | Suitable for: Financial data / Investment reports | Audience: Investment institutions / Financial analysts
```
theme11
```
High-Energy Growth Style | Suitable for: Growth reviews / Business plans | Audience: Entrepreneurs / Growth teams
```
theme12
```
Sound Wave Neon Style | Suitable for: Music entertainment / Trend events | Audience: Entertainment brands / Event planners

Do not use old tokens, old themes, old media slots, old style branches, or old entrance animation controls.

First freeze the

slide.content.presentation

of the page, then pass

--title-chars

--summary-chars

--takeaway-chars

--item-count

--value-item-count

--raw-numeric-item-count

--textual-value-item-count

--nested-depth

, and

--priority

according to the actual capacity, for example

npm --prefix <skill-root>/project run layout:query -- --theme <themePack> --item-count 4 --value-item-count 4 --textual-value-item-count 4 --priority metrics --limit 12 --seed <randomSeed>:slide-<n>

. Title, items,

value/displayValue

, and explicit media are hard conditions; summary, conclusion, detail, unit, focus, and role only affect sorting. Select 3 layouts from different structure families for each page, assign them uniformly for the entire deck, and do not repeat the same set of three layouts. Add

--needs-media

--planned-images <n>

--provided-images <n>

, or

--image-gen

when media slots are needed.

For unclear fields, object/array/count, images/media: First run
```
npm --prefix <skill-root>/project run inspect:layout -- --compact <layout...>
```
to check the 3 template solutions for the page. Scaffold recognizes both array containers and repeated scalar slot groups, and only projects the complete
```
items
```
to the unique main container; set auxiliary visible containers to 0 when they can be hidden, and the layout exits the candidate when it cannot be hidden and has no valid supporting content. Do not let the Agent write 30 copies of
```
contentMap
```
; only fill the page mapping according to
```
goal.fill-plan.json
```
when the user explicitly specifies a complex layout. When writing object, array, count, or image props: Run
```
props:safe
```
, and use
```
props:safe -- --goal <file> --write
```
for the entire goal.

When piping the JSON of

layout:query

inspect:layout

to the program for parsing, use

node <skill-root>/project/scripts/layout-query.mjs

node <skill-root>/project/scripts/inspect-layout.mjs

instead:

npm run

will print a lifecycle banner before stdout, which pollutes the JSON.

For long decks: First write page-by-page brief JSON, each page containing

role

priority

, and unique

content

, then use

npm --prefix <skill-root>/project run goal:scaffold -- --title <title> --goal <goal> --theme <themePack> --pages <n> --content-briefs <briefs.json> --layout-variants 3 --seed <randomSeed> --workflow-run-id <workflowRunId> --chunk-size 5 --out output/<deck-name>/goal.json

. Scaffold selects 3 templates based on content capacity and field capabilities, and appends a theme-based v4 draft that can be directly rendered.

Copy length and array count: Prioritize writing according to
```
fillPlan.text[].maxChars
```
,
```
fillPlan.arrays[].visibleCount
```
,
```
fillPlan.arrays[].nestedArrays
```
; write only short words, short sentences, or numbers in
```
display
```
/
```
metric
```
fields.
For Html fields (such as
```
headlineHtml
```
/
```
quoteHtml
```
), only use
```
 
```
for line breaks and
```

```
/
```

```
for inline emphasis when writing copy; prohibit free HTML like
```

```
; the
```

```
in theme default values depends on theme CSS and is only a placeholder, do not copy it.
```
validate:goal-spec
```
will block free HTML.
Visible array items must contain real copy; the hidden tail items controlled by count/visibility can retain the placeholder "Please enter text".
Use the native effects of page components for element appearance animations.
Page switching animations can be adjusted in the preview control panel.
The deck delivered to users does not display style/theme switching options by default; style switching is only retained in the internal debugging demo page. When the user explicitly requests to keep the theme switcher, write
```
preview: {"themeSwitcher": true}
```
at the top level of the goal.
Do not write free HTML slides. Newly generated decks use
```
schemaVersion: 2
```
; each logical page only saves one copy of
```
content
```
, the first three items are
```
{kind:"template", layout, props, contentMap}
```
, the fourth item is
```
{kind:"bespoke", adjustable:false, composition, contentMap}
```
, and v4 does not write
```
layout
```
,
```
props
```
, or
```
controls
```
. Old decks with single layout and 3 candidates can still be read.
The first 5 pages
```
themeXX_page001
```
to
```
themeXX_page005
```
of each theme are cover candidates. A deck can only have 1 logical cover page, and its 3 template solutions are all selected from the first 5 pages; the template solutions for the main body are selected from page 6 onwards.
The 3 template layouts within the same logical page must be mutually exclusive and preferably from different structure families; first use layouts and structure fingerprints that have not appeared in the entire draft, and reuse only when candidates are insufficient, do not cycle the same set of visual skeletons on adjacent pages.
The deck delivered to users cannot only write
```
role
```
and rely on the default page copy. Write real content in
```
slide.content
```
for each page first, and only retain non-content configurations in the template props.
First write a
```
slide.content.presentation
```
copy package for each logical page, including
```
title/titleShort
```
,
```
summary/summaryShort
```
,
```
takeaway/items
```
, and optional
```
structure
```
; each item uses stable
```
id/label/value/displayValue/detail/unit/required/priority
```
. v1-v3 share page intent, core conclusions, all required facts, key numbers and their units, only select long/short copy, sorting, grouping, and visual hierarchy, do not create three sets of stories separately. Use
```
{source:"presentation.items",fields:{target field:"label"}}
```
for simple array mapping.
v4 must be designed after independently analyzing the user's goal, audience, narrative role of the page, and key information; it is allowed to reorganize, focus, or rewrite expressions from the same fact source, but do not add new facts. Only use the font hierarchy, page frames, color bands, lines, cards, and chart recipes exposed by the current theme runtime, do not write raw CSS, and it is not a minor modification of the first three templates.
When
```
baoyu-design
```
is provided in the Codex environment, read this Skill before designing v4, use its design arguments, visual focus, rhythm, and composition methods to complete the artistic direction of the entire draft; the current theme runtime is regarded as the binding design system, and only the constrained
```
composition
```
is finally implemented, no independent HTML/CSS is output. Follow the same artistic direction standards when this Skill is not provided.
v4
```
composition.designIntent.compositionFamily
```
uses the
```
hero/split/metric-spotlight/chart-led/timeline/matrix/editorial/comparison/process
```
assigned by scaffold; the page geometry must clearly implement this family, do not draw different families as title plus card walls. The same family does not appear consecutively in the entire draft, and card grids account for at most one-third of the main body v4.
v4
```
composition
```
uses theme background semantics and 12×8 grid elements; only use element types
```
text
```
/
```
metric
```
/
```
list
```
/
```
quote
```
/
```
media
```
/
```
shape
```
/
```
chart
```
. Chart-type pages take data graphics as the main visual, timeline/process pages take direction and connection relationships as the main visual, split/editorial pages use asymmetric hierarchy, do not treat label color change as design.
v4 is optimized based on the complete theme-based composition draft of scaffold; retain the assigned composition family and theme recipe, only reorganize pages that truly improve expression, do not clear
```
elements
```
and then re-generate the same set of cards in batches.
The
```
copyKeys
```
/
```
fillPlan.text
```
copy slots of the 3 template solutions must be covered by canonical content; the unique main array or scalar slot group consumes the complete
```
items
```
, and auxiliary content containers can only be legally hidden or make the layout exit the candidate.
```
title
```
and
```
titleShort
```
belong to the same title semantic family.
Prioritize writing only the copy fields exposed by
```
layout:query
```
/
```
inspect:layout
```
. When a field is an object or array, fill in the internal keys according to
```
fillPlan
```
and
```
propShapes
```
.
```
copyKeys
```
has expanded nested paths (such as
```
copy.quote
```
,
```
items[].label
```
), fill in directly according to the listed paths.
Pages marked
```
contentLocked: true
```
by
```
inspect:layout
```
have fixed main content by components and cannot be filled with props: switch to a layout that can fill the main content, or use it only when the user accepts its default main content. Fill the visible items according to
```
fillPlan.arrays[].visibleCount
```
;
```
decorativeKeys
```
are decorative positions, do not fill in.
Do not modify page metadata, component source code, className, CSS, style fields, or default visual structure to complete content filling. Only fill in content and page properties explicitly requested by the user in
```
props
```
.
It is allowed to use the top-level
```
text
```
to overwrite visible text slots, but only for replacing text content. Do not start the browser to batch extract all page text slots in ordinary generation; only perform runtime slot extraction when the user explicitly requests "completely clear all template default copy/proofread visible copy page by page".
Forbid reusing old
```
goal.json
```
or old HTML in
```
output/
```
. Create a new output directory and JSON plan for each request.
Write the output directory in the current session working directory, do not write to
```
<skill-root>/project/output
```
.
HTML delivery: Only provide the preview address
```
http://127.0.0.1:<port>/
```
to the user (do not provide https or .local variants); the local HTTP service can export HTML/PDF/PPTX, while local HTML or
```
file://
```
cannot export editable PPTX. Do not return
```
theme-preview
```
. When generating in an Agent APP with a built-in browser (such as Codex), remind the user to open the address in the system browser before exporting PDF/PPTX.
PPTX delivery: Call
```
/api/export-editable-pptx
```
; finally only provide the PPTX file path or download result.
When there is no browser session, direct script call, or the preview export interface returns 403/5xx: Use
```
npm run export:pptx -- <deck>/ppt <out.pptx>
```
(use
```
export:pdf
```
for PDF) to directly generate the file, no need to start a browser session first.
If default copy unrelated to the user's theme appears in the output content, such as AI Capital / Investment and Financing / SoundWave / Key Metrics / Roadmap / End of Report, etc., rewrite the JSON and re-render, do not deliver it.

Media Workflow

Only write slots with
```
mediaSlots[].canPresetMedia: true
```
in media fields, write paths according to the slot's
```
presetProp
```
/
```
fieldPath
```
;
```
goal.json
```
only references relative media paths within the deck, cannot reference temporary directories, external absolute paths,
```
file://
```
, or remote URLs.
First judge the intention for visual material tasks: When no images are available but visual materials are needed, first ask whether to reserve image slots; when there is no real material and image generation is not possible, prioritize pages without media slots. When the user provides a material library/material directory path, it is regarded as having the intention to use images: select at least 2 pages with media slots and fill in appropriate materials. If the material path is inaccessible, switch to pages without media slots and inform the user in the delivery instructions, do not leave placeholder prompt text in the page. When the user agrees to use
```
--planned-images <n>
```
/
```
--needs-media
```
, use
```
--provided-images <n>
```
/
```
--provided-media
```
when the user provides materials, use image-gen to generate images and add
```
--image-gen
```
when the user explicitly requests original visual images/image generation; ask the user first when image generation is not explicitly requested.
```
plannedImages
```
/
```
needsVisual
```
/
```
imageGen
```
only indicate page selection intention, unless the user explicitly chooses to reserve empty slots, write real media paths before delivery, do not deliver empty media slots or fake paths.
For user's local images/videos, first run
```
npm --prefix <skill-root>/project run media:stage -- <deck-output-dir-or-ppt-dir> <media-file...>
```
, use the returned
```
relative
```
path; AVIF will be converted to a browser-compatible format. Image-gen output also falls into the current deck directory first.
After rendering, check each image/video referenced in the goal:
```
ppt/<relative>
```
exists and the HTML contains the file name; if missing, only supplement the final
```
ppt/assets
```
and re-run the verification. Each image/video material can be used at most once; the 4 solutions of the same logical page share the same material, which counts as 1 logical use, do not fill the same material in different logical pages. After the materials are used up, leave the media slots empty or switch to pages without media slots.
When image-gen is needed to generate more than 2 independent images, use multiple subagents to generate in parallel, do not wait serially one by one; generate each image independently, do not use a single puzzle/material board and then split it. Subagents are only used for image generation, not for topic selection, copy writing, page selection, or verification.

Workflow

Refine user goals:
```
title
```
,
```
goal
```
,
```
audience
```
,
```
owner
```
, page count, content focus, and final product format; at the same time form an acceptance checklist, recording the user's explicit requirements, confirmed options, and necessary assumptions. When the user does not specify the page count, default to about 10 pages, no less than 8 pages.
Confirm
```
themePack
```
. When the user does not specify it, first ask about the style; after the user selects it, generate a
```
randomSeed
```
and a unique
```
workflowRunId
```
for this task, such as
```
<theme>-<date>-<3 random words>
```
, to ensure that random page selection is reproducible; reuse this run ID for retries of the same task, generate a new ID for new tasks.
Judge image intention: When no images are available but visual materials are needed, first ask whether to reserve image slots; when the user provides local materials, first run
```
media:stage
```
; use image-gen when image generation is explicitly requested.
Write the page-by-page brief and
```
content.presentation
```
copy package for the entire deck at one time; the first three templates share required facts and key numbers, and provide full/short versions for title/summary. Pass the hard capacity and soft preferences to
```
goal:scaffold
```
at one time, do not try and switch themes page by page.
Scaffold completes candidate query, unique main container projection, auxiliary container processing, three-layout combination allocation, and v4 theme-based draft for the entire deck at one time; the 3 templates directly materialize the same copy package, do not manually fill
```
contentMap
```
page by page. The Agent uses
```
baoyu-design
```
to first determine the design arguments, rhythm, and visual focus of each page for the entire draft, then batch draws v4 based on the existing
```
compositionFamily
```
and theme recipe, prohibits clearing the draft and then degenerating into card grids page by page temporarily.
Write the schema v2 JSON into
```
output/<deck-name>/goal.json
```
in the current working directory; write
```
selectedVariant: "v1"
```
and exactly 3 template + 1 bespoke for each page. Before rendering, run
```
npm --prefix <skill-root>/project run props:safe -- --goal output/<deck-name>/goal.json --write
```
and goal spec verification. After
```
--write
```
, check the
```
layoutChanges
```
of the 3 template solutions; if you do not approve the replacement, change it back and switch pages.
After filling in the data for chart pages, the insight/chart reading/conclusion copy fields within the page must be rewritten according to the new data, do not retain the default conclusion.
Run the render script to output
```
output/<deck-name>/ppt/index.html
```
; the script will use the Skill's built-in generator, do not switch back to the external project directory.
After rendering, check the material paths, supplement the final
```
ppt/assets
```
if missing.
Confirm that the script has completed
```
validate:swiss
```
,
```
validate:goal-copy
```
, and
```
validate:four-variant-quality
```
verification; the latter checks and screenshots each page's v4 in batches in the same browser session. Only one
```
workflowRunId
```
is created for one user generation task, and all scaffold attempts and subsequent stages reuse it.
The render script will start a local HTTP preview service and output
```
http://127.0.0.1:<port>/
```
; to specify a port, set
```
DASHI_PPT_PREVIEW_PORT
```
before running the script (use ports in the 5200-5999 range, ports 4178/4300/4400 are reserved for users and cannot be used). Only use this preview service, do not replace it with static servers like
```
python -m http.server
```
or
```
npx serve
```
: static servers do not have export and auto-save interfaces. Editing under the preview service is automatically saved to the
```
index.html
```
itself; local files opened via
```
file://
```
are not automatically saved, need to be exported before delivery.
Perform result acceptance on the final product: Only perform one batch of content mapping, size, and runtime checks for template solutions; perform visual acceptance for v4 by viewing all screenshots at once.
When v4 needs correction, only modify the failed pages and re-render once; do not re-select templates, rewrite other pages, or repeat the visual check of the entire draft.

Run

node <skill-root>/scripts/check_latest_version.mjs

for silent version check.

After passing the acceptance, reply according to the delivery format: Only provide
```
http://127.0.0.1:<port>/
```
for HTML; after calling
```
/api/export-editable-pptx
```
for PPTX, only provide the file path or download result.

Result Acceptance and Rework

Machine verification passing is only a technical baseline, not equivalent to passing the result. The final acceptance is based on the user's original requirements, confirmed options, explicit assumptions, and final rendered product:

Goal consistency: The Deck answers the user's core question, and the focus, conclusion, and tone are suitable for the target audience.
Content coverage: The specified theme, mandatory points, page count, style, language, media, and product format are all implemented, no off-topic, missing items, or unrelated template copy.
Page-by-page check: Each page serves the overall goal; title, main body, data, charts, and insight are consistent with each other, no repetition, disconnection, blank pages, or obviously mismatched layout.
Solution check: v1-v3 share page intent, required facts, and key numbers, and the entire draft does not cycle the same set of three layouts; v4 reorganizes the expression based on the same fact source according to the user's goal, and geometrically implements the assigned compositionFamily. Templates complete runtime checks, bespoke completes visual checks.
Narrative integrity: The order of opening, argumentation/expansion, and conclusion/action is clear, and there is logical connection between pages.
Delivery completeness: The final file exists and can be opened, the page count and format are correct, materials are usable, and the first and last pages are not blank.

When browser capability is available, open all v4 pages in batches in the final round, check that content is visible, media works normally, no obvious overflow, occlusion, or cropping; do not perform screenshot aesthetic review for templates.

The acceptance status is only "Passed", "To be corrected", or "Blocked". When v4 is unqualified, only modify the corresponding composition, replace the layout if necessary, then re-render and re-check these pages once; if still not passed, mark it as "Blocked" and explain the unqualified items.

Example command (macOS / Linux):

bash

<skill-root>/scripts/render_goal_deck.sh \
  output/client-review/goal.json \
  output/client-review/ppt/index.html

Windows PowerShell:

powershell

& "<skill-root>/scripts/render_goal_deck.ps1" `
  "output/client-review/goal.json" `
  "output/client-review/ppt/index.html"

JSON Structure

json

{
  "schemaVersion": 2,
  "title": "US AI Funding Research",
  "goal": "Report to the investment team on the structure of large AI funding in the US from 2024-2026, capital flow, and subsequent judgments",
  "audience": "Investment team / Industry research team",
  "owner": "Research team",
  "randomSeed": "ai-funding-20260609-a7k",
  "workflowRunId": "20260609T120000000-a7k9m3x2",
  "pageCount": 1,
  "themePack": "theme01",
  "variantOutputMode": "comparison",
  "slides": [
    {
      "id": "s1",
      "content": {
        "presentation": {
          "title": "US AI Funding Research",
          "summary": "Structure of Large Funding, Capital Flow and Subsequent Judgments (2024-2026)",
          "takeaway": "Establish a unified research scope for investment decisions",
          "items": []
        },
        "media": [],
        "meta": {
          "brand": "Research team",
          "pageLabel": "2026",
          "panelTitle": "Funding Research"
        }
      },
      "selectedVariant": "v1",
      "variants": [
        {"id": "v1", "kind": "template", "layout": "theme01_page001", "props": {}, "contentMap": {"kicker": "meta.panelTitle", "titleTop": "presentation.title", "titleBottom": "presentation.summary", "lead": "presentation.takeaway"}},
        {"id": "v2", "kind": "template", "layout": "theme01_page002", "props": {}, "contentMap": {"enKicker": "meta.panelTitle", "titleTop": "presentation.title", "titleBottom": "presentation.summary", "subtitle": "presentation.takeaway"}},
        {"id": "v3", "kind": "template", "layout": "theme01_page003", "props": {}, "contentMap": {"kicker": "meta.panelTitle", "titleTop": "presentation.title", "titleBottom": "presentation.summary", "bigNumber": "meta.pageLabel"}},
        {
          "id": "v4",
          "kind": "bespoke",
          "adjustable": false,
          "composition": {
            "designIntent": {
              "objective": "Quickly establish research scope",
              "audience": "Investment team",
              "narrativeRole": "Cover page positioning",
              "emphasis": "Research object and decision value",
              "rationale": "Shorten the understanding path with a single central title and three scope prompts",
              "compositionFamily": "hero"
            },
            "background": "dark",
            "elements": [
              {"id": "title", "type": "text", "grid": {"column": 1, "row": 1, "width": 10, "height": 2}, "role": "title", "text": ""},
              {"id": "summary", "type": "text", "grid": {"column": 1, "row": 4, "width": 7, "height": 2}, "role": "body", "text": ""}
            ]
          },
          "contentMap": {"elements[0].text": "presentation.title", "elements[1].text": "presentation.summary"}
        }
      ]
    }
  ]
}

slides

is empty,

pageCount

is only suitable for temporary draft preview. Newly generated decks must be implemented as schema v2 with 3 template + 1 bespoke before delivery to users; old goal files with single layout and old 3 candidates can still be read.

Page Roles

role

is only used for draft page selection, the first three solutions in the final JSON must be implemented as specific

layout

, and v4 must be implemented as bespoke composition without layout. See

references/layout-roles.md

for role descriptions; the real template candidates are subject to the output of

layout:query

cover

can only be selected from the first 5 pages of the current theme.

image

media

candidates are based on real

mediaSlots

, not page title keywords. Dynamic background pages can use

ambient

as atmosphere pages or chapter pages.

You can directly specify a page:

json

{"layout": "theme01_page030", "props": {"title": "Typical Cases"}}

Delivery Capabilities

The editor and left directory always only display N logical pages, switching candidates on the same page does not change the logical page number. The right panel can switch or mark 4 solutions; the first three template solutions can adjust props, v4 is a fixed Agent-customized solution. Only derive 4N pages during the export phase when

variantOutputMode:"comparison"

(used for PDF/PPTX and comparison drafts explicitly requested by users); export N pages when

"selected-only"

. The bottom of pages delivered to users does not display page number identifiers, page-turning guides, dot navigation, or index prompts.

Page Attribute Contract

Do not read

layout-manifest.json

for ordinary generation. First use the candidate summary output by

layout:query

. Only use

npm --prefix <skill-root>/project run inspect:layout -- --compact <layout...>

to view the page contract when more detailed contracts are needed:

```
copyKeys
```
: Copy/data fields that can be safely rewritten.
```
copyBudgets
```
: Copy length budget;
```
display
```
/
```
metric
```
fields that are too long will be intercepted by goal spec.
```
propShapes
```
: Internal shapes of
```
copyKeys
```
/ array fields; only use the keys listed here when writing object fields such as
```
copy
```
,
```
cells
```
,
```
items
```
,
```
rows
```
.
```
fillPlan.arrays[].itemFields[].enum
```
: This field is a structural enumeration, can only be selected from the listed values, not free copy.
```
mediaSlots
```
: Fields for writing images/videos, count key, default quantity, and maximum quantity.
```
countBindings
```
: Binding between quantity parameters and array fields.
For numeric fields in
```
fillPlan
```
, fill in numbers according to
```
numericBounds
```
:
```
enforced:false
```
is a hint, real data can exceed it,
```
enforced:true
```
must be followed,
```
semantics:'normalized'
```
fill in 0-1 ratio; for fixed-length nested arrays, fill in according to the index based on
```
fixedLength
```
/
```
fixedLengths
```
, do not try and error.
```
controlKeys
```
: Fields operable in the right panel, not a normal content filling list; only use them when the user explicitly requests to adjust page properties. By default, only fill in
```
copyKeys
```
, visible arrays, and real media slots.

Validation

Must run
```
validate:goal-spec
```
before rendering.
Must run
```
validate:swiss
```
after output.
Must run
```
validate:goal-copy
```
after output.
Run
```
npm run showcase:update
```
after modifying the demo display.

dashi-ppt

NPX Install

Tags

SKILL.md Content (Chinese)