CtrlK
BlogDocsLog inGet started
Tessl Logo

simulate-to-verify

Build a fast, runnable simulation of a system's safety rules and attack it with hostile inputs to find where it fails BEFORE production — without starting any service. Use this whenever the user wants to "simulate the system", "verify without running it", stress-test invariants, find edge cases / outliers, prove a pipeline or workflow is safe, model a system's rules, or harden code against weird/malicious input. Also use proactively after building any system with safety or correctness invariants (auth, redaction, access control, validation, state machines, data pipelines, payment/ledger logic, agent tool contracts) — the happy-path tests almost never cover the hostile path, and this finds the gap cheaply. Triggers on: "simulate", "model the rules", "edge cases", "stress test", "what could break", "is this safe", "adversarial test", "find outliers".

73

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

85%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured body that sequences a seven-move verification loop with strong validation checkpoints and delegates depth to real, clearly signaled bundle files. It could be slightly leaner and would benefit from one inline executable snippet, but the scaffold makes it concretely actionable.

Suggestions

Trim motivational prose (e.g. 'The win: the happy path is the path you already thought about...') to tighten conciseness without losing the method insight.

Add one short inline executable snippet (e.g. a minimal rule function + one hostile input + verdict) so the body is copy-paste actionable before invoking the scaffold.

Consider qualifying generic trigger terms like 'stress test' and 'edge cases' in the description with the safety-invariant context to reduce overlap with general testing skills.

DimensionReasoningScore

Conciseness

Largely efficient and free of generic filler or explanations of concepts Claude already knows, but contains some motivational/rhetorical prose ('The win: the happy path is the path you already thought about', 'A 58%-of-the-time bug is worse than an always-bug because it hides') that could be trimmed, so it sits just below a 5.

4 / 5

Actionability

Provides a concrete scaffold command, a precise verdict taxonomy (SAFE-REJECT/SAFE-PASS/LEAK/FALSE-REJECT), and specific thresholds (≥5 seeds, 'hundreds more seeds'), but the inline body delegates executable code to the scaffold script rather than including copy-paste code, leaving minor gaps versus a 5.

4 / 5

Workflow Clarity

A clearly sequenced seven-move loop with explicit validation checkpoints (move 6 differential, move 7 fix-test-first-then-re-run-to-confirm) and a dedicated self-verifying/meta-tests section with feedback loops ('If you can't make it go red on demand, you haven't verified anything').

5 / 5

Progressive Disclosure

A clear overview that points one level deep to real, purpose-labeled files — references/method.md ('Read it before starting; it is the substance of this skill'), references/patterns.md, and scripts/scaffold_simulation.py — with the short version inline and the bulk appropriately split out.

5 / 5

Total

18

/

20

Passed

Description

96%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, third-person description that concretely states the capability, gives an explicit 'Use when' trigger clause, a proactive-use clause, and a dedicated trigger-term list. Its only weakness is mild overlap risk from a couple of generic trigger terms.

DimensionReasoningScore

Specificity

Names multiple concrete actions — 'Build a fast, runnable simulation of a system's safety rules', 'attack it with hostile inputs to find where it fails', 'without starting any service' — giving comprehensive coverage of what the skill does.

5 / 5

Completeness

Explicitly answers both what ('Build a fast, runnable simulation... attack it with hostile inputs to find where it fails') and when (a 'Use this whenever...' clause plus a proactive 'after building any system with safety... invariants' clause plus a 'Triggers on:' list with concrete phrases).

5 / 5

Trigger Term Quality

Comprehensive natural-term coverage including synonyms and explicit triggers ('simulate', 'model the rules', 'edge cases', 'stress test', 'what could break', 'is this safe', 'adversarial test', 'find outliers') that users would naturally say.

5 / 5

Distinctiveness Conflict Risk

The niche (adversarial simulation of safety rules without running services) is clear and distinct, but a few trigger terms like 'stress test' and 'edge cases' are generic and carry minor overlap risk with general testing skills, keeping it just below a 5.

4 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
tombrewsviews/skill-simulate-to-verify
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.