antithesis-setup
Scaffold the Antithesis harness: initialize the working directory, write Dockerfiles and docker-compose.yaml with build directives, and prepare to submit your first Antithesis test run.
57
65%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./antithesis-setup/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is strong in specificity and distinctiveness, clearly naming the Antithesis testing platform and listing concrete scaffolding actions. Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know exactly when to select this skill. Trigger term coverage could also be broader to capture more natural user phrasings.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to set up or scaffold an Antithesis testing harness, or mentions Antithesis test runs.'
Include additional natural trigger terms such as 'Antithesis setup', 'fuzz testing', 'autonomous testing', or 'Antithesis SDK' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'initialize the working directory', 'write Dockerfiles and docker-compose.yaml with build directives', and 'prepare to submit your first Antithesis test run'. These are clear, actionable tasks. | 3 / 3 |
Completeness | Clearly answers 'what does this do' with specific scaffolding actions, but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied by the nature of the actions described. | 2 / 3 |
Trigger Term Quality | Includes relevant terms like 'Antithesis', 'Dockerfiles', 'docker-compose.yaml', 'harness', and 'test run', but these are somewhat specialized. Missing common variations a user might say like 'fuzz testing', 'autonomous testing', 'Antithesis setup', or 'Antithesis SDK'. | 2 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific 'Antithesis harness' domain. Unlikely to conflict with generic Docker or testing skills because of the clear Antithesis-specific context and the combination of scaffolding tasks described. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-organized orchestration skill with strong workflow clarity, explicit prerequisite gates, and a thorough self-review checklist. Its main weaknesses are that actionability depends heavily on reference files that aren't provided for evaluation, and the skill body itself is somewhat verbose with duplicated success criteria and lengthy prerequisite explanations that could be more concise.
Suggestions
Add at least one concrete, executable code/config snippet inline (e.g., a minimal docker-compose.yaml skeleton or a bootstrap property example) so the skill body itself provides actionable guidance even before reference files are consulted.
Consolidate the success criteria and self-review checklist into a single section or move the detailed self-review to a reference file to reduce duplication and improve conciseness.
Tighten the provenance verification section — the four example scenarios could be reduced to a brief instruction like 'Describe whatever provenance frontmatter you find and confirm with the user before proceeding.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably well-structured but includes some verbose sections that could be tightened — particularly the extensive provenance verification examples, the lengthy prerequisites section explaining what to do when scratchbook is missing, and the self-review checklist which partially duplicates the success criteria. However, most content is project-specific knowledge Claude wouldn't already have. | 2 / 3 |
Actionability | The skill provides clear structural guidance (directory paths, tool commands like `snouty validate`, `podman compose`) and specific configuration requirements (e.g., `NO_COLOR=1`, `platform: linux/amd64`, `init: true`), but the actual implementation steps are deferred to reference files (`references/directory-init.md`, etc.) which are not provided. The skill itself contains no executable code examples or copy-paste-ready snippets. | 2 / 3 |
Workflow Clarity | The workflow is clearly sequenced across six numbered reference files with explicit ordering. There are validation checkpoints (snouty validate, image inspect for amd64, local testing before submission), feedback loops (check whether later steps invalidate earlier decisions), and a comprehensive self-review checklist. The prerequisite gates (research artifacts, provenance confirmation, snouty installation) are explicit stop-points. | 3 / 3 |
Progressive Disclosure | The skill correctly structures content as an overview pointing to six reference files and links to external documentation, which is good progressive disclosure design. However, since no bundle files are provided, we cannot verify the referenced files exist or contain appropriate content. The self-review checklist is quite long and could arguably be in a separate reference file, and some inline content (like the provenance examples) adds bulk to what should be an overview. | 2 / 3 |
Total | 9 / 12 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- antithesishq/antithesis-skills
- Commit
f837248
- 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.