日本語

Hearing Slides — pages that collect

Read references/hearing-kit.md first (record, customer filter, where answers may be stored) and references/scalar/workflow-contract.md for the shared generation, QA and delivery rules. This skill does not restate either.

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

What makes these pages different

A proposal page asserts. These pages leave a hole and ask the customer to fill it. The hole is real — it comes from hearing.json, where the answer is still 未確認 or 推定.

• Never fill a hole with a guess to make the page look finished. A builder that has no material refuses to build the page (exit 2); take that as the answer, not as an error to work around.
• Everything here is customer-facing, so it is built only from what survives the customer filter. Internal sections and the source/confidence columns never reach a slide.
• Say what the customer gets back. Collecting without returning anything teaches people not to answer next time.

Boundaries

discovery-gaps and this skill's hearing-agenda look similar and are not. discovery-gaps is internal: it assigns each gap to a counterpart and a date. hearing-agenda is shown to the customer and asks them directly. Do not put one in the other's folder.

The pages

Step 1: See what is actually open

.venv/bin/python scripts/hearing/hearing_sheet.py gaps <hearing.json> [--section 4]

Choose pages from what is there, not from the list above:

• Nothing 推定 → no hypothesis-check. There is no understanding to correct yet, and inventing one to fill the page is the exact failure this skill exists to prevent.
• Fewer than three 未確認 → the sheet is nearly done; a whole deck of asking is the wrong artifact. Say so and offer the one page that fits.
• More than one section open → ask with --section rather than mixing an infrastructure question into a budget page.

Step 2: Build the data, then the pages

.venv/bin/python scripts/hearing/hearing_slots.py <hearing.json> hearing-agenda \
    --out out/<customer>/agenda.json --section 4
.venv/bin/python scripts/render_slide_template.py --template hearing-agenda \
    --data out/<customer>/agenda.json --out out/<customer>/agenda.slide.json

The generated wording is a starting point, not the deliverable. Rewrite title and lead to the customer's own situation and vocabulary before assembling — a page that reads as a form letter gets form-letter answers.

For a QR page, make the image first and check where it points:

.venv/bin/python scripts/hearing/qr.py "<answer URL>" --out out/<customer>/qr.png

Without qrcode installed this writes a clearly marked placeholder and exits 2. Do not put the placeholder in front of a customer — either install qrcode[pil] or use collect-cta, which carries the URL as text.

Step 3: Assemble, validate, generate

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

Fix the data when the audit fires — shorten the wording, drop a row — never the template. Then generate into 01_顧客提示 (a page that asks the customer is customer-facing material) and follow the shared contract's QA and cleanup.

Step 4: Close the loop

A collection page that never gets read back is decoration. In the report, say:

1. Which pages were built, and which were refused for lack of material
2. What each page is asking for, and which sheet IDs it covers
3. How the answers come back — hearing-sheet's read, with the baseline kept before the sheet went out
4. What is still open after this deck, and who can answer it

Event answers aggregate to type and count before they go anywhere near accounts/_nurture/; anything that identifies a company is a deal, not a segment (references/hearing-kit.md §4).

Files