日本語

Hearing Sheet I/O

Read references/hearing-kit.md first — the record, the merge rule, the customer filter and the command list are all there, and this skill does not restate them. This file owns only the workflow and the decisions.

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

Boundaries

Step 1: Find or start the record

ls accounts/<AE>/<customer>/stages/hearing.json

If it is missing, start it from the blank form — and from the product addendum when a product is already in play:

.venv/bin/python scripts/hearing/hearing_sheet.py init \
    templates/sales/hearing-sheet.ja.md \
    --out accounts/<AE>/<customer>/stages/hearing.json --product scalar

Do not start a second record for the same deal. One deal, one hearing.json, one Google Spreadsheet link.

If a filled-in Markdown sheet already exists from before this skill, init from that file instead of the blank template — the answers come across, and the IDs are assigned then.

Step 2: Decide the surface from who is filling it in

Ask in one batch only what you cannot infer (references/interactive-intake.md §0 and §5):

Decide it yourself when the request already says so. A sheet the customer writes in is a Google Spreadsheet or an Excel file, never Markdown.

.venv/bin/python scripts/hearing/hearing_sheet.py render <json> --format gsheet \
    --audience customer --folder <Drive folder URL>

Put a customer-facing sheet in 01_顧客提示; an internal one stays out of the customer folders entirely (sales-playbook.md §8).

Before handing anything over, run the playbook §3 check by eye. The --audience customer filter removes columns and sections; it cannot tell that a question is phrased in a way you would not want quoted back.

Step 3: Read what came back

cp <json> <json>.baseline-YYYYMMDD          # keep the baseline before rendering
.venv/bin/python scripts/hearing/hearing_sheet.py read <surface|URL> \
    --into <json> --baseline <json>.baseline-YYYYMMDD --dry-run

Run --dry-run first and read the change list. Then drop it to write.

• A conflict stops the merge. Do not reach for --take to make the message go away: look at both values, decide which is true, and say why in the report.
• An ID that is not in the record means a row was added or the ID column was edited. Ask before inventing a question to match it.
• Answers arrive as the customer wrote them. Keep their words in 回答; your reading of them belongs in the stage record, not in this cell.
• Confidence is not raised by an answer appearing. 確認済 needs the customer to have said it or a document to carry it — if you inferred it, it is 推定.

Step 4: Report what is still open

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

Report, in Japanese:

1. What changed, and where it came from
2. What is still 未確認, grouped by section, with who can answer it
3. Anything answered as 推定 — these are what hypothesis-check will confirm
4. Conflicts, with both values and no resolution invented
5. What the gaps block downstream — §4.2 and §5 gate the architecture diagram and the BOM in scalar-proposal-slides; §14.3 maps each section to the proposal slide it feeds

Then offer hearing-slides for the questions worth asking in person.

Files