Proposal: make test-driven-development ecosystem-neutral with practitioner-validated references

## Context

This proposal was prompted by a public LinkedIn discussion with Renan França.

Renan noticed that, although `test-driven-development` is described as a
general development workflow, its examples and supporting material appear
specific to JavaScript and TypeScript. He asked whether the workflow had been
used and validated in a Java project.

Java is the context that surfaced the issue, but this is not intended to be a
Java-specific proposal. The broader question is whether the skill currently
represents TDD across software ecosystems or unintentionally assumes an
npm-based project.

LinkedIn discussion: [https://www.linkedin.com/feed/update/urn:li:activity:7482684721563508736/?dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287482933051820498944%2Curn%3Ali%3Aactivity%3A7482684721563508736%29](https://www.linkedin.com/feed/update/urn:li:activity:7482684721563508736/?dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287482933051820498944%2Curn%3Ali%3Aactivity%3A7482684721563508736%29)
## Current mismatch

The core TDD principles are ecosystem-independent, but the current execution
guidance is not:

- the RED, GREEN, and bug-reproduction examples use TypeScript;
- the final verification checklist hardcodes `npm test`;
- `references/testing-patterns.md` uses Jest, React Testing Library,
Supertest, and Playwright;
- the reference describes itself as covering patterns “across the stack,”
although it currently represents one ecosystem;
- the skill does not first require agents to discover the repository's
language, build system, test runner, wrappers, and existing conventions.

This may cause agents working in JVM, .NET, Python, Go, Rust, Ruby, PHP, and
other projects to receive irrelevant commands or testing patterns.

## Proposed direction

### 1. Keep one TDD skill

Keep the universal workflow in `test-driven-development/SKILL.md`:

- RED → GREEN → REFACTOR
- reproduce bugs with a failing test
- test observable behavior rather than implementation details
- choose an appropriate test level
- prefer deterministic and isolated tests
- run focused tests during development and the relevant suite before completion

Creating one TDD skill per language would duplicate the workflow, create
overlapping triggers, and allow the different versions to drift.

### 2. Make the core ecosystem-neutral

Before selecting commands or frameworks, require the agent to inspect the
repository for:

- language and runtime;
- build system;
- checked-in build wrappers;
- test framework and configuration;
- existing test directory and naming conventions;
- project documentation and CI commands.

Replace universal commands such as `npm test` with instructions to use the
repository's own focused-test and full-suite commands.

### 3. Treat the current examples as JavaScript/TypeScript guidance

Preserve useful Jest, React, Supertest, and Playwright material, but label it
accurately rather than presenting it as universal testing guidance.

The core skill should route agents to an ecosystem-specific reference only
after detecting the project's stack.

### 4. Add references through practitioner contributions

Rather than generating references speculatively, invite engineers who actively
work in different ecosystems to contribute or validate them.

Possible ecosystems include, without establishing an initial priority:

- JVM
- .NET
- Python
- Go
- Rust
- Ruby
- PHP
- JavaScript/TypeScript
- others represented by contributors

A reference should be added only when it is based on real project experience
and reviewed by someone who actively uses that ecosystem.

Useful evidence could include:

- real focused-test and full-suite commands;
- common build wrappers and project layouts;
- framework-specific test boundaries;
- integration-test and external-dependency strategies;
- common mocking and isolation mistakes;
- examples taken from or validated against real repositories.

## Suggested implementation phases

### Phase 1: ecosystem-neutral core

- audit npm/JavaScript assumptions;
- update the core workflow;
- make verification repository-aware;
- accurately label the existing JavaScript/TypeScript reference;
- add ecosystem-neutral behavioral eval coverage.

### Phase 2: practitioner-authored references

Add ecosystem references incrementally through separate focused PRs, each with
a named contributor or reviewer experienced in that ecosystem.

This avoids turning the initial change into a large collection of
AI-generated framework advice.

## Open questions

@addyosmani:

- Does keeping one ecosystem-neutral TDD skill match the intended direction
of the repository?
- Should the first PR only neutralize the core, leaving ecosystem references
to follow-up contributions?

@nucliweb:

- Given the recent discussion in #329 and #401, where should references used
only by this skill live?
- Should the existing `testing-patterns.md` become an explicitly
JavaScript/TypeScript reference, with other ecosystems added alongside it?

For the wider community:

- Which non-npm ecosystems are currently represented by contributors?
- Who would be interested in contributing or reviewing a reference based on
their day-to-day testing workflow?
- What evidence or review threshold should a reference meet before being
presented as battle-tested guidance?

## Acceptance criteria for the initial change

- [ ] The core skill makes no universal npm assumption.
- [ ] The agent inspects repository conventions before selecting test commands.
- [ ] Existing JavaScript/TypeScript guidance is preserved and labeled clearly.
- [ ] No ecosystem reference is presented as validated without practitioner
contribution or review.
- [ ] Behavioral evals verify that the skill adapts to repository tooling.
- [ ] Skill validation and existing evals pass.