Skip to content
Back to skills

Test First Development

ASecurity

Apply test-first discipline for behavior changes and bugfixes: define expected behavior, add or run a failing test, then implement minimally. Use when fixing bugs, changing logic, or adding features that need regression protection. Triggers: "bugfix", "TDD", "regression test", "behavior change", "add test".

  • 25 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 6, 2026
ai-agentsgotestingdebugginggitdocumentation

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add charlieviettq/awesome-agent-skill --skill test-first-development --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Test First Development?

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

Security grade badge for Test First Development
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/charlieviettq-test-first-development-awesome-agent-skill/badge)](https://www.skillsdirectory.com/skills/charlieviettq-test-first-development-awesome-agent-skill)

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: test-first-development
description: >
  Apply test-first discipline for behavior changes and bugfixes: define expected
  behavior, add or run a failing test, then implement minimally. Use when fixing
  bugs, changing logic, or adding features that need regression protection.
  Triggers: "bugfix", "TDD", "regression test", "behavior change", "add test".
---

# Test-first development

## When to use (default)

- Bug fixes with reproducible symptoms.
- Behavior changes in production code.
- Refactors where regression risk is non-trivial.

## When to relax (document why)

- Throwaway prototypes.
- Generated code with separate validation.
- Pure config or documentation-only changes.

## Workflow (RED-GREEN-REFACTOR)

1. **Define** expected behavior in one sentence.
2. **RED:** Add or identify a test that fails for the right reason (missing behavior, not typo). Run it and confirm failure.
3. **GREEN:** Minimal code to pass. Run the same test and confirm pass.
4. **REFACTOR:** Only after green; keep tests passing.
5. **Verify:** Run targeted tests, then broader suite if scope warrants.

For bugfixes: if production code was written before the failing test, treat as process violation—add the test, confirm fail, then fix.

## Good tests

- One behavior per test; name describes behavior.
- Prefer testing real code paths over heavy mocking.
- For bugs: test reproduces the reported symptom.

## Checklist before done

- [ ] New or updated test exists for the change
- [ ] Saw the test fail before the fix (bugfixes)
- [ ] Targeted tests pass
- [ ] No unrelated test failures introduced

## Testing anti-patterns

- Implement first, add tests only at the end for logic changes.
- Tests that pass immediately without proving anything.
- Vague test names (`test1`, `test_fix`).
- Heavy mocking that does not assert real behavior.
- Test-only methods or flags added to production code solely to make tests pass.
- Incomplete mocks that hide integration failures.

## Related

`systematic-debugging`, `test-failure-triage`, `verify-before-done`

*TDD discipline inspired by [obra/superpowers](https://github.com/obra/superpowers) (MIT).*

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…