/extract-parameters-from-full

name: extract-parameters-from-full
description: Use when the user wants to extract parameters, modelling values, or key variables from a PlanExe report (HTML or text) for napkin math, triage, or Monte Carlo simulation

Extract Parameters from a PlanExe Report

Overview

Wraps the quantitative-triage system prompt at `system-prompt.txt` (next to this file) and applies it to a PlanExe report the user supplies. Output is strict JSON matching the schema in the system prompt — no markdown, no commentary.

When to Use

• User says "extract parameters", "extract modelling values", "pull key variables", or similar from a PlanExe report
• User points at a PlanExe report file (typically HTML, may be 100KB–1MB+) and wants structured input for downstream simulation
• User wants a triage list of values that would matter for Monte Carlo or sensitivity analysis

Not for: full report summarisation, narrative analysis, code generation. The system prompt explicitly forbids those.

Workflow

1. **Get the report path.** If the user did not provide one, ask. Do not guess. 2. **Read `system-prompt.txt`** (sibling of this SKILL.md). Treat its contents as the authoritative extraction instructions — every rule, hard limit, and schema constraint applies. 3. **Read the report file.** For large HTML reports, read the whole file; the system prompt's hard limits (≤8 key_values, ≤5 of each list, ≤25-word comments) keep output bounded regardless of input size. 4. **Produce the JSON** following the exact schema at the end of `system-prompt.txt`. Apply every "Important", "Additional modelling rules", and "Formula and dependency rules" section as you generate each field. 5. **Output destination.** Default: print JSON to the chat. If the user asks for a file, write to the path they specify. If they want a default file path, suggest `<report-basename>.parameters.json` next to the report.

Hard Rules (from system-prompt.txt — re-stated for emphasis)

• **JSON only.** No markdown fences, no prose, no explanation before or after.
• **Percentages as fractions** between 0 and 1 with `unit: "fraction"`. Never `value: 60` for 60%.
• **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.
• **Prefer missing-but-needed values over minor explicit values.** Don't dump every budget line.
• **Clean `source_text`** — strip citations, footnote markers, replacement chars, UI artifacts.

Common Mistakes

| Mistake | Fix | |---|---| | Wrapping JSON in ```` ```json ```` fences | Raw JSON only — the system prompt forbids markdown | | Returning >8 key_values "because the report has many" | Hard cap. Triage. The point is to surface the few that matter | | Including `suggested_low/base/high` by default | Only include when essential to the value's meaning | | Using `value: 60` for "60%" | Use `value: 0.6` and `unit: "fraction"` | | Citing variable in `formula_hint` that isn't declared anywhere | Either add it to `missing_values_to_estimate` or rewrite the formula | | Picking a descriptive timeline value over a funding gate | Prefer the gate — it determines pass/fail |

Reference

• System prompt (authoritative): `system-prompt.txt`
• Example report for testing: `/Users/neoneye/git/PlanExe-web/20250720_faraday_enclosure_report.html`