CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

test-driven-development

在实现任何功能或修复 bug 时使用,在编写实现代码之前

Quality

57%

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/test-driven-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

73%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 an exceptionally actionable and clearly sequenced TDD workflow — complete executable examples, mandatory red/green verification with feedback loops, and a final checklist. Its weaknesses are redundancy between the 'common excuses' table and 'danger signals' list (conciseness), and a broken progressive-disclosure structure: the promised writing-good-tests.md reference does not exist in the bundle while reference-worthy content stays inlined.

Suggestions

Create the referenced writing-good-tests.md file (or remove the link) — the body promises '阅读 [writing-good-tests.md](writing-good-tests.md)' but no such file exists in the bundle.

Merge the '常见借口' table and '危险信号' list, which enumerate the same rationalizations twice, and trim the essay-length full-suite paragraph at line 190 to its operative rule.

Move the detailed test-quality criteria and the excuses catalogue into the reference file, keeping SKILL.md to the cycle, examples, and checklist.

DimensionReasoningScore

Conciseness

The workflow steps and code examples are tight and earn their tokens, but the '常见借口' table (12 rows) and the '危险信号' list (13 items) repeat the same rationalizations twice with motivational padding ("那是在给自己找借口", "删除就是删除"), and the full-suite paragraph at line 190 is essay-length. This is 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than the minor-trimming of anchor 4.

3 / 5

Actionability

Fully executable TypeScript test examples, concrete commands ('npm test path/to/test.test.ts'), a complete worked bug-fix example showing expected FAIL then PASS output, a verification checklist, and a concrete troubleshooting table — copy-paste ready and covering the common cases. Not 4: there are no gaps in executability for an instruction skill.

5 / 5

Workflow Clarity

The red → verify-red → green → verify-green → refactor cycle has explicit mandatory validation checkpoints ("必须执行。绝不跳过"), error-recovery feedback loops ("测试报错了?修复错误,重新运行直到它正确地失败"), a full-suite verification requirement before declaring done, a cycle diagram, and a final checklist — exactly the anchor-5 pattern of explicit validation steps, feedback loops, and a checklist.

5 / 5

Progressive Disclosure

The body links to [writing-good-tests.md](writing-good-tests.md) as its one external reference, but no such file exists anywhere in the bundle (no references/, scripts/, or assets/ directories), so navigation to the reference fails. Meanwhile substantial content that belongs in a reference file (the 12-row excuses table, test-quality criteria) is inlined, making SKILL.md a ~330-line near-monolith — matching 'content that clearly belongs in separate files is inlined'. Not 3, because the one clearly signaled reference is broken rather than merely under-organized.

2 / 5

Total

15

/

20

Passed

Description

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

The description is a pure trigger clause with no capability statement: it says when to apply the skill but never says what the skill does (test-driven development), omits the skill's own vocabulary (test, TDD, refactor), and scopes the trigger to 'any feature or bug', creating conflict risk with essentially all coding skills. It needs a 'what' clause and narrower, TDD-specific triggers.

Suggestions

Add a 'what' statement naming the concrete capability, e.g. 'Enforces a red-green-refactor test-driven development workflow: write a failing test, verify it fails, write minimal code, verify the full suite passes, then refactor.'

Include the skill's natural trigger terms users would actually say — 'write tests', 'test-first', 'TDD', 'refactor' — so the skill triggers on testing requests, not just on every feature/bug request.

Narrow the trigger from 'any feature or bug' to contexts where test-first discipline applies (new features, bug fixes, behavior changes) and reference testing explicitly to reduce overlap with generic development skills.

DimensionReasoningScore

Specificity

The description states only when to use the skill ("在实现任何功能或修复 bug 时使用") and names the domain, but lists no concrete actions or capabilities at all — it never says what the skill actually does. It is not entirely vague abstract language (not 1), but it fails the anchor-3 bar of naming 1-2 concrete actions.

2 / 5

Completeness

Only the 'when' is present with no 'what' — the exact anchor-2 pattern ('only when is present without what', e.g. 'Use when working with documents'). The description never states that the skill enforces a test-first (TDD) workflow. Not 3, because the 'what' is not even weakly implied beyond a generic 'use before writing implementation code'.

2 / 5

Trigger Term Quality

Phrases like "实现功能" (implement features), "修复 bug" (fix bugs), and "编写实现代码" are natural user terms, but common variations and synonyms are missing — most notably "测试" (test), "TDD", "先写测试" (write tests first), and "重构" (refactor). The skill's own domain vocabulary never appears, which keeps it at 'some relevant keywords but missing common variations'.

3 / 5

Distinctiveness Conflict Risk

"在实现任何功能或修复 bug 时使用" ('use when implementing ANY feature or fixing ANY bug') is maximally broad — virtually every coding request matches, so this description would compete with nearly every development-related skill. It fits 'entirely generic; would conflict with virtually any skill'.

1 / 5

Total

8

/

20

Passed

Validation

75%

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

Validation — 12 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 1 missing

Warning

Total

12

/

16

Passed

Repository

jnMetaCode/superpowers-zh

Path

skills/test-driven-development/SKILL.md

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.