tdd-workflow

Enforce test-driven development and consumer-driven contract checks across Go, Python, Rust, and TypeScript services.

9|4|Updated May 30, 2025
One-click install
npx skills add https://github.com/Kaikei-e/Alt --skill tdd-workflow-kaikei-e
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/Kaikei-e/Alt/tree/main/.claude/skills/tdd-workflow
Command: npx skills add https://github.com/Kaikei-e/Alt --skill tdd-workflow-kaikei-e

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents regressions and runtime failures caused by service boundary changes by enforcing a test-first, contract-first development discipline that combines end-to-end, consumer-driven contract (Pact) checks, and RED-GREEN-REFACTOR unit testing. It helps teams detect proto/API contract breaks, missing required headers, and auth changes early in CI rather than in production.

Core Features & Use Cases

  • Pact CDCT / E2E First: Detects service-boundary changes and requires consumer-side Pact tests before provider changes merge.
  • Phase-driven TDD: Guides developers through Phase 0 (contract check), Phase 1 (write failing tests), Phase 2 (minimal implementation), and Phase 3 (refactor and contract regression).
  • Multi-language support: Provides language-specific test and contract commands for Go, Python, Rust, and TypeScript and prescribes locations for contract tests and provider verification.
  • Operational safety playbook: Prescriptive steps for provider-tightening changes (enumerate consumers, audit pacts/, run pact-check.sh, runtime smoke tests) to avoid large-scale outages.
  • Use Case: When adding a required header or changing a proto, use this workflow to add consumer Pact tests first, regenerate pacts, and verify providers to prevent 401/TLS cascades.

Quick Start

Use the tdd-workflow to plan a contract-first TDD run for "add X-Service-Token requirement" by creating a consumer Pact test, regenerating pacts, and running provider verification before implementing code changes.

Frequently Asked Questions about tdd-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent API regressions when changing service boundaries across microservices?▼

To prevent API regressions when changing service boundaries, you need consumer-driven contract testing that requires consumer-side Pact tests to pass before provider changes merge, catching breaks early in CI.

What is the RED-GREEN-REFACTOR workflow for contract-first TDD?▼

The RED-GREEN-REFACTOR workflow for contract-first TDD is a phase-driven process: check contracts, write failing tests, implement minimal code, then refactor and run contract regression checks.

How do I add a required header to a proto without causing runtime failures?▼

To add a required header to a proto without runtime failures, create a consumer Pact test first, regenerate pacts, and run provider verification to detect 401 or TLS cascades before implementing code changes.

Does consumer-driven contract testing work with Go, Python, Rust, and TypeScript services?▼

Consumer-driven contract testing works with Go, Python, Rust, and TypeScript services by providing language-specific test commands and prescribing exact locations for contract tests and provider verification.

When should I use pact verification over standard unit testing for API changes?▼

You should use pact verification over standard unit testing for API changes when modifying service boundaries, tightening providers, or altering protos, ensuring consumer expectations are met before deployment.