Scalar Ae Materials

---
name: scalar-ae-materials
description: >-
  Build what a Scalar Account Executive needs for one customer visit, chosen
  by deal phase and audience: the customer-facing one-pager, the internal
  visit plan, the WPS win plan, and the Deal Desk approval packet.
  Use for: 訪問・面談の準備, フェーズ 0〜6 の会話に使う資料, visit plan, WPS,
  Deal Desk, 社内の承認やリソースを取りたい.
  Not: the standing activity plan (scalar-account-plan); the formal proposal
  (scalar-proposal-slides); the stakeholder maps (b2b-account-maps).
---

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

# Scalar AE Materials

Use `references/scalar/workflow-contract.md` for shared safety, Drive,
approval, and QA rules. This skill owns only the routing and content rules for
a single visit or internal approval artifact.

**The same deal information must never be shown to everyone through a single
document.** This skill's job is to choose the material type from phase
(0–6) × audience (customer / internal) × purpose, and to build only a
document that satisfies that type's required content.

Working directory: the slide-forge root. Run commands with `.venv/bin/python`.

The source of truth for these decisions is
[references/scalar/sales-playbook.md](../../references/scalar/sales-playbook.md)
(phases and transition conditions in §2, the 5 material types in §3, quality
standards in §4, meeting bodies in §6).

## Boundaries

| Request | Where it goes |
|---|---|
| A full set of materials for one visit | This skill |
| Internal approval / resource acquisition (WPS / Deal Desk / internal approval) | This skill |
| Per-customer activity plan (standing, append-only) | `scalar-account-plan` |
| Annual Account Planning Session (org chart / deal review deck) | `scalar-account-planning-session` |
| Formal proposal / quotation | `scalar-proposal-slides` + `spreadsheets` |
| Stakeholder map / discovery map | `b2b-account-maps` |
| Organise minutes / email into per-stage records | `scalar-deal-intake` |
| Scalar company/product introduction (not customer-specific) | `scalar-product-slides` |
| Visual inspection of a generated deck | `slide-qa` |

## Step 1: Settle the phase and the audience

**Read the ledger first.** If `accounts/<AE name>/<customer name>/account.json`
exists, the phase, stakeholders, and open items are in it. If it doesn't
exist, create it with Steps 1–2 of `scalar-account-plan`.

```bash
.venv/bin/python scripts/scalar/account_ledger.py validate <account.json>
.venv/bin/python scripts/scalar/account_ledger.py gaps <account.json>
```

Ask only about premises that cannot be pulled from the ledger, in one batch
via `AskUserQuestion` (following the conventions in
`references/interactive-intake.md` §0 and §5):

1. Who will you meet (title / department / first time)?
2. What one statement do you want to get from the customer in this visit?
3. Is there anything you want internally (approval of proposal investment /
   price approval / SA staffing)?

The shared workflow contract settles the QA choice; do not repeat it in this
skill's audience-specific question batch.

## Step 2: Choose the material type (routing)

| Audience / purpose | Phase | What to build | Location | Owner |
|---|---|---|---|---|
| Internal / pre-visit preparation | All | `visit-plan` | `90_社内` | This skill |
| Customer / start a conversation | 0–2 | `challenge-hypothesis` + case study | `01_顧客提示` | This skill |
| Customer / structure the challenge | 2 | Challenge structure diagram, As-Is overview, discussion points | `01_顧客提示` | This skill |
| Internal / decide on proposal investment (WPS) | End of 2 | `win-plan` + 3 maps | `90_社内` | This skill + `b2b-account-maps` |
| Customer / show feasibility | 3 | Demo materials, To-Be, architecture overview | `01_顧客提示` | `scalar-proposal-slides` |
| Customer / agree on a PoC | 3 | PoC proposal, implementation plan | `02_顧客提案` | `scalar-proposal-slides` |
| Internal / approve pricing and contract risk | 3–5 | Deal Desk materials, internal approval | `90_社内` | This skill |
| Customer / selection and budgeting | 4 | Formal proposal, quotation, ROI (`license-pattern-compare` + `license-estimate` for the licence pages) | `02_顧客提案` | `scalar-proposal-slides` + `spreadsheets` |
| Customer / contract procedures | 5 | Checklist, SOW, purchase order | `02_顧客提案` | `google-slides-template` |
| Internal / renewal and expansion planning | 6 | Health review, renewal plan | `90_社内` | `scalar-account-plan` |

Partner-facing / partner-proposal materials (the remaining 2 types in
playbook §3) have **no dedicated template implemented**. If requested, build
them with `google-slides-template`; pull the required items from playbook §3
and the source material §7.5.

Ask `AskUserQuestion` once, and only when you cannot decide. If the phase is
in the ledger and the audience is specified, decide without asking.

## Step 3: Check that customer-facing material isn't mixed with internal information (do not skip)

**Before** generating material to hand to the customer (`01_顧客提示` /
`02_顧客提案`), read the spec body and confirm the following:

- [ ] No judgments about an individual's influence, position, or "not yet
  contacted" status are included
- [ ] No competitor weaknesses are named (assume the customer will pass this
  along to the competitor)
- [ ] No unconfirmed item is written as if it were confirmed
  → Rephrase it as "would like to confirm today." Do not fill it in with a guess
- [ ] No figure without a source is included (cite sources for public case studies)
- [ ] Pricing / roadmap information is within what is allowed to be disclosed —
      the figures on `license-estimate` / `license-pattern-compare` are
      transcribed from a generated quotation (`scalar-quotation`), and their
      edition contents, Pod counting, and billing model come from the OKF
      bundle (`references/scalar/okf-bundle.md`). The bundle's list prices are
      published and citable as 定価 (tax-excluded) reference-estimate material,
      but 3-year terms, prepaid credits, and discount rates are 非公開 there —
      never put those on a customer page
  to this audience

The `challenge-hypothesis` guardrails say the same thing. If even one item
applies, move that content into a `90_社内` document instead.

## Step 4: Write the spec and validate it offline

Build pages that can be built from the ledger, from the ledger (don't
hand-copy):

```bash
.venv/bin/python scripts/scalar/account_ledger.py slots <account.json> visit-plan \
    --out out/<顧客名>/visit-plan.json
.venv/bin/python scripts/render_slide_template.py --template visit-plan \
    --data out/<顧客名>/visit-plan.json --out out/<顧客名>/visit-plan.slide.json
```

`visit-plan` is built from the `visits[]` entries in the ledger whose
`status` is `"planned"`. Write the visit's purpose, questions, and expected
objections into the ledger first, and the material follows from the ledger.

Customer-facing case pages use the `case-studies` pack (`case-study-card` /
`case-study-detail` / `case-fit`). **Publication consent and the dated source
live in `templates/marketing/case-study.ja.md`**; a case whose consent is
未取得 does not go in front of a customer.

Other pages not in the ledger are written from a
`slide-templates` template or a pattern from
`references/slide-pattern-catalog.md` — 20KB, so open only the section for the
page family you need (§2 structural, §3 quantitative, §4 comparison, §5 logic,
§6 planning, §8 qualitative, §9 closing). Assemble and validate:

```bash
.venv/bin/python scripts/assemble_spec.py out/<顧客名>/*.slide.json \
    --out out/<顧客名>/deck.json --title "<資料名>"
.venv/bin/python scripts/build_deck.py --template templates/scalar-2026.json \
    --spec out/<顧客名>/deck.json --dry-run --strict
```

If findings come back, **fix the data** (shorten the wording, separate
people). Don't fix the template.

## Step 5: Generate and place it in the correct folder

```bash
.venv/bin/python scripts/scalar/account_workspace.py ensure --ledger <account.json> --json
```

From the returned IDs, choose `--folder` per the Step 2 location table:

| Type | Folder |
|---|---|
| Customer-facing | `01_顧客提示` |
| Customer proposal | `02_顧客提案` |
| Internal explanation | `90_社内` |
| Activity plan | `00_活動計画` |

```bash
.venv/bin/python scripts/build_deck.py --template templates/scalar-2026.json \
    --spec out/<顧客名>/deck.json --folder <フォルダ ID>
.venv/bin/python scripts/drive_folder.py upload <フォルダ ID> out/<顧客名>/deck.json
```

**Never place it in the wrong folder.** If an internal document ends up in
`01_顧客提示`, an individual's private judgments go straight to the customer
when the folder is shared.

## Step 6: Material-specific QA

Apply the shared QA procedure. For customer-facing material, repeat the Step 3
leakage check against the rendered thumbnails.

## Step 7: Write back to the ledger (do not skip)

**Don't stop at making the visit materials.** Write back what you made and
what was decided in it to the ledger, and update the activity plan. This is
the only mechanism that keeps the visit materials and the activity plan from
drifting apart.

1. Add this visit to `visits[]` (`status: "planned"` before the visit;
   `status: "done"` with `heard` / `next` filled in after it happens)
2. Add newly learned facts to `facts[]`, tagged with `kind`
3. Record any gates that were satisfied in `gates`, **with evidence from the
   customer side**
4. Turn open items into actions with Steps 4–5 of `scalar-account-plan`, and
   replace the activity plan

```bash
.venv/bin/python scripts/scalar/build_account_plan.py <account.json> --carry-over
```

## Step 8: Report

1. The name, type, deck URL, and Drive folder of each material produced
2. For customer-facing material: confirmation that the Step 3 check was
   passed, and which items were moved out for being internal
3. The QA result (or that it was not performed)
4. **The AE's action plan** — who, what, by when, and what completion looks
   like (`out/account-plan/<customer name>/action-plan.md`)
5. For material requesting internal approval: **what decision is being
   asked for**, in one line (continue / hold / withdraw, discount cost,
   staffing required)

## Rules

- **Never mistake the audience.** The material type is determined by the
  reader. When in doubt, default to internal.
- **Stage advances on customer agreement, not on activity volume.** Do not
  treat "we explained it" or "we handed over a document" as grounds for
  advancing the stage (playbook §1, principle 5).
- **Never skip WHAT/WHY.** Don't produce material that answers the
  customer's requirements with HOW alone.
- **Never fill gaps with guesses.** Present unconfirmed items as "would like
  to confirm today" in the material.
- **Back every figure with a source.** Don't include a number you can't cite
  a source for.
- Don't leave a previous customer's name, amount, structure, or notes behind
  from an old template (playbook §4).
- Do not commit `accounts/` or `config/`. Keep working files under `out/`.