kotonoha 0.1.2 → 0.1.4

package/CHANGELOG.md

@@ -5,6 +5,34 @@ All notable changes to this project are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+## [0.1.4] - 2026-09-29
+
+### Added
+
+- Add Japanese requirements-definition and system-design templates with
+  doctype routing, responsibility boundaries, traceability, and review
+  checklists.
+- Add Japanese test-plan, operations-runbook, migration-plan, and
+  security-design/threat-model templates with dedicated doctype guidance
+  and review checklists.
+- Add the `presentation-planner` skill for presentation requirements,
+  storyline, slide outlines, design specifications, and PPTX-skill handoff.
+- Add executive decision, technical briefing, and data report presentation
+  scenario templates plus a `presentation-scenario.md` planning artifact.
+- Add executive proposal, technical briefing, and data report design
+  specifications in YAML.
+- Standardize presentation designs on white backgrounds with Microsoft
+  corporate colors and accessible dark semantic text colors.
+- Add a guide for adapting design specifications and adding reusable
+  presentation templates.
+- Add multi-skill installation with `kotonoha install --skill <name|all>`.
+- Add Japanese templates for technical proposals, requests for information
+  (RFI), and requests for proposal (RFP).
+- Add doctype routing, writing guidance, and checklists for the three new
+  templates.
+
 ## [0.1.2] - 2026-09-29
 
 ### Added
@@ -45,3 +73,5 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 [0.1.2]: https://github.com/nahisaho/kotonoha/compare/v0.1.1...v0.1.2
 [0.1.1]: https://github.com/nahisaho/kotonoha/compare/v0.1.0...v0.1.1
 [0.1.0]: https://github.com/nahisaho/kotonoha/releases/tag/v0.1.0
+[0.1.4]: https://github.com/nahisaho/kotonoha/compare/v0.1.2...v0.1.4
+[Unreleased]: https://github.com/nahisaho/kotonoha/compare/v0.1.4...HEAD

package/README.md

@@ -1,10 +1,15 @@
 # kotonoha
 
-kotonoha provides `tech-writer`, a GitHub Copilot CLI skill that helps
-structure and polish technical documents. It covers README, design
+kotonoha provides GitHub Copilot CLI skills for technical documents and
+presentation planning. `tech-writer` helps structure and polish README, design
 docs/ADRs, API reference, PR descriptions/commit messages/issue reports,
-release notes, user manuals/how-to guides, code comments, and Qiita/Zenn
-articles, structured so readers never get lost.
+release notes, user manuals/how-to guides, code comments, requirements
+definitions, system designs, test plans, operations runbooks, migration plans,
+security designs, technical proposals, RFI/RFP procurement documents, and
+Qiita/Zenn articles,
+structured so readers never get lost. `presentation-planner` turns source
+material into a reusable presentation scenario, slide outline, design
+specification, and handoff for a dedicated PPTX creation skill.
 
 ## What tech-writer solves
 
@@ -20,7 +25,9 @@ Japanese prose with natural-japanese.
 
 - Create/review README, design docs/ADRs, API reference, PR
   descriptions/commit messages/issue reports, release notes, user manuals,
-  code comments, and Qiita/Zenn articles
+  code comments, requirements definitions, system designs, test plans,
+  operations runbooks, migration plans, security designs, technical proposals,
+  RFI/RFP procurement documents, and Qiita/Zenn articles
 - Doctype-specific structure and checklists to guide writing
 - Iterative rubber-duck review after document creation, with fixes and
   re-review until no actionable findings remain; unavailable reviews are
@@ -35,6 +42,49 @@ Japanese prose with natural-japanese.
   (the target programming language's own syntax)
 - Japanese as the primary target language, with English document support
 
+## Supported document types
+
+| Document type | Examples | Doctype |
+|---|---|---|
+| Project overview | README | `readme` |
+| Design decision | Design doc, ADR, RFC | `design-doc` |
+| Requirements definition | 要件定義書, functional and non-functional requirements | `requirements-definition` |
+| System design | システム設計書, architecture and detailed system design | `system-design` |
+| Test planning | テスト計画書, test strategy and acceptance evidence | `test-plan` |
+| Operations | 運用設計書, operations runbook, incident procedures | `operations-runbook` |
+| Migration | 移行計画書, data and system cutover plan | `migration-plan` |
+| Security | セキュリティ設計書, threat model | `security-design` |
+| API reference | REST API, events, SDK reference | `api-docs` |
+| Development workflow text | PR description, commit message, bug report, feature request | `pr-commit` |
+| Release documentation | Release notes, CHANGELOG | `release-notes` |
+| User guidance | User manual, how-to guide, tutorial | `user-manual` |
+| Source documentation | Code comments, docstrings | `code-comments` |
+| Internal technical proposal | Architecture, investment, and delivery proposal | `technical-proposal` |
+| Request for information | RFI | `rfi` |
+| Request for proposal | RFP | `rfp` |
+| Technical article | Zenn article | `zenn` |
+| Technical article | Qiita article | `qiita` |
+
+Reusable templates are included for README, design decisions, user manuals,
+PR descriptions, requirements definitions, system designs, test plans,
+operations runbooks, migration plans, security designs, technical proposals,
+RFI, and RFP documents. Every supported doctype includes dedicated structure
+guidance and a review checklist under
+`skills/tech-writer/references/doctypes/`.
+
+## What presentation-planner does
+
+- Defines the audience, decision, call to action, and presentation constraints
+- Produces a brief, audience-reasoning scenario, assertion-title slide outline,
+  YAML design specification, and deterministic handoff for the host's PPTX
+  creation skill
+- Includes executive decision, technical briefing, and data report scenario
+  templates
+- Includes executive proposal, technical briefing, and data report design
+  specifications
+- Delegates `.pptx` generation, binary editing, rendering, and visual QA to
+  the dedicated PPTX skill instead of duplicating it
+
 ## Setup
 
 ### Prerequisites
@@ -45,43 +95,54 @@ Japanese prose with natural-japanese.
 
 ### Install from npm
 
-Install the package, then copy `tech-writer` into a skill directory with
-the included CLI:
+Install the package, then copy all packaged skills into a skill directory
+with the included CLI:
 
 ```bash
 npm install --save-dev kotonoha
 npx kotonoha install
 ```
 
-The default destination is `.github/skills/tech-writer` in the current
-project. To install into another supported skill directory, pass its parent
-directory:
+The default destinations are `.github/skills/tech-writer` and
+`.github/skills/presentation-planner` in the current project. To install
+only one skill, or use another supported skill directory:
 
 ```bash
+npx kotonoha install --skill presentation-planner
 npx kotonoha install --target .claude/skills
 npx kotonoha install --target ~/.copilot/skills
 ```
 
-The command refuses to overwrite an existing `tech-writer` directory. Review
-or back up the existing installation, then pass `--force` only when you
-intend to replace it:
+An explicit `--skill <name>` install refuses to overwrite that existing
+skill directory. Review or back up the existing installation, then pass
+`--force` only when you intend to replace the selected skills:
 
 ```bash
 npx kotonoha install --force
 ```
 
+When installing all skills, existing skill directories are skipped and only
+missing skills are added. This makes upgrading from a tech-writer-only
+installation safe:
+
+```bash
+npx kotonoha install
+# Skipped tech-writer (...)
+# Installed presentation-planner (...)
+```
+
 ### Install from a source checkout
 
-Inside this repository, the skill is already placed at
-`.github/skills/tech-writer`, so no extra setup is needed to use it with
-Copilot CLI here.
+Inside this repository, the skills are linked under `.github/skills/`, so no
+extra setup is needed to use them with Copilot CLI here.
 
-To use it in another project, copy the `skills/tech-writer` directory into
-that repository's `.github/skills/`, `.claude/skills/`, or your global
+To use a skill from a source checkout in another project, copy its directory
+into that repository's `.github/skills/`, `.claude/skills/`, or your global
 `~/.copilot/skills/`.
 
 ```bash
 cp -r skills/tech-writer /path/to/your-repo/.github/skills/tech-writer
+cp -r skills/presentation-planner /path/to/your-repo/.github/skills/presentation-planner
 ```
 
 ## Ask Copilot for the document you need
@@ -91,6 +152,10 @@ invoked automatically.
 
 - "Write a README", "Review this design doc", "Write the PR description",
   "Make this how-to guide clearer"
+- "要件定義書を作って", "承認済み要件からシステム設計書を書いて",
+  "移行計画とRunbookを作って"
+- "Create a PPTX from this proposal", "Plan an executive presentation",
+  "Design a technical briefing deck"
 
 To run a quick structure-only diagnostic:
 
@@ -107,10 +172,16 @@ works too (standard library only).
 skills/tech-writer/          # the skill itself
   SKILL.md                   # skill definition
   references/                # structure constitution + doctype rules/checklists
-  references/doctypes/       # README, design doc, API docs, PR/issue, release notes, manual, comments, Qiita/Zenn
+  references/doctypes/       # README, requirements/design/test/operations/migration/security, API docs, PR/issue, release notes, proposals, RFI/RFP, Qiita/Zenn
   scripts/lint.py            # structural lint script
-  assets/templates/          # skeleton templates for the main doctypes
+  assets/templates/          # doctype skeletons including requirements, design, test, operations, migration, security, and procurement
+skills/presentation-planner/ # storyline, design-spec, and PPTX handoff skill
+  SKILL.md
+  references/                # boundary, scenario/design guidance, customization, handoff contract
+  assets/scenario-templates/ # executive, technical, and data-report narrative scenarios
+  assets/design-templates/   # executive, technical, and data-report YAML designs
 .github/skills/tech-writer   # symlink to skills/tech-writer (where Copilot CLI reads it)
+.github/skills/presentation-planner
 ```
 
 ## Known limitations
@@ -121,6 +192,10 @@ skills/tech-writer/          # the skill itself
 - The doctypes are written mainly with Japanese technical-writing
   conventions in mind; most of the guidance (especially the commit-message
   imperative-mood rule) applies directly to English documents as well.
+- `presentation-planner` does not create or validate `.pptx` binaries by
+  itself; a dedicated PPTX skill is required for generation and visual QA.
+- Design customization is documented in
+  `skills/presentation-planner/references/customizing-design-templates.md`.
 
 ## Acknowledgment
 

package/bin/kotonoha.js

@@ -7,11 +7,12 @@ const packageJson = require("../package.json");
 
 function printUsage() {
   console.log(`Usage:
-  kotonoha install [--target <directory>] [--force]
+  kotonoha install [--target <directory>] [--skill <name|all>] [--force]
 
 Options:
   --target <directory>  Skill directory root (default: .github/skills)
-  --force               Replace an existing tech-writer installation
+  --skill <name|all>    Skill to install (default: all)
+  --force               Replace existing selected skill installations
   --help                 Show this help
   --version              Show the installed kotonoha version`);
 }
@@ -23,6 +24,7 @@ function fail(message) {
 
 function parseInstallOptions(args) {
   let target = ".github/skills";
+  let skill = "all";
   let force = false;
 
   for (let index = 0; index < args.length; index += 1) {
@@ -43,6 +45,25 @@ function parseInstallOptions(args) {
       continue;
     }
 
+    if (argument === "--skill") {
+      const value = args[index + 1];
+      if (!value || value.startsWith("--")) {
+        throw new Error("--skill requires a skill name or all");
+      }
+      skill = value;
+      index += 1;
+      continue;
+    }
+
+    if (argument.startsWith("--skill=")) {
+      const value = argument.slice("--skill=".length);
+      if (!value) {
+        throw new Error("--skill requires a skill name or all");
+      }
+      skill = value;
+      continue;
+    }
+
     if (argument.startsWith("--target=")) {
       const value = argument.slice("--target=".length);
       if (!value) {
@@ -55,7 +76,7 @@ function parseInstallOptions(args) {
     throw new Error(`unknown option: ${argument}`);
   }
 
-  return { target, force };
+  return { target, skill, force };
 }
 
 function install(args) {
@@ -67,28 +88,75 @@ function install(args) {
     return;
   }
 
-  const source = path.resolve(__dirname, "..", "skills", "tech-writer");
+  const skillsRoot = path.resolve(__dirname, "..", "skills");
   const targetRoot = path.resolve(process.cwd(), options.target);
-  const destination = path.join(targetRoot, "tech-writer");
 
-  if (!fs.existsSync(source)) {
-    fail(`packaged skill not found at ${source}`);
+  if (!fs.existsSync(skillsRoot)) {
+    fail(`packaged skills not found at ${skillsRoot}`);
     return;
   }
 
-  if (fs.existsSync(destination)) {
-    if (!options.force) {
+  const availableSkills = fs
+    .readdirSync(skillsRoot, { withFileTypes: true })
+    .filter(
+      (entry) =>
+        entry.isDirectory() &&
+        fs.existsSync(path.join(skillsRoot, entry.name, "SKILL.md")),
+    )
+    .map((entry) => entry.name)
+    .sort();
+  const selectedSkills =
+    options.skill === "all" ? availableSkills : [options.skill];
+  const installAll = options.skill === "all";
+
+  for (const skill of selectedSkills) {
+    if (!availableSkills.includes(skill)) {
       fail(
-        `${destination} already exists; rerun with --force to replace it`,
+        `unknown skill: ${skill}; available skills: ${availableSkills.join(", ")}`,
       );
       return;
     }
-    fs.rmSync(destination, { recursive: true, force: true });
+  }
+
+  const existingDestinations = selectedSkills
+    .map((skill) => path.join(targetRoot, skill))
+    .filter((destination) => fs.existsSync(destination));
+
+  if (existingDestinations.length > 0 && !options.force && !installAll) {
+    fail(
+      `${existingDestinations.join(", ")} already exists; rerun with --force to replace selected skills`,
+    );
+    return;
   }
 
   fs.mkdirSync(targetRoot, { recursive: true });
-  fs.cpSync(source, destination, { recursive: true });
-  console.log(`Installed tech-writer to ${destination}`);
+  for (const skill of selectedSkills) {
+    const source = path.join(skillsRoot, skill);
+    const destination = path.join(targetRoot, skill);
+    if (fs.existsSync(destination) && !options.force) {
+      console.log(
+        `Skipped ${skill} (${destination} already exists; use --force to replace)`,
+      );
+      continue;
+    }
+
+    const temporaryDestination = path.join(
+      targetRoot,
+      `.kotonoha-${skill}-${process.pid}-${Date.now()}`,
+    );
+    try {
+      fs.cpSync(source, temporaryDestination, { recursive: true });
+      if (options.force) {
+        fs.rmSync(destination, { recursive: true, force: true });
+      }
+      fs.renameSync(temporaryDestination, destination);
+    } catch (error) {
+      fs.rmSync(temporaryDestination, { recursive: true, force: true });
+      fail(`failed to install ${skill}: ${error.message}`);
+      return;
+    }
+    console.log(`Installed ${skill} to ${destination}`);
+  }
 }
 
 const [command, ...args] = process.argv.slice(2);

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "kotonoha",
-  "version": "0.1.2",
-  "description": "A GitHub Copilot CLI skill for structuring and polishing technical documents.",
+  "version": "0.1.4",
+  "description": "GitHub Copilot CLI skills for technical writing and PPTX presentation planning.",
   "license": "MIT",
   "author": "nahisaho",
   "repository": {
@@ -27,7 +27,11 @@
     "skill",
     "technical-writing",
     "documentation",
-    "markdown"
+    "markdown",
+    "presentation",
+    "pptx",
+    "powerpoint",
+    "slides"
   ],
   "files": [
     "CHANGELOG.md",

package/skills/presentation-planner/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: presentation-planner
+description: >-
+  Plans the content structure and visual design handoff for PowerPoint/PPTX
+  presentations without generating or editing the .pptx file itself. Use for
+  requests like "create a PowerPoint", "make a PPTX", "design a slide deck",
+  "turn this proposal into slides", 「PowerPointを作って」「PPTXを作成して」
+  「提案書をスライドにして」「プレゼン資料の構成を作って」
+  「プレゼンシナリオを作って」. Produces a presentation brief, reusable
+  scenario-based narrative, slide-by-slide outline, design specification,
+  and handoff instructions for the host's dedicated PPTX creation skill. Does
+  NOT implement PPTX generation, python-pptx/PptxGenJS code, binary editing,
+  rendering, thumbnail creation, or visual-overlap inspection; those remain
+  the responsibility of the dedicated PPTX skill. Does NOT handle simple
+  edits to an existing deck, single-slide changes, or direct generation when
+  the storyline and design are already settled; use the dedicated PPTX skill
+  directly for those requests.
+license: MIT
+argument-hint: "[plan|review] <presentation request or source files>"
+---
+
+# presentation-planner
+
+Plans what a presentation must communicate, how the story progresses, and
+which visual system the PPTX renderer must apply. The output is a complete
+handoff package for a dedicated PPTX creation skill, not a `.pptx` file.
+
+## Responsibility boundary
+
+Read `references/responsibility-boundary.md` before acting. This skill owns:
+
+- Audience, objective, decision, and call-to-action definition
+- Scenario selection, audience reasoning journey, and slide ordering
+- One-message-per-slide content architecture
+- Evidence and source mapping
+- Selection and adaptation of a packaged design specification
+- A deterministic handoff contract for the host's PPTX skill
+
+This skill must not:
+
+- Create, edit, unzip, or inspect `.pptx` binaries
+- Write PowerPoint generation code using python-pptx, PptxGenJS, COM, or
+  similar libraries
+- Render slides, create thumbnails, or detect visual overlap
+- Reimplement layout or visual QA tooling supplied by the host's PPTX skill
+
+When the host provides a registered `pptx` or PowerPoint creation skill,
+delegate binary generation and visual QA to it. If no such skill is
+available, still produce the five planning artifacts and report
+`PPTX generation not performed`; do not silently implement a renderer.
+
+## Execution modes
+
+- `plan` (default): gather context, produce the five handoff artifacts, and
+  delegate generation when a PPTX skill is available.
+- `review`: review existing brief, scenario, outline, and design spec for
+  audience fit, storyline gaps, evidence gaps, and handoff ambiguity. Do not
+  inspect the binary presentation.
+
+## 0. Route direct PPTX operations away
+
+Before intake, skip this skill and use the dedicated PPTX skill directly
+when any of the following is true:
+
+- The request is a mechanical edit to an existing deck
+- Only one slide, title, image, note, or formatting property must change
+- The user supplied a final scenario, slide outline, and design with no
+  request to restructure them
+- The task is only binary generation, rendering, conversion, or visual QA
+
+Use `presentation-planner` when the audience, storyline, evidence,
+slide sequence, or visual system still needs design.
+
+## 1. Gather context one question at a time
+
+Ask only the single most informative missing question, then wait. Stop once
+the following are known:
+
+1. Target audience and what they already know
+2. The decision, action, or understanding the presentation must produce
+3. Presentation setting: meeting type, speaking time, and target slide count
+4. Source material and evidence that may be cited
+5. Required language, aspect ratio, brand rules, and accessibility needs
+6. Whether an existing `.pptx` or brand template must be reused
+
+If an existing `.pptx` must be reused, ask the host's PPTX skill to inspect
+its theme and layouts. Consume the returned design summary; do not inspect
+the binary in this skill.
+
+## 2. Choose a packaged design specification
+
+Choose the closest design under `assets/design-templates/`:
+
+| Design | Use when | Avoid when |
+|---|---|---|
+| `executive-proposal.yaml` | Approval, investment, roadmap, or executive decision | Dense technical training |
+| `technical-briefing.yaml` | Architecture, engineering explanation, technical proposal | Primarily financial reporting |
+| `data-report.yaml` | KPI review, research findings, operational or analytical reporting | Slides without credible data |
+
+Read `references/design-spec-schema.md` and adapt the selected design into
+the presentation's `design-spec.yaml`. Preserve the schema keys so the PPTX
+skill can consume it predictably.
+
+For project-specific changes or new reusable templates, follow
+`references/customizing-design-templates.md`.
+
+## 3. Build the storyline before slide content
+
+Read `references/scenario-templates.md`, then choose the closest scenario
+under `assets/scenario-templates/`:
+
+| Scenario | Use when |
+|---|---|
+| `executive-decision.md` | Approval, investment, roadmap, policy, or option selection |
+| `technical-briefing.md` | Architecture, engineering behavior, or technical review |
+| `data-report.md` | KPI, research, experiment, survey, or operational analysis |
+
+Copy and adapt it into `presentation-scenario.md`. Use the shortest storyline
+that gets the audience to the intended outcome. The selected template's
+scenario arc is authoritative; keep its stage names unless the adaptation
+records why a stage is removed, merged, or renamed.
+
+When none of the packaged templates fits, use this generic fallback:
+
+1. **Context**: why the audience should care now
+2. **Tension**: the problem, gap, risk, or opportunity
+3. **Evidence**: facts that establish scale and credibility
+4. **Resolution**: the proposed answer or interpretation
+5. **Plan**: actions, owners, cost, timing, and controls
+6. **Decision**: the exact approval, action, or next step
+
+Remove a stage when it adds no decision value. Do not add agenda, section
+divider, or summary slides merely to increase slide count.
+
+## 4. Produce the five handoff artifacts
+
+Write the artifacts under `.presentation/<deck-slug>/` unless the user
+specifies another directory. Derive a stable, filesystem-safe slug from the
+presentation title so multiple decks do not overwrite each other.
+
+### `presentation-brief.md`
+
+Include:
+
+- Working title and one-sentence purpose
+- Audience and prior-knowledge floor
+- Decision or call to action
+- Setting, duration, slide count, language, and aspect ratio
+- Source files and citation expectations
+- Constraints, non-goals, and known unknowns
+- Selected design template and reason
+
+### `presentation-scenario.md`
+
+Copy and adapt one packaged scenario template. If no packaged template fits,
+write the generic fallback arc from §3 into this file using the same fields:
+stage, audience question, assertion, required evidence, transition, and
+suggested slide range. Include:
+
+- Current and intended audience position
+- One assertion and audience question per scenario stage
+- Required evidence, source status, and assumptions
+- The transition that makes the next stage relevant
+- Likely objections, uncertainty, and trade-offs
+- The exact final decision, action, or understanding
+
+The scenario defines the reasoning journey, not individual slide content.
+
+### `slide-outline.md`
+
+Use one row per slide:
+
+| # | Scenario stage(s) | Assertion title | Audience takeaway | Evidence/source | Visual form | Speaker note purpose |
+|---:|---|---|---|---|---|---|
+
+Rules:
+
+- Titles state the slide's conclusion, not its topic
+- Each slide has one primary message
+- Every slide maps to at least one scenario stage; separate multiple stage
+  names with ` / `
+- Evidence is traceable to a source or marked as an assumption
+- Visual form is specific: comparison table, timeline, architecture diagram,
+  annotated chart, process, quote, or full-bleed image
+- A slide must earn its place by advancing the decision or outcome
+
+### `design-spec.yaml`
+
+Copy and adapt one packaged design specification. Set `base_template` to the
+packaged template ID and change `id` to a unique value such as
+`<deck-slug>:<base-template>`. Resolve its placeholders, then record any
+deliberate deviation in a `deviations` list.
+
+### `pptx-handoff.md`
+
+Follow `references/handoff-contract.md`. It must tell the PPTX skill:
+
+- Exact input artifact paths
+- Exact output `.pptx` path
+- Required design template and deviations
+- Slide count and aspect ratio
+- Source and citation rules
+- Required speaker notes and accessibility behavior
+- Binary-generation and visual-QA acceptance checks
+
+## 5. Validate the planning package
+
+Before handoff, verify:
+
+- Reading only assertion titles reproduces the full argument
+- Reading only scenario-stage assertions reproduces the audience journey
+- Every slide maps to at least one stage without introducing an unsupported
+  conclusion
+- The final slide asks for the exact intended decision or action
+- Every factual or quantitative claim has a source or assumption marker
+- No slide has more than one primary message
+- Visual forms vary with the information instead of repeating one layout
+- The design spec contains all required schema keys
+- The handoff assigns all binary and visual checks to the PPTX skill
+
+Use an independent `rubber-duck` reviewer when available. Fix actionable
+findings and repeat for at most five rounds. A round is clean when no
+unaddressed correctness, storyline, evidence, design, or handoff findings
+remain. If the reviewer is unavailable, report `review not performed`. If
+five rounds end with actionable findings, report `review did not converge`
+with the unresolved findings and attempted fixes.
+
+## 6. Delegate PPTX creation
+
+Pass the five artifact paths to the host's dedicated PPTX skill. The PPTX
+skill may choose its own implementation library, but it must preserve the
+approved storyline and design tokens unless it reports a concrete rendering
+constraint.
+
+After generation, require the PPTX skill to report:
+
+- Output file path and slide count
+- Render/thumbnail review result
+- Overlap, clipping, contrast, and font-substitution checks
+- Missing assets or unsupported design instructions
+- Any deviation from `slide-outline.md` or `design-spec.yaml`
+
+Do not claim a presentation is complete from this planning skill alone.