/polygen

name: polygen
description: Write NEW stateful code that is verifiable from the moment it's written, instead of auditing code that already exists (that's the "polygraph" skill). Draft a contract from a feature description, author a SAM v2 strict-profile module against it (named intents/schemas/domains, keyed acceptors, reject(reason), sealed model, next-state (prime) acceptors), self-repair against reachable invariant violations before anything ships, and synthesize a demo/regression trace corpus. Use when the user wants to write a new state machine, workflow, or reducer and have it come out pre-verified; when they say "build a verifiable X"; or as the first half of a lifecycle that ends with wiring the result into a real app and auditing the integration with polygraph. Trigger phrases: "polygen", "write a verifiable state machine", "author verifiable code", "build me a X flow that's already checked", "generate a reducer/workflow and verify it".

polygen — author verifiable code, out of the box

Companion to the `polygraph` skill. That one AUDITS code that already exists. This one AUTHORS new code so it's verifiable from the start — closing the loop at creation time instead of retrofitting it later. v1 is **JS/TS only**: the generated module is directly usable only in a JS/TS codebase (porting a verified model to another language is a real, separate problem — the port itself would need its own differential check against the JS original — and is out of scope here).

**The authored artifact (v0.7):** by default a **SAM v2 strict-profile module** (`module.exports = { instance, init, actions, getState, setState }`, sam-lib 2.1.2 vendored in the plugin): named intents with schemas and finite domains, acceptors keyed by intent name, every not-applicable action an observable `reject(reason)` (never a throw), sealed model, and explicit next-state (prime) semantics — acceptors write the `next` draft and frame untouched variables with `unchanged(...)` (sam-lib 2.1, #25). Generated code must load **strict-clean** — `instance({}).validate()` is a hard gate at every stage boundary, so schema/shape errors block instead of becoming report lines, and dead wiring cannot ship silently. The self-repair loop feeds back `lastStep()` classifications and determinism flags, not only windows and invariants. (House rule from sam-lib #29, fixed in 2.0.0-alpha.2: never rely on `instance({}).state()`; the pipeline uses `getState()`/`setState()` only.)

> **Same disclosure as `polygraph`.** This is experimental, unproven > technology and a *consistency check, not a proof*. A converged run means the > authored code satisfies its OWN stated invariants over a bounded, explored > state space — nothing more, and that space is finite only because the > contract declares finite action/data domains; behavior at values outside > the declared representatives is unchecked. The contract and the invariants are the model's > reading of your intent; they need your review before either is trusted.

All scripts live under `${CLAUDE_PLUGIN_ROOT}/scripts/`. `polygen.mjs` needs `ANTHROPIC_API_KEY` and an explicit `--model` (no default; recommend `opus-5` with the self-repair loop on, which is the default — `fable-5` only for one-shot runs with `--repair-max 0`, and `opus-4.8` as the retry if the API refuses on policy grounds. Per-step source of truth: `RECOMMENDED_MODELS` in `scripts/models.mjs`).

Step 0 — Choose the authoring path (key or no key)

Only the AUTHORING model call needs a key. Every gate below it — the strict `validate()` load, `check.mjs` model checking, corpus validation, replay, `check-effects`, the polyrun deploy gate, polyvers, polynv — is pure local execution. That means there are two legitimate paths, and the user chooses:

• **Keyed (scripted) — the CI / reproducibility path.** `polygen.mjs` with

`ANTHROPIC_API_KEY`: pinned model id, deterministic harness, the automated self-repair loop, the standard `polygen-report.md`, and the synthesized corpus independently replayed in a separate process. This is the path for enterprises wiring authoring into CI, and for anyone who wants the run re-executable byte-for-byte later.

• **Keyless (in-session) — the zero-cost adoption path.** YOU are the

authoring model. Author `contract.json`, the SAM v2 strict-profile module, and `invariants.mjs` in this session, in the exact artifact style (copy shapes from an existing example, e.g. `${CLAUDE_PLUGIN_ROOT}/examples/workflows-not-loops/pipeline-v1/`), then run the SAME mechanical gates the script would: `check.mjs` (fix code at any counterexample and re-check — that is the self-repair loop, performed by you), drive the module through exported scenarios to synthesize a corpus, `validate_corpus.mjs`, and replay in a separate process. A/B evidence that this is not a degraded mode: an in-session-authored machine and a scripted `polygen.mjs` run against the same contract were behaviorally identical over the full explored space (270/270 edges, `examples/workflows-not-loops/README.md` "Provenance") — the checkers, not the key, carry the guarantee.

**When no key is present, ASK — never fail silently and never fall back silently.** The user decides, with the tradeoffs in front of them. The question to put to them, roughly:

> I don't have an `ANTHROPIC_API_KEY` in this environment. Two ways forward: > **(a) continue keyless** — I author the artifacts in this session and run > every mechanical gate locally (model check, corpus validation, separate- > process replay); same checking strength, zero API cost; what you give up > is a pinned model id and a scripted, re-runnable authoring step. > **(b) supply a key** — the scripted `polygen.mjs` run: pinned model, > automated repair loop, the standard report; this is the path you'd wire > into CI. Which would you like?

If they choose keyless and later want the CI-grade run, the same contract feeds `polygen.mjs --contract` unchanged.

State the prove