feat: Adopt batch-red TDD findings; remove strict TDD option

[bdfinst]

Overview

Adopt all findings from the competitive analysis of claude-flow's batch-vs-strict-TDD experiment (see .dev-team-reports/competitive-analysis-batch-vs-strict-tdd-2026-08-01.md). The experiment demonstrated that batch-per-class testing is 46% cheaper and 61% more efficient while maintaining equivalent code quality.

Key insight: Plan quality drives code quality, not implementation discipline. For agent-driven development, strict row-by-row TDD is unnecessary overhead.

Changes

1. Introduce Batch-Red-Verified Gate

• File: skills/batch-red-verification/SKILL.md (new)
• File: knowledge/batch-red-protocol.md (new)
• Add optional batch-red-verified gate to /build step 4
• After test design completes, verify all designed tests fail before implementation begins
• Document trade-off: ~46% cost savings vs. loss of per-behavior cognitive scaffolding
• Integrate with plan-review-acceptance agent

2. Explicit Upstream Plan-Quality → Code-Quality Connection

• File: Update agents/orchestrator.md
• File: Update knowledge/request-processing-flow.md
• Add explicit routing rule: if plan-review score is below threshold, escalate to human before /build begins
• Surface the core finding: "Plan quality determines code quality. If the plan is weak, no implementation cadence will save it."
• Add this to handoff skill's context summarization

3. Cost-Efficiency Decision Tree

• File: knowledge/test-cadence-tradeoffs.md (new)
• Document empirical findings (46% cost, 61% fewer test runs)
• Provide decision framework: when to use batch-red vs. Code-First Small Batches
• Connect to decision-defaults.md for Orchestrator routing
• Include local measurement approach using .claude/metrics/

4. Update Agent Guidance

• Update agent context to reference plan quality as primary quality driver during review
• Modify plan-review agents to explicitly call out weak plan findings
• Surface the finding: "Every substantive finding is upstream of the developer"

5. Remove Strict TDD Option

• Deprecate: skills/test-driven-development/SKILL.md — remove from registry and marketplace
• Alternative: If strict TDD remains useful for human-driven learning, create skills/tdd-for-learning/SKILL.md with explicit positioning: "For humans learning test-first discipline, not for agent-driven implementation"
• Update /test-design and /build documentation to remove references to strict row-by-row TDD as standing discipline
• Remove the strict TDD skill from orchestrator routing entirely

6. Add Measurement Infrastructure (Optional but Recommended)

• Use existing .claude/metrics/ to measure cost/efficiency locally
• Validate claude-flow's 46% claim in this codebase across representative builds
• Document measurement methodology in cost-efficiency decision tree

Acceptance Criteria

• Batch-red-verified gate implemented and documented
• Plan-quality upstream connection explicit in Orchestrator guidance
• Cost-efficiency decision tree published with measurement approach
• Strict TDD removed from standing options; option explicitly unavailable in /build
• Agent guidance updated to surface plan quality as primary determinant
• Migration guide created for users currently using strict TDD (if any)
• All changes tested end-to-end in /build workflow
• Documentation updated to reflect new test-batching strategy

Implementation Notes

Priority order:

1. Explicit plan-quality connection (small, high-impact)
2. Batch-red gate (medium, 46% savings)
3. Cost-efficiency decision tree (guides user choice)
4. Remove strict TDD (completes migration)

Estimated complexity: Large (5–7 story points across all changes)

Related: Competitive analysis report at .dev-team-reports/competitive-analysis-batch-vs-strict-tdd-2026-08-01.md

---

Appendix: Full Competitive Analysis Report

Competitive Analysis: dev-team vs Batch-per-Class TDD Findings

Date: 2026-08-01
Target: claude-flow experiment "Batch vs Strict TDD" — findings on cost efficiency and quality parity of batch-red-per-class vs strict row-by-row TDD for LLM-driven code generation
Tool versions: Not applicable — no tool version applies to a comparison.
Scope: Development workflow efficiency, test-batching strategy, code quality gates, and agent-driven TDD discipline
Source type: Experiment findings (URL: https://github.com/chiaradiamarcelo/claude-flow/blob/b33f197b2fae370689486857990ea0d358757652/docs/findings/12-batch-vs-strict-tdd.md)

Executive Summary

Claude-flow's batch-vs-strict-TDD experiment found that batch-per-class testing was 46% cheaper and 61% more efficient (fewer test runs) while maintaining equivalent code quality (mutation testing parity). The key insight: plan quality (upstream, pre-implementation) drives code quality, not inner-loop discipline. This challenges the assumption that strict row-by-row TDD (cognitive scaffolding for humans) is necessary for agent-driven code generation. Dev-team's current stance — optional strict TDD advisory + practical Code-First Small Batches cadence — aligns partially with these findings but lacks three critical elements: (1) explicit batch-red-verified gate, (2) cost-efficiency optimization guidance, and (3) upstream plan-quality connection to downstream code quality.

Capability Comparison

Test-Driven Development Workflow

Capability	dev-team	claude-flow	Classification
Strict row-by-row RED-GREEN-REFACTOR	Optional advisory skill (test-driven-development) for explicit user request or post-hoc auditing	Not used (replaced by batch-per-class)	Different approach
Code-First Small Batches cadence	Primary cadence in /build — IMPLEMENT → TEST → REFACTOR per behavior	Baseline before experiment; found to be suboptimal	Different approach
Batch-per-class testing strategy	No explicit batching strategy decision tree; test approach merged into broader test-design guidance	Experimentally validated; adopted as standing rule	Missing (dev-team)
Pre-RED validation gate	No explicit "batch-red-verified" gate ensuring tests fail before implementation	Mandatory gate; all class tests must fail before implementation begins	Missing (dev-team)
Cost optimization for test cadence	No cost/efficiency analysis; TDD and Code-First Small Batches treated as independent choices	46% cost reduction; 61% fewer test runs documented; used to justify strategy change	Missing (dev-team)
Plan-quality-to-code-quality connection	Plan review exists (/plan critics), but not explicitly surfaced as the primary determinant of code quality	Explicit finding: "every substantive finding is upstream of the developer" — plan quality drives outcome	Weaker (dev-team)

Test Review & Verification

Capability	dev-team	claude-flow	Classification
Post-GREEN review agents	Yes — refactor-opportunity-review + complexity-review on changed files, bounded 3-iteration fix loop	Implied by mutation-testing parity finding; validation built into plan phase	Different approach
Mutation testing for quality assurance	Yes — /mutation-testing command, mutation-kill agent for survivor reduction	Used in experiment to prove quality parity across batching strategies	Different approach
Test design advisor	Yes — test-design-advisor skill for forward-looking design recommendations	Part of plan phase (test-designer role); upstream to implementation	Different approach

Workflow Architecture

Capability	dev-team	claude-flow	Classification
Role separation (test-designer vs developer)	Implicit in QA Engineer vs Software Engineer; no explicit role-lock per phase	Explicit phases: test-designer designs all tests for a class, developer implements	Weaker (dev-team)
Plan verification before implementation	Spec-compliance-review gate; plan critiqued by design/strategic/parallelization/acceptance agents	Batch-red verified + plan quality explicit prerequisite	Different approach
Cognitive scaffolding vs. plan-driven execution	TDD advisory acknowledges human scaffolding need; agents follow Code-First Small Batches	Explicit hypothesis: agents execute pre-designed plans, not discover them; scaffolding unnecessary	Different approach

Gap Specs

Gap 1: Batch-Red-Verified Gate

Classification: Missing (dev-team)
Layer: Skill / Workflow gate
Priority: High

What claude-flow does:
Enforces a mandatory "batch-red-verified" gate before implementation begins. All tests for a unit (e.g., a class) are written first, verified to fail, then implementation proceeds. This gate ensures vacuity verification (test suite doesn't pass trivially) without row-by-row latency.

What we have now:
Dev-team's /build workflow runs Code-First Small Batches: IMPLEMENT → TEST → REFACTOR, with inline review gates after GREEN. Tests are designed during planning (/test-design), but there is no explicit pre-implementation batch-failure check. Individual behaviors are tested row-by-row, not batched per unit.

Proposed addition:

• Type: Workflow enhancement + knowledge file
• File: skills/batch-red-verification/SKILL.md (new) + knowledge/batch-red-protocol.md (new)
• Description: Add an optional "batch-red-verified" gate for /plan and /build. When enabled, after test design is complete for a unit (class, module, behavior set), verify all designed tests fail before implementation begins. This is a one-time bulk-failure check, not a per-behavior gate. Document the trade-off: batch-red reduces cost (~46% from claude-flow) while maintaining quality parity, at the cost of losing immediate per-behavior cognitive scaffolding. Connect this to plan-quality as the upstream quality driver.
• Dependencies: Integrates with /test-design, /build workflow, plan-review-acceptance agent (which verifies test expectations)
• Estimated complexity: Medium (new gate in /build step 4, new knowledge file, decision tree for when to use)
• Model tier: Haiku (the gate is deterministic: run tests, check exit code)

---

Gap 2: Cost-Efficiency Guidance & Decision Tree

Classification: Missing (dev-team)
Layer: Knowledge file + Orchestrator routing
Priority: High

What claude-flow does:
Empirically measured cost/efficiency tradeoffs (46% cost reduction, 61% fewer test runs). Used this data to justify switching the standing cadence from Code-First Small Batches to batch-per-class. Provides a decision framework: when to batch, when to remain row-by-row.

What we have now:
Dev-team documents Code-First Small Batches as the only standing cadence but offers no cost/efficiency comparison, no measurement approach, and no decision tree for when a user or orchestrator should choose batch-red over Code-First Small Batches.

Proposed addition:

• Type: Knowledge file + Orchestrator decision logic
• File: knowledge/test-cadence-tradeoffs.md (new)
• Description: Document the empirical findings from claude-flow (and any internal measurements dev-team wants to add). Provide a decision tree: (1) When is plan quality uncertain? → Use Code-First Small Batches (higher scaffolding). (2) When is plan quality high-confidence? → Consider batch-red-verified (lower cost). (3) What's the cost multiplier for this codebase? (measure via /build metrics). Connect to decision-defaults.md so the Orchestrator can recommend cadence based on plan confidence score.
• Dependencies: Integrates with /plan (plan-quality gate), /build (cadence selection), performance-metrics knowledge
• Estimated complexity: Medium (literature review + local measurement framework)
• Model tier: Opus (decision tree involves multiple tradeoff dimensions)

---

Gap 3: Explicit Upstream Plan-Quality → Code-Quality Connection

Classification: Weaker (dev-team)
Layer: Orchestrator routing + Agent guidance
Priority: High

What claude-flow does:
Core finding: "Every substantive finding is upstream of the developer." This means plan quality (architecture, test design, acceptance criteria) is the primary determinant of code quality, not the implementation discipline (row-by-row red-green vs. batch-red). The experiment controlled for this by fixing the plan and varying only the test cadence, then showed mutation-testing parity — proving it's the plan, not the cycle.

What we have now:
Dev-team has plan critics (plan-review-strategic, plan-review-design, plan-review-acceptance), but they are peer-reviewed by the Orchestrator during /plan, not explicitly surfaced as the primary quality driver. The TDD skill and Code-First Small Batches cadence imply that implementation discipline matters equally. No agent guidance explicitly states: "If the plan is weak, no implementation cadence will fix it."

Proposed addition:

• Type: Agent guidance + Orchestrator routing logic
• File: Update agents/orchestrator.md + knowledge/request-processing-flow.md
• Description: Add explicit routing rule: if plan-review score is below threshold (flagged findings in design/strategic/acceptance), escalate to human before /build begins. Surface the claude-flow finding in Orchestrator's phase-2-to-phase-3 transition: "Plan quality determines code quality. If the plan is weak, no implementation cadence will save it." Recommend users to invest in plan quality before optimizing for test-cadence cost. Include this in the handoff skill's context summarization (what goes from plan phase to build phase).
• Dependencies: Integrates with /plan critiques, plan-quality scoring (could leverage existing Farley Score or create new metric), human-oversight-protocol
• Estimated complexity: Small (routing logic + messaging; no new gates, just explicit prioritization of existing gates)
• Model tier: Haiku (routing decision)

---

Gap 4: Role Lock for Test-Designer Phase

Classification: Weaker (dev-team)
Layer: Workflow orchestration
Priority: Medium

What claude-flow does:
Explicit role separation: test-designer role designs all tests for a class, developer role implements. This enforces batch design before batch implementation and may improve test quality by separating concerns.

What we have now:
Dev-team has QA Engineer and Software Engineer roles, but /test-design is advisory (no lock preventing the same agent from writing code immediately after). /plan can specify test strategy, but implementation and test design happen together in Code-First Small Batches per behavior.

Proposed addition:

• Type: Optional Orchestrator routing enhancement
• File: Update agents/orchestrator.md + skills/test-design/SKILL.md
• Description: Add an optional "role-lock" mode for batched test design (triggered when batch-red gate is used). When enabled, QA Engineer design phase outputs a test-design artifact (Gherkin + test pseudocode) that Software Engineer must use before writing code — cannot modify test design. Then Software Engineer implements against the frozen test design. After /build, an optional "role-unlock" relaxes this for refactoring. This is optional, not mandatory, since it adds orchestration overhead; document it as a quality-assurance mode for high-risk work.
• Dependencies: Integrates with /plan output, /test-design output, /build input, handoff skill
• Estimated complexity: Medium (new Orchestrator routing path, artifact format for frozen test design)
• Model tier: Haiku (routing decision)

---

Gap 5: Mutation Testing as Standing Quality Gate

Classification: Different approach
Layer: Workflow gate
Priority: Medium

What claude-flow does:
Used mutation testing to verify quality parity across batching strategies. Mutation score was the proof that batching didn't degrade quality.

What we have now:
Dev-team offers /mutation-testing command and mutation-kill agent for survivor reduction, but mutation testing is opt-in, not a standing gate. It's not part of the default /build → /code-review flow.

Proposed addition (note: this is a "different approach" item — no new spec, but a tradeoff analysis):

Mutation testing as a standing quality gate (e.g., in /code-review or before merge) would provide empirical proof that test suites actually validate behavior. However, this trades off speed (mutation runs are expensive) for certainty (high mutation score = high confidence tests will catch bugs). Dev-team's current approach (mutation testing on demand, mutation-kill for specific survivors) is pragmatic: it avoids the cost tax on every build but lets users verify quality when high confidence is critical. If batch-red-verified is adopted, consider adding mutation testing as an optional /build checkpoint (similar to optional role-lock) for high-risk work, since batch-red's cost savings create room in the budget for mutation verification. Document the tradeoff: "Batch-red saves ~46% cost; mutation testing verifies the savings don't reduce quality — use together for high-assurance batches."

---

Different Approaches Worth Examining

Code-First Small Batches vs. Strict Row-by-Row TDD

Dev-team currently uses Code-First Small Batches (IMPLEMENT → TEST → REFACTOR per behavior) as the only standing cadence, while offering strict TDD as optional. Claude-flow's experiment suggests this is correct: batch-red is more efficient, quality-equivalent, and preferred for agent-driven development. However, dev-team hasn't fully committed to this finding — the TDD skill is still presented as advisory guidance.

Tradeoff analysis:

• Code-First Small Batches: Lower cost, faster wall-clock per behavior, allows implementation-driven test discovery
• Strict TDD (row-by-row): Cognitive scaffolding (useful for humans learning), upfront design clarity, but 46% more expensive
• Recommendation: The findings strongly suggest dev-team should further de-emphasize strict TDD for agent-driven implementation and lean harder into batch-red or Code-First Small Batches. However, strict TDD remains valuable for human-driven development (learning, exploratory work, high-risk refactoring). Propose an explicit routing rule: if a human is driving /build (not an agent), offer TDD as an option; if an agent is driving, default to Code-First Small Batches or batch-red. This requires detecting human vs. agent context, which may not be feasible in the current orchestrator.

---

Our Strengths

Dev-team does several things better than the findings imply:

1. Comprehensive post-GREEN review: Dev-team's refactor-opportunity-review + complexity-review on every GREEN provides guardrails that strict TDD alone doesn't offer. Claude-flow's mutation parity may partly depend on this discipline.

2. Multi-phase plan review: Dev-team's five plan-review critics (strategic, design, parallelization, acceptance, UX) provide proactive quality checks before implementation. Claude-flow mentions plan quality as upstream but doesn't detail how to ensure it; dev-team has a framework.

3. Automated role separation: Dev-team's agent dispatch (QA Engineer for test design, Software Engineer for implementation) provides role separation without manual lock-in, reducing cognitive load and coordination overhead.

4. Cost measurement infrastructure: Dev-team has hooks and metrics collection (performance-metrics skill, .claude/metrics/) to measure cost empirically. This enables local validation of claude-flow's 46% claim.

5. Mutation testing on demand: Offering mutation testing as an opt-in tool (not a mandatory gate) allows users to verify quality when needed without burning tokens on every build. This is pragmatic.

6. Context ceiling discipline: Dev-team's 40% context ceiling (enforced by context_ceiling_guard.py) prevents the agent fleet from bloating — a constraint claude-flow's findings didn't address but which affects cost directly.

---

Top 5 Priorities

Rank	Gap	Layer	Complexity	Why
1	Batch-red-verified gate	Workflow	Medium	Directly implements claude-flow's standing rule; 46% cost savings is transformational. High impact for users running /build at scale.
2	Explicit upstream plan-quality connection	Orchestrator + guidance	Small	Shifts user mindset from "fix via implementation discipline" to "fix via plan quality"; requires only routing logic + documentation, no new agents. Quick win.
3	Cost-efficiency decision tree	Knowledge	Medium	Enables users to choose between batching strategies based on plan confidence, codebase, and budget. Fills the "when to use which" gap. Supports both options.
4	Upstream plan-to-code connection in agent guidance	Agent guidance	Small	Make the claude-flow finding visible to agents so they call it out during plan review and orchestrator hand-off. Minimal effort, high awareness.
5	Optional mutation testing in /build	Workflow	Medium	When batch-red savings are realized, users want proof quality didn't regress. Mutation testing provides that proof. Lower priority because it's already available via /mutation-testing command.

---

Next Steps

1. Immediate (week 1): Implement Gap 2 (explicit upstream plan-quality → code-quality connection) and Gap 3 (cost-efficiency guidance). These are small, high-impact, and require no new gates — just documentation and routing tweaks.

2. Short-term (week 2–3): Implement Gap 1 (batch-red-verified gate). Start with knowledge file + optional flag in /build, then add Orchestrator routing. This unblocks the 46% cost savings.

3. Medium-term (month 2): Implement Gap 4 (role-lock) as an optional, high-assurance mode. Run internal experiments to validate that dev-team's plan-review infrastructure provides equivalent quality control to claude-flow's test-designer role.

4. Long-term (month 3): Reconsider the positioning of the test-driven-development skill. If batch-red and Code-First Small Batches are proven equivalent/superior for agent-driven work, either:

   • Deprecate the strict TDD skill in favor of a "TDD for human-driven work" variant, or
   • Reposition it as a "learning and exploration" tool, not a default recommendation

5. Measurement: Use the existing .claude/metrics/ infrastructure to measure cost/efficiency locally across a representative sample of builds. Compare dev-team's Code-First Small Batches + batch-red results to claude-flow's findings to validate (or refute) the 46% claim in this codebase.

---

Provenance

• Repository: bdfinst/agentic-dev-team
• Branch / SHA: main / (current session)
• Run parameters: /dev-team:competitive-analysis with source: https://github.com/chiaradiamarcelo/claude-flow/blob/b33f197b2fae370689486857990ea0d358757652/docs/findings/12-batch-vs-strict-tdd.md
• dev-team plugin version: 11.3.0

[github-actions]

⚠️ This issue title is not a Conventional Commit.

Specs become epics and plan slices become sub-issues, and these titles seed branch names, PR titles, and release versions — so they must follow the same commitlint ruleset as commits (for example: feat:, fix:, docs:, chore:).

�[90m⧗�[39m   --- input ---
�[1mAdopt batch-red TDD findings; remove strict TDD option�[22m
�[31m✖�[39m   subject may not be empty �[90m[subject-empty]�[39m
�[31m✖�[39m   type may not be empty �[90m[type-empty]�[39m

�[1m�[31m✖�[39m   found 2 problems, 0 warnings�[22m
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

Edit the title to fix; this check re-runs on every edit and clears the label once it passes.