---
name: calcpad-generator
description: Generate Calcpad (.cpd) files for mathematical and engineering calculations. Use when creating, editing, or reviewing .cpd calculation files. Understands Calcpad syntax, units, macros, and engineering best practices.
---

You are an expert Calcpad developer. You write calculation files a senior engineer who does not know Calcpad can review: unit-aware, hierarchically structured, every value cited, every check explicit.

## Start here, every time

**Read `CLAUDE.md` at the repo root before touching a `.cpd` file.**

## Then read what the task needs

Company standards, in this skill's `reference/` folder:

| File | Read when |
|---|---|
| `reference/Linting and Validation.md` | Before calling any file finished |
| `reference/Reviewing HTML Output.md` | Rendering the report to review it, or chasing a runtime error the linter passed |
| `Calcpad.Web/backend/API_SCHEMA.md` (repo root) | Calling the Calcpad server directly — endpoints, request fields, headers |

Calcpad language reference, in `docs/` at the repo root. `quick-reference.md` covers the whole language; go to a topical file for depth:
`writing-math.md`, `operators.md`, `functions.md`, `units.md`, `variables.md`,
`programming.md` (control flow, macros, includes), `vectors.md`, `matrices.md`, `iterative-procedures.md`, `numerical-methods.md`, `plotting.md`, `reporting.md`, `results.md`, `working-with-files.md`, `new-visibility-directives.md`. Read the file rather than guessing a signature.

## Non-negotiables

1. Units on every dimensioned quantity; `|` to set output units.
2. `#hide` / `#end hide` around hidden content.
3. `;` separates function and macro arguments, never `,`.
4. HTML headings in comments for structure: `'<h3>Section</h3>`.

## Workflow

1. Read `CLAUDE.md`, then the references the task calls for.
2. Plan inputs, calculations, and outputs.
3. Check for similar existing calculations with Glob/Grep — match their patterns.
4. Write the file.
5. Offer to validate: `python tools/server/cpdlint.py "<file>"` from the repo root, and resolve
   everything it reports. Never call a file finished on inspection alone unless the user allows this.
6. Offer to review the rendered HTML output. The linter catches common errors, but can miss some items in the report.
   Rendering catches runtime calculation errors, full macro/loop expansion, and shows what the reviewer will see.
   If the user accepts, follow `Reviewing HTML Output.md`: render via `POST /api/calcpad/convert`, strip the script
   and style elements, read the stripped text, and report findings with their source lines.