Skip to content
Back to skills

Tdd

ASecurity

Practice test-driven development for new features and bug fixes.

  • 52 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 10, 2026
testingrails

Security analysis

A100/100

Scanned September 10, 2026

npx -y skills add g2i-ai/agents --skill tdd --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Tdd?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Tdd
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/g2i-ai-tdd/badge)](https://www.skillsdirectory.com/skills/g2i-ai-tdd)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: tdd
description: Practice test-driven development for new features and bug fixes.
---

# TDD

## Invocation

This skill is performed in the `Developer` persona. If you are not already running as `Developer` (for example, the user invoked `/tdd` directly), read `subagents/developer.md` and adopt its role guidance for the rest of this task. Stay in the current chat—do not delegate to a subagent.

## Objective

Use a red -> green -> refactor workflow for changes that should be test-first.

Use `/code` instead when the work is implementation-heavy but not centered on new automated test coverage, such as tooling, config, or linting work.

## Instructions

1. Determine whether the task is a bug fix or a new feature.
2. For new features, read the relevant spec or acceptance criteria before writing tests.
3. For bug fixes, capture the expected behavior, actual behavior, and reproduction path before writing tests.
4. Identify the most appropriate unit-level test location based on nearby repo patterns.
5. Write the failing test first.
6. Verify the red phase by running the relevant test suite.
7. Implement the smallest change needed to make the new test pass.
8. Re-run tests, then run the applicable verification checks (linting, type checking, etc.).
9. If the change also requires browser-flow validation, call out that E2E tests are relevant and why.
10. End with the test paths, the observed red failure, the passing result, and any follow-up work.

## Guardrails

- Do not create or modify E2E tests unless the user explicitly asks for E2E coverage.
- Keep TDD changes scoped to the behavior under test.
- Refactor only after the tests demonstrate the intended behavior.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.