tdd-workflow Skill Evaluation Report¶

Evaluation framework: skill-creator Evaluation date: 2026-03-11 Evaluation subject: tdd-workflow

tdd-workflow is an end-to-end TDD skill for Go code changes, designed to put "write failing tests first, then minimal implementation, then safe refactor" into practice. It is especially suited for new features, bug fixes, and security-sensitive logic testing. Its three standout strengths are: requiring a one-to-one mapping between Defect Hypotheses and test cases, so you define "what bug to catch" before writing tests; enforcing a Red → Green → Refactor evidence chain so the TDD process is verifiable, not just claimed; and using Killer Cases plus coverage and risk-path gates to elevate tests from "runnable" to "capable of catching critical defects".

1. Evaluation Overview¶

This evaluation reviews the tdd-workflow skill along two axes: actual task performance and token cost-effectiveness. Three scenarios were designed (S-size yamlQuote boundary tests, M-size normalizeSummaryJSON three-function tests, M-size IsPrivateIPLiteral security tests). Each scenario was run with both with-skill and without-skill configurations, for 3 scenarios × 2 configs = 6 independent subagent runs, scored against 39 assertions.

2. Test Methodology¶

2.1 Scenario Design¶

2.2 Rationale for Target Selection¶

• All use stdlib assertions (project constitution forbids testify) — tests skill adaptation to project assertion style
• Functions exist but lack direct unit tests — tests skill ability to handle "characterization testing" (adding tests to existing code)
• Varying complexity — from 4 LOC pure functions to 12 LOC multi-branch security functions

2.3 Execution¶

• With-skill runs first read SKILL.md and optionally load reference materials
• Without-skill runs read no skill, using model default behavior
• All runs execute in parallel in independent subagents

3. Assertion Pass Rate¶

3.1 Overview¶

3.2 Per-Assertion Details¶

Eval 1: yamlQuote S-size (12 assertions)¶

Eval 2: normalizeSummaryJSON M-size (14 assertions)¶

Eval 3: IsPrivateIPLiteral M-size (13 assertions)¶

3.3 Classification of 18 Failed Assertions (Without-Skill)¶

Key observation: All 18 failures are TDD methodology artifacts, not test code quality issues. Without-skill test code quality is not low (Eval 1 even produced 15 test cases vs With-skill’s 7), but it lacks TDD process evidence and structured reports.

3.4 Delta Stability¶

Deltas across the three scenarios are highly consistent (+42.9% to +50.0%), indicating the skill’s contribution is not task-dependent but systematically injects six categories of TDD methodology artifacts.

4. Dimension-by-Dimension Comparison¶

4.1 Defect Hypothesis → Test Mapping (Core Differentiator)¶

This is the TDD skill’s most distinctive contribution — requiring hypotheses before tests.

Practical value: Defect hypotheses are not just report decoration — they drive more targeted test design:

• Eval 3 H1 (IPv4-mapped IPv6 bypass) is a test angle completely absent from Without-skill. ::ffff:127.0.0.1 and ::ffff:10.0.0.1 are real SSRF attack vectors; none of Without-skill’s 36 tests touch them.
• Eval 2 DH5 (nested braces extraction boundary) is a key test for the Index/LastIndex algorithm; Without-skill has the test but no hypothesis rationale.

4.2 Red → Green Evidence¶

Key difference: For characterization testing (adding tests to existing code), the skill still requires Red evidence — Eval 1 via mutation, Eval 2–3 via hypothesis. Without-skill only shows "all pass", so it cannot prove what the tests actually verify.

4.3 Killer Case Mechanism¶

With-skill produced 6 killer cases in total, each with a 4-part structure:

1. Defect hypothesis — the specific defect hypothesis to verify or falsify
2. Fault injection — how to trigger that defect (mutation or attack input)
3. Critical assertion — the key assertion that must succeed
4. Removal risk — risk if this test is removed

Without-skill tests cover boundaries but lack an SSRF attack perspective (Eval 3) and lack mutation-driven regression protection (Eval 1).

4.4 Test Code Quality (Both Sides Comparable)¶

Notably, Without-skill test code quality is not low:

Without-skill produced more test cases in Eval 1 (15 vs 7) and even covered YAML metacharacters, which With-skill did not. But it lacks a methodology framework — no hypotheses, no red evidence, no coverage report, no killer cases.

Conclusion: The skill’s core value is not generating more or better test code, but injecting TDD methodology discipline and structured deliverables.

4.5 Residual Risks Analysis (Eval 3 Highlight)¶

With-skill’s Eval 3 report listed 4 residual risks:

1. CGNAT (100.64.0.0/10) — currently returns false; extend if threat model includes shared address space
2. IPv6 zone IDs — upstream handling of fe80::1%eth0 is uncertain
3. DNS rebinding — design limitation for hostname resolution bypass
4. Octal/hex IP notation — TOCTOU risk for 0177.0.0.1

This risk analysis is entirely absent from Without-skill and is especially important for security-sensitive code.

5. Token Cost-Effectiveness Analysis¶

5.1 Skill Size¶

5.2 Actual Load Scenarios¶

5.3 Token Cost for Quality Gain¶

5.4 Comparison with Other Skills’ Cost-Effectiveness¶

Analysis:

• Second-highest absolute gain (+46.2%) — behind only e2e-test’s +48.7%
• Strong typical-load cost-effectiveness (~78 tok/1%) — third in the series, behind only git-commit (~51) and thirdparty-api-integration-test (~62)
• Good SKILL.md cost-effectiveness (~52 tok/1%) — comparable to git-commit (~51)
• Lean, effective references — 4 reference files total ~2,800 tokens, each with a clear use case

5.5 Token Segment Cost-Effectiveness¶

5.6 Token Efficiency Rating¶

6. Boundary Analysis vs Claude Base Model Capabilities¶

6.1 Capabilities Base Model Already Has (No Skill Increment)¶

6.2 Base Model Gaps (Skill Fills)¶

7. Overall Score¶

7.1 Dimension Scores¶

7.2 Weighted Total Score¶

Test code quality increment is scored lower because Without-skill test code quality is not low — the skill’s core value lies in methodology discipline, not code generation.

8. Evaluation Materials¶