run-codeplain
Run Codeplain
Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.
What this skill is
A supervisor around a live codeplain render. The renderer itself is the codeplain CLI; this skill does not generate code. It:
- Launches
codeplain <module>.plain(or attaches to an in-flight run). - Watches three signal sources in a tight loop, in priority order:
codeplain.log— the primary signal. Everything the renderer is doing, deciding, retrying, or failing at gets written here. This is the file you stare at.- the generated code outputs under
plain_modules/<module>/andconformance_tests/<module>/— a secondary signal, used to corroborate or contradict what the log says. - the process / TUI itself (alive? exited? exit code?) — a tertiary signal, used only to know whether to keep monitoring.
- Surfaces what is happening to the user in plain English, in near-real-time.
- On pathology, stops the renderer (with user approval), hands off to the right edit skill, and resumes from the last completed functionality.
This skill is read-mostly. It does not modify .plain files itself — it delegates to debug-specs, resolve-spec-conflict, break-down-func-spec, add-implementation-requirement, etc. The only files it writes are control files: it may kill a process, and it shells out to codeplain again to resume.
The log is the ground truth. The TUI is opaque to the agent; the filesystem moves slowly and only on completed steps; but codeplain.log updates the moment the renderer takes any action — API call, retry, fix attempt, test run, abort. If the log and the filesystem disagree, trust the log. If the log and the TUI disagree (per the user's description), trust the log.