google-slides-template git:20261015.6a1b38bA

Immutable. This exact content never changes and is served at /api/v1/blob/83c2bc41314529f9.

---
name: google-slides-template
description: >-
  Generate or update a Google Slides deck from a registered master template.
  The main deck-generation workflow — prefer it whenever a corporate master
  exists.
  Use for: テンプレートからデッキを作って, 提案資料を作成して, 既存デッキのこのページを直して,
  make a deck from our template, update slides 3 and 7, register this master.
  Not: a deck with no corporate master (google-slides); designing a new master
  (template-forge); filling only the empty image frames (image-slots).
---

*[日本語](SKILL.ja.md)*

# Google Slides from a template

Claude Code is the primary host for this shared skill. Codex and Antigravity
run the same procedure through their host adapters. Work from the slide-forge
repository root with `.venv/bin/python`.

Read this file completely. Then follow `references/workflow-contract.md`.
Load detailed references only when activated by the routing table below.

## Scope

Use this skill to:

- generate a new deck from a registered template;
- inspect and register a supplied, unregistered master before generation;
- update selected pages of a slide-forge-managed deck from its complete source
  spec, or rebuild all pages when full replacement is explicitly approved.

Use `google-slides` for a deck without a corporate master, `template-forge` to
create a new master design, and `image-slots` when the only task is filling
empty image frames in an existing deck.

## Non-negotiable rules

- Before editing a user-owned deck in place, run
  `.venv/bin/python scripts/snapshot_version.py <URL>` and report the revision.
- For a local fix, use `--into <deck> --update-slides <pages>` after snapshot;
  it preserves every unselected page. Bare `--into` replaces every page and
  requires target/master verification plus explicit full-replacement approval.
- Ask only for missing branch decisions; never ask again for supplied or
  delegated (`your call`) decisions.
- Get explicit approval for page count, layout, and every action title before
  authoring, unless that exact outline was already approved.
- Run strict offline validation before every API write.
- Template decorations, logos, and footers are inherited. Do not redraw them.
- Fix the source spec and regenerate. Do not patch around a source defect only
  in the generated artifact.
- API success is not visual QA. When QA is selected, follow `slide-qa`.
- Keep credentials, tokens, generated fragments, and QA images out of Git.

## Reference routing

Read only the selected row's file or relevant section. Search long references
for the named topic before opening a large range.

| Need | Load |
|---|---|
| Intake questions or final adjustment choices | Applicable sections of `references/interactive-intake.md` |
| Spec fields, placeholders, body roles, image slots | `references/template-schema.md` |
| Canvas, flows, connectors (arrows join boxes: `node()` + `vlink` / `hlink` / `elbow`, never typed coordinates) | Relevant section of `references/diagrams.md` |
| Dense architecture diagram | `drawio-diagrams` skill; then its routed `drawio.md` section |
| Chart/table | Matching component in `references/charts.md` |
| Numbers/charts that follow a spreadsheet | `references/sheets-link.md` (build the model before the spec) |
| Business framework | Matching component in `references/patterns.md` |
| Page skeleton/density | Matching skeleton in `references/slide-patterns.md` |
| Image generation/placement | Matching sections in `references/images.md` |
| Image generation on/off, deliverable destination | `references/settings.md` |
| Scalar or cloud icons | `icons.md` or matching section of `cloud-icons.md` |
| Code sample | `references/code-blocks.md` |
| Outline model | One matching outline in `references/deck-outlines.md` |
| API failure or measured constraint | Search `references/api-notes.md`; use `google-slides-api.md` only if unresolved |
| Large/complex deck | Applicable sections of `references/parallel-generation.md` |
| Visual QA | `slide-qa/SKILL.md` and Gate 2 of `references/validation.md` |

Do not preload catalogs, all Composer guides, all figure-family manuals, or
the complete Google Slides API manual.

## Phase 0: Check the environment

Confirm the repository-local entry point works without exposing secrets:

```bash
.venv/bin/python scripts/list_templates.py
```

Credentials are resolved by `GSLIDES_CONFIG_DIR`, repository `config/`, then
the legacy Claude skill location. Only investigate authentication when a live
operation needs it.

## Phase 1: Settle premises and approve the outline

Determine the template, audience/purpose, page count, outline, density, Drive
folder, QA choice, and relevant delivery formats. Read `config/settings.json`
first (`scripts/settings.py --show`) — it may already settle image generation
and the deliverable destination. Batch only missing decisions into one or two
question rounds. QA defaults to run.

Purpose selects density for `$density` templates:

- proposal, internal review, or handout: `print`;
- projected talk: `presentation`.

Write the chosen density into the deck spec as well (`"density": "print"`, or
`assemble_spec.py --density print`). A print deck lets text fitting shrink
overflowing text down to 8pt — 8, 9 and 10pt read fine on paper — while a
presentation deck stops at 70% of each size.

List registered templates when needed:

```bash
.venv/bin/python scripts/list_templates.py --json
```

Present the proposed page count, layout for every page, and every action title.
Stop for approval. After approval, continue through delivery without another
routine gate.

## Phase 2: Register only when necessary

Skip this phase for an already registered template. For a new URL, inspect and
emit a template definition:

```bash
.venv/bin/python scripts/inspect_template.py <URL> \
  --emit templates/<id>.json --name <id> --thumbnails out/<deck>/layouts
```

Inspect the actual layout thumbnails. Verify title/body roles, decorations,
image slots, and safe areas. Keep any template-provided roles that inspection
verified; do not guess role mappings from names alone.

## Phase 3: Author and validate

Write one spec against the selected `templates/<id>.json`. Use an action title
for every content page. Choose only the figure family needed for each message,
then load its routed reference.

Validate before any API call:

```bash
.venv/bin/python scripts/build_deck.py \
  --template templates/<id>.json --spec out/<deck>/deck.json \
  --dry-run --strict
```

A clean run prints a three-line summary; add `--verbose` only when you need
the per-slide layout list or the full list of fitted text.

Resolve every error. Review warnings and record any intentionally accepted
warning. Ordinary decks up to 17 pages stay in one agent. Consider fan-out at
18–20 pages, or earlier only for independent groups of complex figures. When
splitting, follow `parallel-generation.md`: 2–3 related pages per worker, at
most two named reference sections, self-validation, and findings/path-only
returns.

## Phase 4: Generate and collect sources

Create the Drive folder first, generate once, and upload editable sources:

```bash
.venv/bin/python scripts/drive_folder.py create "<Deck title>"
.venv/bin/python scripts/build_deck.py \
  --template templates/<id>.json --spec out/<deck>/deck.json \
  --title "<Deck title>" --folder "<folder URL or ID>"
.venv/bin/python scripts/drive_folder.py upload \
  "<folder URL or ID>" out/<deck>/deck.json out/<deck>/figures/*
```

If generation fails, remove the partial deck made by this run before retrying.
For a local edit, pass the complete source spec with `--into <deck>
--update-slides 3,7`; strict dry-run, snapshot, template and live-page-count
checks remain mandatory. Selected pages receive new slide IDs. Use bare
`--into` only after explicit approval to replace every page.

## Phase 5: Verify and deliver

When QA was selected, invoke `slide-qa`. Its first pass inspects every page.
After a fix, reinspect only the changed page plus adjacent pages unless a
shared layout, master, theme, footer, or page-number change expands the impact
scope. Clean local QA files at the end.

Run `pptx-export` or `spreadsheets` only against the final verified deck. Make
spreadsheet totals agree with slide summaries. A planning model the deck links
to is the exception — it is built before the spec; after the sheet changes, run
`sync_deck.py <deck>` rather than regenerating.

Report the presentation and Drive-folder URLs; spec/source locations and
optional deliverables; the offline validation result; QA scope, defects fixed,
remaining limitations and cleanup—or that QA was explicitly skipped; and the
final adjustment choices from the relevant intake section.

## Minimal command index

| Task | Command/owner |
|---|---|
| List templates | `scripts/list_templates.py` |
| Check a master is reachable (copy-mode 404s) | `scripts/check_template_access.py [--id <id>]` |
| Inspect/register template | `scripts/inspect_template.py` |
| Validate/generate spec | `scripts/build_deck.py` |
| Snapshot existing deck | `scripts/snapshot_version.py` |
| Create/upload Drive folder | `scripts/drive_folder.py` |
| Assemble fragments | `scripts/assemble_spec.py` |
| Visual QA | `slide-qa` skill |
| Export PowerPoint | `pptx-export` skill |
| Build estimate/BOM | `spreadsheets` skill |
| Linked planning model / carry sheet changes into the deck | `scripts/build_model.py` / `scripts/sync_deck.py` |