日本語

Scalar Solution Proposal Slides

Use references/scalar/workflow-contract.md for shared sales-material rules and references/scalar/research-policy.md for freshness/research. This skill owns only proposal-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).

Important

• Prerequisite skill: google-slides-template (same repo) — auth, the shared venv, the scalar-2026 template, drawing API, and QA tooling. This skill owns only what is proposal-specific: the hearing checklist, the challenge→product mapping, and the proposal deck structure.
• The customer's challenges drive everything. A proposal without agreed challenges is a product intro — route it to scalar-product-slides. Collect hearing material (minutes, notes, RFP) before designing slides; what is not known must surface as "to confirm today" on the deck, never as a guess.
• Never fabricate customer-specific numbers. Quantified effects need a calculation basis from the hearing; otherwise write qualitative effects and route quantification to the PoC ("measure it during the PoC and use it as material for internal approval"). Public case numbers (ENS approx. 1/5, etc.) are usable with sources.
• Every initial proposal includes an architecture diagram and a BOM. The standard topology is 3 environments — development (local) / test (aidd-infra-test) / staging (aidd-infra-staging) — on AWS by default (rebuild the same role split on GCP/Azure only if the customer specifies). After composing the architecture, output the cloud-service list and the Scalar product list with quantities (and monthly license cost when quantities are not specified) — on the deck AND as a list in the final report (proposal-map.md §6).
• Check the constraints before proposing — references/scalar/proposal-map.md §4 (cases where ScalarDB/DL does not fit). Do not force a challenge onto a Scalar product; saying so is part of proposal quality.
• Product facts and prices come from the OKF bundle — references/scalar/okf-bundle.md tells you where it is and how to cite it. Capability, edition, version, release status, billing model, list price, and Pod counting are looked up there, never written from memory. The bundle is a public repository, so its figures are citable — label them 定価 (tax-excluded) and treat them as reference-estimate material, with the AE reviewing any quote that goes to the customer. What it marks 非公開 (3-year terms, prepaid credits, discounts) routes to the AE instead.
• Research freshness: facts come from references/scalar/research-2026-08.md and references/scalar/proposal-map.md (§3/§5 dated 2026-08-05). Both follow the 3-month rule — refresh only affected claims using references/scalar/research-policy.md; parallel research is not automatic.

Quick Reference

Phase 1: Collect the challenges and settle premises

Follow references/interactive-intake.md sections 0/3/4/5. Ask in one batch:

• Material first: if minutes/notes exist, read them before asking Q2 and pre-select the likely categories in the option descriptions.
• If nothing is known yet, hand over the hearing forms as the deliverable instead of forcing a deck — templates/sales/hearing-sheet.ja.md plus templates/sales/products/scalar.ja.md (what each section feeds in the deck is in the sheet's §14.3; the checklist behind them is proposal-map.md §1).
• If a filled-in hearing sheet exists, read it first: §4.2 / §5 give the current-state diagram and the BOM quantities, and the product addendum's §B / §C give the constraints that must appear on the risk slide. When it is kept as hearing.json, run hearing_sheet.py gaps before designing — what is still 未確認 becomes "to confirm today" on the deck, never a guess, and what is 推定 is stated as our reading rather than as fact.
• Second round if unspecified: output Drive folder, cover date, language, and cloud (default AWS — state the adopted default instead of asking when the customer's cloud is unknown). The shared contract owns the QA question.
• Do not ask about diagram composition, coordinates, colors, or which part draws which section — that is fixed by the worked example and design conventions.

Then present the slide outline (page count + each slide's action title, challenge→product mapping made explicit) and get approval before generating (the outline gate of interactive-intake.md §3).

Phase 2: Map challenges to products

1. Classify each agreed challenge into proposal-map.md §3 categories (A–H); pull the product/feature line and the public cases from the same row.
2. Check §4 (unsuitable cases) — direct-write bypass, DB-specific features, OLAP-only workloads, "tamper prevention" wording, Community-edition gaps. Surface any hit as a risk-slide item or descope it honestly.
3. Verify freshness (3-month rule) of §3/§5 and research-2026-08.md; re-run research agents if stale, and check the pitfall list at the end of research-2026-08.md before writing slides.

Phase 2.5: Compose the architecture and BOM

1. Start from the standard 3-environment topology (proposal-map.md §6): development (local, Community edition, free) → test aidd-infra-test (Cluster, 1 Pod) → staging aidd-infra-staging (Cluster, 3 Pods), AWS by default. Adjust environment names, sizes, and the production environment to the hearing.
2. Author the diagram from examples/scalar-proposal-envs.drawio (edit → scripts/drawio_export.py → Read the PNG; drawio-diagrams skill rules apply: verified shape names only, visual check mandatory).
3. Derive the BOM: per environment, the cloud services and the Scalar products with quantities; compute monthly license cost with the §6 formula when quantities are not customer-specified. Premium features or ScalarDL change the unit prices (§5/§6).
4. When the customer needs an editable estimate (itemized quotation) — typical for full-rollout proposals, or when the user asks — build it from the BOM with the spreadsheets skill (Excel / Google Spreadsheet, real formulas for quantities × unit prices and tax) into the deck's Drive folder. The cost slide keeps the summary; the spreadsheet carries the line items, and the two totals must match.

Section pages that used to exist only inside the builder now have registered templates — reach for these instead of re-drawing figures by hand:

A case page needs the customer's publication consent and a dated source — templates/marketing/case-study.ja.md §1 and §3 own both. Do not put a case on a customer page while consent is 未取得.

Phase 3: Build the deck

scripts/scalar/build_scalar_proposal.py is a worked example (fictional manufacturing scenario, 23 slides incl. architecture + BOM) that encodes the standard structure — proposal-map.md §2 has the section-by-section rationale. To build a real proposal, rewrite only the PROPOSAL dict at the top of the script (customer, summary, challenges, mapping, alternatives, effects, cases, journey, gantt, team, costs, risks, next) with hearing results, keeping:

• Challenge slides ≤ 3 items, same order and wording as the mapping table
• The alternatives table's comparison axes rewritten to the customer's actual KBF (what they will evaluate proposals on)
• Cases picked from the mapped categories (§3), with sources in speaker notes
• Cost figures only from §5 with source_note; anything else stays "quote available on request"
• Dense architecture diagrams (10+ nodes, cloud-specific) → author with the drawio-diagrams skill and insert as an image instead of the built-in solution diagram

Design conventions are shared with scalar-product-slides: action titles, square corners on accent-bar cards, pictograms from illustrations.

Phase 4: Generate and QA

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

1. The script prints "audit:" lines from audit_* on every drawn slide. If any audit fires, fix the data/spec and rebuild (delete the old deck from Drive first; rebuilding changes the URL — tell the user).
2. Apply the shared contract's QA and cleanup procedure.
3. Content QA specific to proposals: no customer-specific number without a hearing basis, no case/price without a source note, challenge wording consistent across slides 3 / 7 (challenge summary and mapping table), scope-out line present.
4. In the final report, alongside the deck/folder URLs, include the BOM lists (cloud services per environment; Scalar products with quantity and monthly cost) — the builder prints them as === Bill of Materials (BOM) ===.
5. Use the shared contract's final-adjustment step, adding proposal-specific choices for swapping cases or adding/removing sections.

File layout