Is tdd safe to install?

SaferSkills independently audited tdd (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.claude/skills/tdd/SKILL.md · 1 file

.claude/skills/tdd/SKILL.md2.2 KB · Markdown

name: tdd

description: "Implements features using strict test-driven development — red-green-refactor cycle. Writes a failing test first, then minimal code to pass, then refactors. Use when building features that need high reliability."

argument-hint: "[feature or function to implement]"

allowed-tools: Read, Grep, Glob, Bash, Write, Edit

Test-Driven Development

Detect Test Environment

!ls package.json pytest.ini pyproject.toml go.mod Cargo.toml *.csproj Gemfile mix.exs 2>/dev/null !find . -type f \( -name "*.test.*" -o -name "*.spec.*" -o -name "test_*" -o -name "*_test.*" \) -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null | head -5

The TDD Cycle

For the requested feature, repeat this cycle until complete:

RED — Write a Failing Test

Write the smallest possible test that describes the next piece of behavior
The test must import/reference the function or module (even if it doesn't exist yet)
Run the test — it MUST fail
Verify the failure message is meaningful (not just a compilation error)

GREEN — Make It Pass

Write the absolute minimum code to make the test pass
Hardcoding is acceptable at this stage — it will be cleaned up in refactor
Don't add functionality the test doesn't require
Run the test — it MUST pass
Run all related tests — nothing else should break

REFACTOR — Clean Up

Remove duplication in both production and test code
Improve naming, extract methods, simplify logic
Run tests after every refactoring step — they must stay green
Stop when the code is clean

Test Progression

Start simple, add complexity gradually:

Null/empty/zero case
Single item / simplest valid input
Multiple items / typical case
Edge cases / boundary values
Error cases / invalid input
Async / concurrent behavior (if applicable)

Output

Show each cycle clearly: RED (test code + failure), GREEN (impl + pass), REFACTOR
Display test runner output at each step
Final summary: all tests, coverage of the feature

Rules

NEVER write implementation before a failing test
NEVER skip the refactor step
One behavior per cycle — don't batch multiple features
If the test framework isn't set up, set it up first

tdd— agent skill

Is tdd safe to install?

Test-Driven Development

Detect Test Environment

The TDD Cycle

RED — Write a Failing Test

GREEN — Make It Pass

REFACTOR — Clean Up

Test Progression

Output

Rules

Audit the pieces. Scan the whole. Decide.