CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

ac-test-generator

Generate tests for features using TDD approach. Use when creating test files, generating test cases, implementing RED phase of TDD, or scaffolding test infrastructure.

Quality

78%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/ac-test-generator/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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.

The body is well-structured and actionable, with an executable Quick Start and a clear validated workflow. Its weaknesses are padding — tutorial-style explanations of test types and TDD basics — and an example output that includes stubbed, non-executable tests.

Suggestions

Cut the 'Test Types' and 'TDD Integration' sections (or reduce them to one line each) — Claude already knows what unit/integration/E2E tests and RED/GREEN/REFACTOR are; keep only project-specific conventions.

Complete or trim the example test file so every shown test has a real body, or explicitly state that stubs are placeholders awaiting feature-specific assertions.

Add a brief error-recovery note to the Workflow (e.g. what to do when generated tests pass prematurely or the feature file is missing) to strengthen the Validate checkpoint.

DimensionReasoningScore

Conciseness

The 'Test Types' section (e.g. 'Test individual functions', 'Mock dependencies', 'Fast execution') and the 'TDD Integration' RED/GREEN/REFACTOR diagram explain concepts Claude already knows, and 'Purpose' restates the frontmatter description. The padding is real but not pervasive, fitting 'mostly efficient but includes some unnecessary explanation'.

3 / 5

Actionability

The Quick Start is genuine executable code matching the real script API, and the Configuration block is concrete. However, the 'Generated Test Structure' example is two-thirds `pass` stubs with comment placeholders ('# Arrange - create existing user'), leaving minor gaps that keep it below fully copy-paste-ready.

4 / 5

Workflow Clarity

The five-step Workflow is clearly sequenced and includes an explicit validation checkpoint ('Validate: Ensure tests fail (RED)'). It lacks error-recovery guidance (e.g. what to do if tests unexpectedly pass) and the steps are terse without commands, so it does not reach anchor 5.

4 / 5

Progressive Disclosure

Sections are well-organized and the single bundle reference ('See scripts/test_generator.py for full implementation') is clearly signaled, one level deep, and points to a real file. Minor gaps: the long example test could live in a references file, and the body is somewhat long for an overview.

4 / 5

Total

15

/

20

Passed

Description

78%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 description with an explicit and well-phrased trigger clause and third-person voice. Its main weakness is thin capability specificity — one broad action — which also leaves modest overlap risk with generic testing skills.

Suggestions

Enumerate the concrete capabilities in the 'what' clause, e.g. 'Generate unit, integration, and E2E test files for features, including fixtures and Arrange-Act-Assert scaffolding, following TDD.'

Add natural trigger synonyms users commonly say, such as 'write tests', 'unit tests', or 'pytest', to the 'Use when' clause to broaden and sharpen matching.

Tighten distinctiveness by leading with the TDD/RED-phase specialization (e.g. 'Create failing tests first (RED phase of TDD)...') so generic test-writing requests are less likely to trigger it.

DimensionReasoningScore

Specificity

The 'what' is a single action — 'Generate tests for features using TDD approach' — naming the domain but offering only one concrete capability with no enumeration of what generation covers (e.g., fixtures, coverage reporting, framework selection). It is below anchor 4, which requires several specific listed actions.

3 / 5

Completeness

Clearly answers 'what' ('Generate tests for features using TDD approach') and explicitly answers 'when' with a 'Use when...' clause containing four concrete trigger phrases, matching the top anchor. Not below 5 since neither half is vague or implied.

5 / 5

Trigger Term Quality

Natural phrases users would say are present — 'creating test files', 'generating test cases', 'implementing RED phase of TDD', 'scaffolding test infrastructure' — giving good coverage. Missing common variations like 'write tests', 'unit tests', 'pytest', or 'test coverage', so not anchor 5.

4 / 5

Distinctiveness Conflict Risk

'Implementing RED phase of TDD' carves a clear niche, but the generic triggers 'creating test files' and 'generating test cases' overlap with any general test-writing skill, so minor conflict risk remains — anchor 4 rather than 5.

4 / 5

Total

16

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

fernandezbaptiste/Skrillz

Path

skills/ac-test-generator/SKILL.md

Revision

93ed392

Reviewed

Table of Contents

DiscoveryImplementationValidation

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.

Claim skill