From 5bd8f4a2ae7c0ca0b9a2bd937839e847dd8ab534 Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Mon, 19 Oct 2026 00:54:18 +0000 Subject: [PATCH] fix(pstack): add TLA+ default and no-verifier fallback to create-formal-verification-skill The event-order sentence names TLA+ as the default in any language, and the sentence that recommended TLA+ for concurrent and distributed designs is gone. When no verifier runs on the language, the agent says so and tests the real code with generated inputs, not a hand model of the function. The new paragraph is the exact text that a preregistered eval tested. --- .../skills/create-formal-verification-skill/SKILL.md | 2 +- pstack/skills/create-formal-verification-skill/SKILL.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/harness/pstack/claude-code/skills/create-formal-verification-skill/SKILL.md b/harness/pstack/claude-code/skills/create-formal-verification-skill/SKILL.md index 21fd16918..893f6042c 100644 --- a/harness/pstack/claude-code/skills/create-formal-verification-skill/SKILL.md +++ b/harness/pstack/claude-code/skills/create-formal-verification-skill/SKILL.md @@ -16,7 +16,7 @@ A good target is a promise the code makes, where a break harms users and tests r ## Let the question choose the tool -Pick the tool that answers the question at the lowest cost: a model checker, a proof assistant, an SMT-backed verifier, or another tool. Whether events can happen in a bad order usually suits a model checker over a small model of the design. Whether the code itself behaves for every input, as with memory safety, overflow, or a data-structure invariant, usually suits a verifier that runs on the code. A property that must hold at every size, where a bound is not enough, can need a proof. For concurrent and distributed designs, TLA+ is often the most useful place to start. Prefer a tool that the repo's developers can install and run, and tell the user why you chose it. +Pick the tool that answers the question at the lowest cost: a model checker, a proof assistant, an SMT-backed verifier, or another tool. Whether events can happen in a bad order usually suits a model checker over a small model of the design, and TLA+ is the default for that in any language. Whether the code itself behaves for every input, as with memory safety, overflow, or a data-structure invariant, usually suits a verifier that runs on the code. If no verifier runs on this language, say so, and test the real code with generated inputs, not a hand model of the function. A property that must hold at every size, where a bound is not enough, can need a proof. Prefer a tool that the repo's developers can install and run, and tell the user why you chose it. ## What makes it good diff --git a/pstack/skills/create-formal-verification-skill/SKILL.md b/pstack/skills/create-formal-verification-skill/SKILL.md index 21fd16918..893f6042c 100644 --- a/pstack/skills/create-formal-verification-skill/SKILL.md +++ b/pstack/skills/create-formal-verification-skill/SKILL.md @@ -16,7 +16,7 @@ A good target is a promise the code makes, where a break harms users and tests r ## Let the question choose the tool -Pick the tool that answers the question at the lowest cost: a model checker, a proof assistant, an SMT-backed verifier, or another tool. Whether events can happen in a bad order usually suits a model checker over a small model of the design. Whether the code itself behaves for every input, as with memory safety, overflow, or a data-structure invariant, usually suits a verifier that runs on the code. A property that must hold at every size, where a bound is not enough, can need a proof. For concurrent and distributed designs, TLA+ is often the most useful place to start. Prefer a tool that the repo's developers can install and run, and tell the user why you chose it. +Pick the tool that answers the question at the lowest cost: a model checker, a proof assistant, an SMT-backed verifier, or another tool. Whether events can happen in a bad order usually suits a model checker over a small model of the design, and TLA+ is the default for that in any language. Whether the code itself behaves for every input, as with memory safety, overflow, or a data-structure invariant, usually suits a verifier that runs on the code. If no verifier runs on this language, say so, and test the real code with generated inputs, not a hand model of the function. A property that must hold at every size, where a bound is not enough, can need a proof. Prefer a tool that the repo's developers can install and run, and tell the user why you chose it. ## What makes it good