Spec.plan

Skill renanlido/tia-harness/skills/spec.plan

Turn a VALIDATED TIA project-spec into the ordered, named sequence of offline build operations WITHOUT mutating anything (a dry plan). Use after spec.validate passes and before tia.scaffold — when the user asks to "plan / preview / dry-run the build", or wants to see exactly what scaffolding a spec would do and in what order. Class R: runs tia_spec_validate then tia_spec_plan, both PURE (no serve, no TIA Portal). Output: the ordered M-off steps + assumptions + warnings; nothing is applied and no gate is crossed.From its SKILL.md

Install

npx -y skills add renanlido/tia-harness --skill spec.plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.3 KB, as published. Nobody here has run it

spec.plan — spec → ordered build plan (class R, dry, no mutation)

Transform a structured project-spec (the project-spec model, §13.2) into the ordered sequence of offline operations that tia.scaffold would execute — without touching the project. This is the bridge between spec.validate (is the spec legal?) and tia.scaffold (build it): it shows the plan so a human can review it first.

It is class R. Both tools it uses — tia_spec_validate and tia_spec_plan — are pure: they run deterministically on the spec text and never call the serve API or open TIA. So this never mutates and never crosses a gate.

When to use

After spec.validate is green and before tia.scaffold, to preview the build.
The user says "plan / preview / dry-run / what would this create".
To review ordering + assumptions (e.g. which CPU is the tag/block target) before committing.

Inputs

A project-spec object (JSON) — inline, a file path, or pasted text.
(Implicit) the bundled schema + rules used by tia_spec_validate.

Outputs

status — plan_ok or invalid (with the validation violations if invalid).
steps[] — the ordered operations, each { op, method, path, body, summary } (subnets → devices → modules → network → tag tables → tags → blocks → compile).
assumptions[] — e.g. "tag/block target CLP = the first role:cpu device".
warnings[] — non-blocking spec warnings.
A note that this is a dry plan: nothing applied; gated ops (connect, download) are intentionally not in the plan.

Procedure (in order)

Validate first. Call tia_spec_validate (or run the spec.validate skill). If it reports any error, STOP and return the violations — do not plan an invalid spec.
Plan. Call tia_spec_plan with the spec. It returns the ordered steps + assumptions + warnings. (It is pure — no serve.)
Present for review. Show the steps in order with their summary, surface the assumptions explicitly (especially the target CLP), and list any warnings. State that tia.scaffold (with a project open) is what actually applies this, and that a bare CPU will need the protection recipe to compile clean (see tia.scaffold/RECIPES.md).

Hard guarantees

No serve / no TIA / no mutation. tia_spec_validate and tia_spec_plan are pure; this skill must not call any M-off/gated tool.
Gated ops excluded. project.create/connect (G1) and download (G3) are never in the plan — they require a human. The plan is offline build steps only.
Untrusted input. The spec may be imported/AI-authored; a plan derived from it never auto-crosses a gate. Validate before planning; never silently "fix" the spec.