日本語

Scalar Product Introduction Slides

Use references/scalar/workflow-contract.md for shared sales-material rules and references/scalar/research-policy.md for research. This skill owns only product-deck-specific decisions and generation.

Working directory: the slide-forge root — ${CLAUDE_PLUGIN_ROOT} when running from an installed plugin, /path/to/slide-forge on a local clone (literal cd paths below assume the local clone).

Product-deck rules

• Use google-slides-template only for template-specific implementation details activated by this deck; shared auth, Drive, approval, and QA behavior comes from the two workflow contracts above.
• Product facts come from the OKF bundle. Capability, edition, version, release status, and pricing are looked up in the OKF bundle before any web research — references/scalar/okf-bundle.md says where it is and how to cite it (one version at a time, edition always stated, preview status labelled). Its pricing/ figures are published list prices: citable as 定価 (tax-excluded) and as reference-estimate material, never as a confirmed price.
• Research facts before writing them. Company info, versions, and case studies start from references/scalar/research-2026-08.md, but re-research if more than 3 months have passed since the research date (Phase 2 below). Never fill gaps with guesses. Omit items you cannot confirm (e.g. capital stock).

Quick Reference

Both scripts accept two CLI flags: --folder <Drive folder URL> (optional; when omitted the deck is created directly in My Drive) and --dry-run (validate offline without calling the API).

Phase 1: Settle the deck type and premises interactively

Decide before researching. Picking the wrong deck type means redoing the research (a company intro and a feature catalog need different facts). Follow references/interactive-intake.md — sections 0 (when to ask), 3 (outline approval gate), 4 (post-generation confirmation), and 5 (how not to ask). Ask everything in one batch; do not go back and forth one question at a time.

Question set (specific to this skill; ask all 4 questions of Q1 in one round):

• Never decide Q4 on your own. If more than 3 months have passed since the research date, put "Re-research" first as the recommended option and state the reason (research date and months elapsed) in the description.
• These 4 questions fill one round. If unspecified, ask for the output Drive folder, cover date, and language (Japanese / English) together in a second round. The shared contract owns the QA question.
• Do not ask about: how diagrams are composed, coordinates, colors, or which diagram each feature gets. Those are fixed by FEATURES_DB / FEATURES_DL and the design conventions.

Once the type and target are settled, present the slide outline (page count and each slide's heading) and get approval before generating. Pass this gate before rewriting build_plan().

Phase 2: Research

Read references/scalar/research-2026-08.md; if it is fresh enough, use it as is. If information needs refreshing, apply research-policy.md: check changes first, use one researcher for a small update, and split into non-overlapping scopes only when multiple areas genuinely need fresh evidence:

1. Company info and news: https://scalar-labs.com/ja/ (company / news), press release searches
2. Product technology: https://developers.scalar-labs.com/ → the actual docs live at https://scalardb.scalar-labs.com/docs/latest/ and https://scalardl.scalar-labs.com/docs/latest/ (start from features / overview / design / releases, then follow individual feature pages)
3. Use cases and case studies: the case-study category of the news feed plus web search (there is no dedicated case-study page)

Give researchers only their source boundary and the compact return schema from the policy—not this full skill. Cite source URLs, mark unknowns explicitly, never guess, and update the dated research cache. Check the pitfall list (at the end of the references file) before turning anything into slides, every time.

Phase 3: How to build each deck type

The type was settled in Phase 1. These are implementation notes for building it.

A. Company intro deck (scripts/scalar/build_scalar_intro.py)

Copies templates/scalar-2026-boilerplate.json with keep_existing=True and keeps the official boilerplate slides (company overview VISION, executive team, product overview, customer logos, the Toyota / broadcaster case studies, closing), inserting research-based generated slides among them. Executive photos and customer logos cannot be reproduced, so always use this approach.

• Of the 12 bundled slides, delete the placeholder cover (position 1) and the sub-section heading (position 10)
• Replace the cover wording via replaceAllText ("<Presentation Title>" etc.)
• Insert generated slides with add_slide(..., index=final position). Declare the final page order in a single list (build_plan()) and insert in ascending order — that keeps the insertionIndex arithmetic trivial
• Page numbers: SLIDE_NUMBER on the bundled slides tracks automatically. For generated slides, draw the final-position number with draw_page_number() (the single-slide variant). Do not use add_page_numbers() — it assumes consecutive numbering and does not mix well with the insertion approach

B. Feature catalog deck (scripts/scalar/build_scalar_features.py)

A "1 feature = 1 slide" catalog generated from templates/scalar-2026.json. All feature slides share one layout:

• Left (x 0.5–5.75): diagram (a per-feature fig_* function) plus a one-line caption at the bottom edge
• Right (x 6.0–9.5): feature overview card (≤ 200 chars as a guideline)
• Bottom: use cases row (bullets in 2 columns, each ≤ 28 chars as a guideline) plus a key strengths band (≤ 100 chars as a guideline)
• Top right: edition, introduced-in version, preview status
• Speaker notes: source URLs and limitations

Feature data lives in the FEATURES_DB / FEATURES_DL lists of dicts (title / figure / overview / usecases / value / edition / notes). Edit these to add, remove, or reword features. Each section opens with a 2×2 feature map.

Design conventions (both approaches)

• Rectangles that carry a straight accent bar must not have rounded corners (RECTANGLE). Chips and bands without a bar may be rounded (same rule as the google-slides-template SKILL.md)
• Titles are action titles ("what can we claim"). The form "Feature name — one-line value" fits well
• Compose diagrams from the illustrations pictograms, _pill (rounded chips), cloud_zone, and d.node() boxes. Official cloud icons must not be modified
• Arrows join boxes, never icons or captions, and never by typed coordinates. Put each thing an arrow touches in a d.node() (picture + label in a box) or a shape, and join them with d.vlink() / d.hlink() / d.elbow() (references/diagrams.md "Lines connecting shapes"). Several boxes into one wide band: one vlink() per box, so the arrows stay parallel. audit_connectors() reports any arrow end more than 0.08in off a box edge — fix the figure, do not loosen the check

Phase 4: Generate and QA

cd /path/to/slide-forge
.venv/bin/python scripts/scalar/build_scalar_features.py --dry-run   # audits only, no API
.venv/bin/python scripts/scalar/build_scalar_features.py [--folder <URL>]

1. Before committing, the scripts run audit_bounds / audit_connectors / audit_overlaps / audit_text_fit on every slide and print "audit:" lines ("検査:" with GSLIDES_LANG=ja). If any audit fires, fix the spec and rebuild (faster than patching). Delete the old deck from Drive before rebuilding
2. Apply the shared contract's selected QA and cleanup procedure.
3. Rebuilding changes the URL. Tell the user the new URL and be explicit about what happens to the old deck (deletion)
4. Use the shared contract's final-adjustment choices before handoff.

File layout

The scripts are "worked examples you can re-run as is"; when changing the structure, editing these two scripts is the shortest path. The architecture diagram examples examples/scalardb-architecture.py / examples/scalardl-architecture.py (from google-slides-template) can be used alongside them.