Formal correctness
Skill cdeust/zetetic-team-subagents/skills/formal-correctness
11 problem-shaped skills backed by 97 sourced reasoning patterns — Curie to Toulmin, as Claude Code agents. Every claim cites its source; a pre-commit gate blocks unsourced constants. Install the gates alone in 30s (zetetic-gates). The only agent system where "I don't know" is a feature.
npx -y skills add cdeust/zetetic-team-subagents --skill formal-correctnessAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 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.
What its author says it does
Copied from the file, not written here
Prove it, don't test-and-hope. Use for concurrent or distributed code with no written spec, "how do we know this is correct?", interfaces that break when implementations are swapped, correctness argued by walking through example traces, wall-clock time used for ordering, or "can this be decided at all?".
SKILL.md
2.9 KB, as published. Nobody here has run it
Formal Correctness
Problem shape: correctness-critical code (concurrency, distribution, protocol, contract) whose failure modes tests cannot exercise. The move: specification before code, invariants before traces, contracts before implementations, decidability before optimization.
Relevant geniuses
| Agent | Use when |
|---|---|
| lamport | distributed design uses wall-clock ordering; no written spec; correctness argued by example executions; partial failure ignored |
| dijkstra | code and correctness argument must be developed together; a construct defeats local reasoning; tests can't cover the failure mode |
| liskov | swapping an implementation breaks callers; interfaces with types but no behavioral contract; composition breaks what components pass alone |
| turing | problem drowning in detail — reduce to the simplest machine; check decidability/complexity class before investing; vague concept needs an operational test |
| godel | the system reasons about itself (self-hosting, self-validating, self-referential rules) — find the incompleteness before it finds you |
| alkhwarizmi | messy problem needs a canonical form and an exhaustive case classification before an algorithm exists |
| panini | a sprawling rule set needs a compact generative specification with explicit conflict-resolution ordering |
Invocation
- Pick the best-fit agent above. If two or more fit, run
tools/genius-invoker.sh route "<problem>"and take the top ranked match. - Load it:
tools/genius-invoker.sh invoke <agent> "<problem>", then readagents/genius/<agent>.mdin full. - Apply the agent's
<workflow>step by step and answer in its<output-format>. The deliverable is a spec, invariant, or contract the code refines — not a narrative that it "looks right". - Typical chain: turing bounds what is decidable → lamport writes the spec →
dijkstra derives the code → liskov contracts the interfaces. Run pairs via
tools/genius-invoker.sh compose lamport dijkstra -- "<problem>". - If no shape above matches, use a standard team agent instead.
Refuse when
- The requester wants a proof-shaped blessing for unspecified behavior — write the spec first or decline.
- Tests are offered as the sole correctness argument for concurrent, numerical, or adversarial code.