Skip to content
cccskills
FreePublished on GitHub

tdd-workflow

Drive development with a red-green-refactor TDD cycle, ensuring tests are written before implementation. Use when implementing any new functionality.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md2.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

SKILL: TDD Workflow

The RED → GREEN → REFACTOR Cycle

RED Phase (QA Agent)

  1. Read the acceptance criterion or task description.
  2. Write a test that will fail because the implementation doesn't exist.
  3. Run the test. It MUST fail with a meaningful error (not a syntax error).
  4. If the test passes immediately → the test is wrong. Rewrite it.
  5. Report: file path, test name, failure message.

GREEN Phase (Specialist Agent)

  1. Read the failing test file at the provided path.
  2. Implement the MINIMUM code to make ONLY that test pass.
  3. Do not implement anything not required by the test.
  4. Run the test. It must pass.
  5. Run the full unit suite to verify no regressions.
  6. If the test fails after 3 attempts → escalate to Orchestrator.

REFACTOR Phase (Specialist Agent)

  1. Look for: duplication, poor naming, long functions, complex conditionals.
  2. Clean up without changing behavior.
  3. Run the test again. It must still pass.
  4. Commit: git commit -m "refactor: {what was cleaned up}"

ATDD Pattern (Acceptance Test-Driven Development)

  1. Write the E2E/acceptance test from the acceptance criterion (Given/When/Then).
  2. Watch it fail (RED).
  3. Drive out unit tests and implementation to make it pass (GREEN).
  4. Acceptance test goes green last.

Integration Test Container Lifecycle

# Before integration tests
docker compose -f docker-compose.test.yml up -d --wait

# Run integration tests
make test-integration

# After tests
docker compose -f docker-compose.test.yml down -v

Rules

  • Test file is created BEFORE implementation file.
  • Test name format: "should {expected outcome} when {condition}".
  • Never weaken an assertion to make a test pass.
  • Never mock what you can test with a real dependency (use containers).
  • Implementation agent receives FILE PATH, not requirement text.
  • Gate: test must fail before implementation, pass after.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Run WCAG 2.2 Level AA accessibility audits against generated UI. Use when a story has ui:true or when asked to audit accessibility.

The English summary is being prepared. Showing the original description.

kinncj/Heimdall70Updated Sep 2, 2026

Generate a complete component file tree wired to design tokens with tests and Gherkin spec. Use when scaffolding a new UI component.

The English summary is being prepared. Showing the original description.

kinncj/Heimdall70Updated Sep 2, 2026

Extract Gherkin scenarios from story markdown files into runnable .feature files and generate step definition stubs. Use when syncing stories to test suites.

The English summary is being prepared. Showing the original description.

kinncj/Heimdall70Updated Sep 2, 2026

Read and write design tokens in W3C DTCG format (tokens.json) and emit CSS, Tailwind, and Mantine outputs. Use when modifying or generating design tokens.

The English summary is being prepared. Showing the original description.

kinncj/Heimdall70Updated Sep 2, 2026

Apply Docker and Docker Compose best practices for containerising services. Use when writing or reviewing Dockerfiles and compose configs.

The English summary is being prepared. Showing the original description.

kinncj/Heimdall70Updated Sep 2, 2026

Identify and annotate cloud cost implications of architectural decisions. Use when reviewing infrastructure changes or designing new services.

The English summary is being prepared. Showing the original description.

kinncj/Heimdall70Updated Sep 2, 2026

See all skills by kinncj

Report a problem with this skill