common-tdd
Implements a strict Red-Green-Refactor loop to ensure zero production code is written without a prior failing test. Use when: creating new features, fixing bugs, or expanding test coverage.
79
76%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.github/skills/common/common-tdd/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 effectively communicates the TDD methodology and includes an explicit 'Use when' clause, which is a strength. However, the trigger scenarios are overly broad ('creating new features, fixing bugs') and would conflict with many other coding skills. It also misses common natural language terms like 'TDD' or 'test-driven development' that users would likely use.
Suggestions
Add common trigger terms users would naturally say: 'TDD', 'test-driven development', 'test-first', 'write tests first', 'unit testing workflow'.
Narrow the 'Use when' triggers to be more distinctive—e.g., 'Use when the user requests TDD, test-driven development, test-first coding, or explicitly wants tests written before implementation' rather than the overly broad 'creating new features, fixing bugs'.
Add more specific concrete actions: e.g., 'Writes a failing test, implements minimal code to pass, then refactors while keeping tests green' to better illustrate the workflow.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (TDD/Red-Green-Refactor) and describes the core constraint ('zero production code without a prior failing test'), but doesn't list multiple specific concrete actions beyond the general methodology. Actions like 'creating new features, fixing bugs, expanding test coverage' are broad categories rather than specific concrete actions. | 2 / 3 |
Completeness | Clearly answers both 'what' (implements a strict Red-Green-Refactor loop ensuring no production code without a failing test) and 'when' (explicitly states 'Use when: creating new features, fixing bugs, or expanding test coverage'). | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'Red-Green-Refactor', 'failing test', 'test coverage', 'features', 'bugs', but misses common natural user phrases like 'TDD', 'test-driven development', 'write tests first', 'unit tests', or 'test-first approach' that users would naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | The TDD/Red-Green-Refactor methodology is a fairly distinct niche, but the trigger scenarios ('creating new features, fixing bugs') are extremely broad and would overlap with virtually any coding skill. Only the test-related triggers help distinguish it. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
85%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-structured TDD skill that is concise, clearly sequenced, and appropriately organized with progressive disclosure to reference files. Its main weakness is the lack of inline executable code examples—the AAA structure is described but the actual code example is deferred to a reference file, which slightly reduces immediate actionability. Minor grammatical issues ('MUST deleted', 'not test') don't significantly impact clarity.
Suggestions
Add at least one inline executable code example showing the AAA pattern (e.g., a simple pytest test) rather than deferring all code to reference files.
Fix minor grammatical issues: 'Code written before test MUST deleted' → 'MUST be deleted'; 'test without assert not test' → 'a test without an assert is not a test'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. It avoids explaining what TDD is conceptually and jumps straight into actionable rules. Every section earns its place with no padding or unnecessary context that Claude would already know. | 3 / 3 |
Actionability | The skill provides clear rules and structure (AAA, RGR loop, mock guidelines, coverage thresholds) but lacks any executable code examples inline—the AAA code example is deferred to a reference file. Concrete coverage commands and test code snippets would make this more immediately actionable. | 2 / 3 |
Workflow Clarity | The RGR loop is clearly sequenced with explicit verification at each step (verify failure, verify pass, stay green). The verification checklist provides a feedback loop, and the iron law about deleting code written before tests establishes a clear error recovery pattern. | 3 / 3 |
Progressive Disclosure | The skill provides a concise overview with well-signaled one-level-deep references to AAA examples, test runners, TDD patterns, and anti-patterns. Content is appropriately split between the main file and reference documents. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 11 Passed | |
- Repository
- HoangNguyen0403/agent-skills-standard
- Commit
4c72e76
- 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.