/extract-parameters-from-digest

name: extract-parameters-from-digest
description: Use when the user wants to extract parameters from a PlanExe extraction-input digest (the markdown produced by experiments/napkin_math/prepare_extract_input.py — the 137-recommended section bundle, with the four "Keep or compress" sections compressed) instead of the full PlanExe HTML report

Extract Parameters from a PlanExe Extraction-Input Digest

Overview

A drop-in alternative to `extract-parameters-from-full` that reads the digest produced by `prepare_extract_input.py` (see `experiments/napkin_math/prepare_extract_input.py`) rather than the full PlanExe HTML report.

The digest is the 137-recommended extraction bundle in 137's order: Executive Summary, Project Plan, Selected Scenario, Assumptions, Review Plan, Premortem, Expert Criticism, Data Collection. Strategic Decisions is replaced by Selected Scenario per proposal 139.

It mixes two formats:

• **Compressed sections** (Selected Scenario, Review Plan, Premortem,

Expert Criticism) — produced by `compress_report_section`. Bullets carry inline epistemic tags of the form `[<source_status> | e=N r=N | quote: verified|unverified]`.

• **Raw sections** (Executive Summary, Project Plan, Assumptions, Data

Collection) — passed through unchanged from the PlanExe source. No inline tags.

The system prompt at `system-prompt.txt` explains how to read both formats.

Output schema and hard limits are identical to `extract-parameters-from-full`, so the two skills can be compared head-to-head on the same plan.

When to Use

• The user has run `prepare_extract_input.py` against a PlanExe sample and

wants parameters extracted from the resulting digest

• The user is comparing whether this pipeline produces better parameters

than feeding the full HTML report

For plain PlanExe HTML/text reports, use `extract-parameters-from-full` instead.

Workflow

1. **Get the digest path.** Usually `experiments/napkin_math/output/<plan-name>/extract_parameters_input.md`. If the user did not provide one, ask. Do not guess. 2. **Read `system-prompt.txt`** (sibling of this SKILL.md). Treat it as the authoritative extraction instructions. 3. **Read the digest file.** Mid-sized — much smaller than a raw PlanExe HTML report. Compressed sections (Selected Scenario, Review Plan, Premortem, Expert Criticism) carry inline tags; raw sections (Executive Summary, Project Plan, Assumptions, Data Collection) do not. 4. **Canonicalize across sections.** The four compressed sections often surface the same real-world quantity under different phrasings ("minimum viable rental rate" / "off-peak hourly price" / "speculative high hourly rate" all name one rate). Merge near-duplicates into a single canonical snake_case id before writing the JSON. Prefer framings closest to a modelling primitive (rate, count, fraction, amount-per-period). Two ids for the same quantity will silently fragment downstream bounds and Monte Carlo correlations. 5. **Produce the JSON** following the schema at the end of `system-prompt.txt`. For compressed sections, map the inline `source_status` tags to the JSON `value_type` field: `[explicit]` → `explicit`, `[derived]` → `derived`, `[inferred]` → `inferred`, `[missing]` items belong in `missing_values_to_estimate`, `[stress_test]` items are scenario-stress inputs (not baseline `key_values`). For raw sections, apply general parameter-extraction triage. 6. **Output destination.** Default: print JSON to the chat. If the user asks for a file, write to the path they specify. Default suggestion: `<digest-basename>.parameters.json` next to the digest.

Hard Rules (re-stated for emphasis)

• **JSON only.** No markdown fences, no prose, no explanation.
• **Use the digest's tags where they exist.** For compressed sections,

prefer `[explicit] + quote: verified` items for baseline `key_values`. Treat `quote: unverified` items with extra scepticism. `[missing]` items belong in `missing_values_to_estimate`. `[stress_test]` items are downside-scenario inputs, not plan facts.

• **For raw sections** (Executive Summary, Project Plan, Assumptions,

Data Collection), apply general triage: prefer numeric anchors, deadlines, denominators, and explicit gate criteria.

• **Canonicalize across sections.** The compressor over-produces on

purpose; collapsing cross-section near-duplicates into one canonical id is your job at this stage, not its job. Never preserve two ids for the same real-world quantity.

• **Percentages as fractions** between 0 and 1 with `unit: "fraction"`.
• **No invented ids in `formula_hint`** — every variable must be declared

in `key_values`, `missing_values_to_estimate`, or the object's own `depends_on`.

• **Every entry with a non-null `formula_hint` MUST also declare `output_name`

(snake_case id of the computed value) and `output_unit`** (e.g. `"DKK"`, `"people"`, `"fraction"`). Downstream consumers — generate-calculations, run-scenarios, monte-carlo — read these directly and do not parse `formula_hint` or pattern-match on tokens. The LLM is the single authority for both fields.

Reference

• System prompt (authoritative): `system-prompt.txt`
• Producer of the input digest: `experiments/napkin_math/prepare_extract_input.py`
• Parallel skill for full HTML reports: `../extract-parameters-from-full/SKILL.md`
• Background: `docs/proposals/137-section_filtering_for_parameter_extraction.md`,

`docs/proposals/139-compress-for-monte-carlo.md`