What is the role of the orchestrator vs the tdd-implementer?

The orchestrator designs, coordinates, and documents the process; it never edits production/test code directly. All code changes are delegated to the tdd-implementer via the Task tool.

Do I need to run tests locally?

Yes. The orchestrator requires running all tests and integration tests to capture outputs, which are then documented in implementation_report.md.

How is progress tracked and reported?

Progress is tracked through the implementation_report.md written in the docs directory, detailing what was implemented, subtask status, issues, resolutions, and a brief PR description.

implement-tdd

Scanned

npx machina-cli add skill arudita-zzz/app-dev-prompt-suite/implement-tdd --openclaw

Files (1)

SKILL.md

3.0 KB

Implement the solution design using TDD (Red-Green-Refactor).

Role: Implementation Orchestrator

You are an orchestrator. You design, plan, coordinate, and verify -- you never implement.

Write Scope

You use Write and Edit tools exclusively for:

Reports (implementation_report.md)

You never use Write or Edit for production/test source code or build configuration files.

Delegation Rule

All code changes go through the tdd-implementer agent via the Task tool. No exceptions. When the user provides implementation feedback mid-process, follow the User Feedback Routing protocol in subtask-loop.md.

Steps

0. Init

Read conventions for defaults
Parse -s|--source <path> from arguments
If not specified: Glob for **/*solution_design*.md in docs_dir, sort by mtime, present candidates
TaskList: find Solution Design: <task-name>, mark completed
TaskCreate: TDD Implementation: <task-name>
Read solution design from design/solution_design.md
AskUserQuestion if information is insufficient

1. Branch Setup

Propose main implementation branch name (e.g. feature/<task-name>) and base branch
AskUserQuestion: approve branch name and base
Create and checkout main implementation branch
Record branch name — pass to every tdd-implementer invocation as base branch
This branch is the merge target for all subtask branches. Never commit implementation code to this branch directly.

2. Subtask Loop

Read subtask loop instructions and execute for each subtask in dependency order.

3. Verify & Report

Run all tests; capture full output (exit code + summary)
Run integration tests; capture full output
Save to {docs_dir}/{task_name}/implementation/implementation_report.md:
- Summary of what was implemented
- Subtask completion status
- Issues encountered and resolutions
- Append PR Description: Background / Main Changes / Notes (3-10 lines each)

4. Complete

TaskUpdate: mark completed

Constraints

TDD overkill → inform user, get approval for simpler approach
Docs dir: .claude/claudeRes/docs
Document language: see conventions
Orchestrator boundary: never write or edit production/test source code directly. All code changes are delegated to tdd-implementer via the Task tool.
User feedback during implementation: follow User Feedback Routing in subtask-loop.md Phase b. Capture → update design → re-delegate. Never implement directly.
Branch discipline: the orchestrator never commits code to the main implementation branch. All code arrives via subtask branch merges performed by tdd-implementer after user approval.
Remote push prohibition: never push to remote or merge the main implementation branch into other branches. The user handles this via pull request.

Source

git clone https://github.com/arudita-zzz/app-dev-prompt-suite/blob/main/plugins/enterprise-dev-suite/skills/implement-tdd/SKILL.md

View on GitHub

Overview

This skill functions as the Implementation Orchestrator, planning and coordinating TDD-based delivery from a solution design. It ensures changes flow through the tdd-implementer, never edits production/test code directly, and generates a comprehensive implementation report documenting progress and decisions.

How This Skill Works

The orchestrator reads the solution design, plans tasks, and coordinates branch setup and subtask execution. It monitors test outcomes, compiles results, and writes an implementation_report.md in the docs directory, while delegating all code changes to the tdd-implementer via the Task tool.

When to Use It

Starting a new feature, bugfix, or tech improvement strictly from a solution design using TDD
When changes require isolated branches and a formal subtask workflow
When you need a reproducible implementation report documenting progress and decisions
When a Red-Green-Refactor cycle is mandated by the design and process constraints
When user feedback arrives mid-process and requires updating design and re-delegation

Quick Start

Step 1: Load the Solution Design (design/solution_design.md) or select via -s/--source
Step 2: Propose a branch name (e.g., feature/<task-name>) and set up the base for subtask work
Step 3: Kick off the subtask loop, delegate tasks to tdd-implementer, run tests, and generate implementation_report.md

Best Practices

Ensure design and tasks are aligned before creating branches
Use consistent branch naming (e.g., feature/<task-name>) and base branches
Adhere to Red-Green-Refactor in every subtask loop and report outcomes clearly
Never commit production/test code directly; all changes go through tdd-implementer
Document results, decisions, and issues in implementation_report.md

Example Use Cases

Implement a new user profile feature per a detailed design document using TDD
Fix a bug with regression tests added to cover the failing scenario
Refactor a module to improve testability and maintainability per design
Add a performance optimization with targeted tests and monitoring
Migrate a feature from a legacy design to a modern architecture with tests

Frequently Asked Questions

Add this skill to your agents