| 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
- Get the report path. If the user did not provide one, ask. Do not guess.
- 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.
- 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.
- 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.
- 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
