Skip to content
Skills Library
Programming · Building & coding

test-driven-development

/test-driven-development

Write failing test BEFORE implementation, match project conventions from tea-rags search of existing test files (mocks, helpers, assertion style, fixture conventions) so new test fits local norms. Triggers on "write a test", "TDD", "напиши тест", "сначала тест", "failing test first", "RED phase", "implement feature X", "add test for Y", "fix bug Z". NOT for projects with no existing tests — fall back to superpowers:test-driven-development directly. Wraps superpowers:test-driven-development with tea-rags test-pattern search.

Repository
tearags-mcp ↗
Licence
MIT
Last repository change
18.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 18.10.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Write failing test BEFORE implementation, match project conventions from tea-rags search of existing test files (mocks, helpers, assertion style, fixture conventions) so new test fits local norms. Triggers on "write a test", "TDD", "напиши тест", "сначала тест", "failing test first", "RED phase", "implement feature X", "add test for Y", "fix bug Z". NOT for projects with no existing tests — fall back to superpowers:test-driven-development directly. Wraps superpowers:test-driven-development with tea-rags test-pattern search.

Triggers from the description

write a testTDDнапиши тестсначала тестfailing test firstRED phaseimplement feature Xadd test for Y
Original author description

Write failing test BEFORE implementation, match project conventions from tea-rags search of existing test files (mocks, helpers, assertion style, fixture conventions) so new test fits local norms. Triggers on "write a test", "TDD", "напиши тест", "сначала тест", "failing test first", "RED phase", "implement feature X", "add test for Y", "fix bug Z". NOT for projects with no existing tests — fall back to superpowers:test-driven-development directly. Wraps superpowers:test-driven-development with tea-rags test-pattern search.

How it works

  1. Iron Rule
  2. Step 1 — Frame the test intent
  3. Step 2 — Search proven test patterns (split queries)
  4. Step 3 — Extract pattern block
  5. Step 4 — Invoke superpowers:test-driven-development
  6. Red Flags — STOP and restart from Step 2
  7. Common Mistakes
Original SKILL.md headings · 237 lines, 1,571 words
SKILL.md preview
---
name: test-driven-development
description:
  Write failing test BEFORE implementation, match project conventions from
  tea-rags search of existing test files (mocks, helpers, assertion style,
  fixture conventions) so new test fits local norms. Triggers on "write a test",
  "TDD", "напиши тест", "сначала тест", "failing test first", "RED phase",
  "implement feature X", "add test for Y", "fix bug Z". NOT for projects with no
  existing tests — fall back to superpowers:test-driven-development directly.
  Wraps superpowers:test-driven-development with tea-rags test-pattern search.
---

# dinopowers: test-driven-development

Wrapper over `superpowers:test-driven-development`. Ensures RED-phase failing
test follows project's established test conventions (mock helpers, vi.mock
setup, assertion style, fixture location), not written from scratch.

## Iron Rule

**Two split queries on DSL test chunks MUST be made BEFORE writing the failing
test** — whenever project has DSL test chunks indexed:

- Step 2a — fixture conventions: `chunkType: "test_setup"` + `rerank: "proven"`
  (delegated to `Skill(tea-rags:tests-as-context)` recipe `fixture-lookup`)
- Step 2b — assertion / naming idioms: `chunkType: "test"` + `rerank: "proven"`

Correct filter (`chunkType: "test"`/`"test_setup"`, NOT file-level
`testFile: "only"`) + correct rerank (`"proven"` — battle-tested patterns) +
correct params (`level: "chunk"` — `proven` is file-level and would regroup
chunks per file; `metaOnly: false` to see actual test content) + correct
ordering (search BEFORE draft) = core value. No `filter` needed: the server
skips `proven`'s production default when `chunkType` / `testFile` select tests
(tea-rags server predating that → 0 results → add `filter: {}`).

If `Skill(tea-rags:tests-as-context)` Step 0 preflight returns SKIP (no
`chunkType: "test"` chunks — language has no AST test chunking; **currently
supported: TypeScript + JavaScript (Vitest/Jest/Mocha), Ruby (RSpec), Swift
(XCTest / swift-testing / Quick), Rust (#[cfg(test)] / #[test])** — see
`src/core/domains/language/<lang>/chunking/` (`test-scope-chunker.ts`,
`rspec-scope-chunker.ts`, `suite-recognition.ts`, `quick-scope-chunker.ts`);
canonical per-language list:
`.claude-plugin/tea-rags/rules/language-compatibility.md` (GENERATED)), fall
back to single `mcp__tea-rags__semantic_search` with `testFile: "only"` +
`rerank: "proven"` and state "file-level fallback — test chunks unavailable for
this language".

Swift's granularity depends on the framework. XCTest and swift-testing declare
cases as methods, so a `chunkType: "test"` hit is one `func testX()` /
`@Test func x()`, no ancestor setup spliced in. Quick is a describe/context DSL
and chunks per SCOPE, like Ruby: a hit is one `context "when overdue"` with its
ancestors' `beforeEach` spliced in. Fixtures + helpers →
`chunkType: "test_setup"` in both.

> **Maintainers:** new language gains AST test chunking → update the
> supported-languages list above AND the same lists in
> `tea-rags:tests-as-context` (Step 0 SKIP block) and `tea-rags:filter-building`
> (chunkType section). Canonical checklist:
> `.claude/rules/test-spec-chunking.md`.

If first test in project (no existing tests): skip pattern search, invoke
`superpowers:test-driven-development` directly. State it.

**Chaining rule:** see [CHAINING.md](../../CHAINING.md) — every dinopowers:X
redirects superpowers:X. NEVER bypass the wrapper.

**Index freshness:** see [FRESHNESS.md](../../FRESHNESS.md) and
`tea-rags/rules/index-freshness.md`. No background reindex hook. Linked
worktree: overlay serves uncommitted edits — never reindex for them. Main
checkout: incremental `mcp__tea-rags__index_codebase` BEFORE first tea-rags call
over code edited but not committed.

## Step 1 — Frame the test intent

From user request or in-progress feature, identify:

| Element                                           | Example                                                     |
| ------------------------------------------------- | ----------------------------------------------------------- |
| **Subject under test (SUT)** — symbol or behavior | `ChunkGrouper.group()`, "parallel subagent dispatch"        |
| **Implementation path (optional)**                | `src/core/domains/ingest/pipeline/chunker/chunk-grouper.ts` |
| **Expected test scope**                           | unit / integration / e2e                                    |
| **Mocking needs**                                 | filesystem? tree-sitter? qdrant client?                     |

Compose:

- `intent`: concise sentence (e.g. "ChunkGrouper groups overlapping chunks by
  startLine")
- `pathHint`: optional pathPattern scoping to test area (from implementation
  path)

## Step 2 — Search proven test patterns (split queries)

### Step 2a — Fixture conventions (mock setup, beforeEach, factory helpers)

Invoke `Skill(tea-rags:tests-as-context)` with:

```
recipe: "fixture-lookup"
intent: <Step 1 intent, focused on the SETUP shape this test will need>
```

Recipe internally issues `mcp__tea-rags__semantic_search` with
`chunkType: "test_setup"` + `rerank: "proven"` + `level: "chunk"` +
`metaOnly: false` (limit 6), returns top-K setup chunks with file:line + content
excerpt.

If recipe returns SKIP (DSL test chunks absent), fall back to ONE
`mcp__tea-rags__semantic_search` call:

```
path:        <your working directory>   ← tea-rags search-cascade "Addressing the Codebase"; never project alone
query:       <intent from Step 1>
pathPattern: <pathHint optional>
testFile:    "only"                ← FILE-LEVEL fallback when no DSL chunks
rerank:      "proven"              ← stable + old + low-bugFix
level:       "chunk"               ← proven is file-level; keep chunk content
limit:       8
metaOnly:    false
```

State explicitly: "DSL test chunks unavailable — file-level fallback in use".

### Step 2b — Assertion / naming idioms (describe-it style, expectation form)

Issue ONE direct `mcp__tea-rags__semantic_search`:

```
path:        <your working directory>
query:       <intent from Step 1>
pathPattern: <pathHint optional>
chunkType:   "test"                ← DSL leaf scenarios
rerank:      "proven"              ← battle-tested conventions
level:       "chunk"               ← proven is file-level; keep DSL leaves
limit:       8
metaOnly:    false
```

Skip Step 2b if Step 2a took file-level fallback path — file-level results
already cover both setup and scenarios mixed together.

### Why split queries

DSL test chunking emits two distinct chunk types per
`test-scope-chunker.ts:265,289` (leaf `it`/`test` blocks) and `:309,340,376`
(`beforeAll`/`beforeEach` setup). Querying separately:

- Returns setup conventions cleanly in 2a (no scenario noise)
- Returns assertion idioms cleanly in 2b (no setup noise)
- Allows different limits / scopes per dimension

`"proven"` preset calibrated for
`{stability: 0.3, age: 0.3, bugFix: -0.15, ownership: -0.05, similarity: 0.2}` —
surfaces tests that survived long without breaking = local convention.

Do NOT substitute:

| Wrong tool                                                             | Why wrong                                                                                                                              |
| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `semantic_search` with bare `testFile: "only"` (when DSL chunks exist) | Captures imports, helpers, non-DSL chunks as noise. `chunkType` is the precise filter when DSL chunks are indexed.                     |
| `pathPattern: "**/*.test.ts"` without `chunkType`                      | Works for TypeScript but misses `*.spec.ts`, `_test.go`, `_spec.rb` etc., AND still captures non-DSL noise. Use `chunkType: "test"`.   |
| Named preset `"relevance"` / `"recent"` / `"hotspots"`                 | `proven` is calibrated for "conventions to follow"; `recent` returns unstable drafts; `hotspots` returns flaky tests to avoid          |
| Custom rerank weights                                                  | `proven` preset already encodes the right weights; reinventing diverges from `tea-rags:data-driven-generation` Step 2                  |
| `mcp__tea-rags__hybrid_search`                                         | Same rerank, but its BM25 leg re-ranks by query-token overlap — signal scan wants semantic + signals                                   |
| `mcp__tea-rags__find_similar` on implementation file alone             | Finds structurally similar code, not tests that exercise similar behavior                                                              |
| Built-in Grep for setup or assertion patterns                          | Returns every occurrence; `proven` narrows to CONVENTIONAL uses                                                                        |
| Skipping the `tests-as-context` preflight                              | Without preflight, fallback path is unknown; you may issue a `chunkType: "test"` query that returns 0 on a non-DSL language by mistake |

Do NOT pass:

- `metaOnly: true` — need actual test body to extract conventions (mock setup,
  assertion style, helper calls); signal-only payload useless for TDD
- `filter` on test file paths — `chunkType` handles granularity; path filters
  restrict too tight

If both queries return 0 results (no existing tests, or none matching area):
report "no existing test patterns found — falling back to
`superpowers:test-driven-development` direct". Do NOT invent conventions.

## Step 3 — Extract pattern block

From top-K returned chunks, extract 4-6 concise bullets (NOT raw content):

- **Mock setup convention** (e.g.
  `vi.mock("node:fs", async () => { ...partial(), existsSync: vi.fn() })`)
- **Helper imports** (e.g.
  `import { createTempTestDir, defaultTestConfig } from "tests/core/domains/ingest/__helpers__/test-helpers"`)
- **`describe`/`it` naming style** (e.g. BDD "should X when Y" vs functional
  "X()")
- **Assertion idiom** (e.g. `expect(result).toEqual(...)`,
  `expect(fn).toHaveBeenCalledWith(...)`, snapshots, property-based)
- **Fixture location** (inline objects vs `__fixtures__/` files vs factory
  helpers)
- **Setup/teardown** (`beforeEach` vs `beforeAll`, cleanup patterns)

Cap bullets at 6. Cite proven test file each convention came from (e.g.
`tests/core/domains/language/ruby/chunking/rspec-scope-chunker.test.ts`).

If tea-rags returned fewer than 3 proven tests (thin corpus): note "small test
corpus — conventions inferred from <N> files only, may not be representative".

## Step 4 — Invoke superpowers:test-driven-development

Invoke `Skill` tool with `superpowers:test-driven-development`. Prepend pattern
block from Step 3 as context. Phrase handoff as:

> "Before writing the failing test, match these established conventions from the
> proven test corpus: …<block>… Deviate only if the new test genuinely needs a
> different pattern (document why).
>
> Chaining rule reminder: when your cycle would next invoke
> `superpowers:verification-before-completion` (or any wrapped `superpowers:Y`),
> invoke `dinopowers:Y` instead — see the Chaining rule section above."

Let `superpowers:test-driven-development` run its RED → GREEN → REFACTOR cycle.
This wrapper does not replace it — grounds RED draft in local conventions.

## Red Flags — STOP and restart from Step 2

- File-grouped results (`level: "file"` in the response) → `level: "chunk"`
  missing; redo
- "I know how tests look in this project" → run Step 2 anyway; memory stale
  across files
- "First test of a new module, no patterns needed" → if project has ANY tests,
  search broader corpus with no `pathPattern`
- Used `semantic_search` without `chunkType: "test"`/`"test_setup"` (when DSL
  chunks indexed) → redo; bare `testFile: "only"` captures import / helper noise
  that dilutes pattern signal
- Picked `rerank: "recent"` "to get latest conventions" → `proven` calibrated
  better; recent returns drafts
- Passed raw test code to `superpowers:test-driven-development` → extract
  pattern block first (6 bullets, not raw content)
- Started drafting failing test before Step 2 → revert, restart from Step 2
- Let `superpowers:test-driven-development` chain into raw
  `superpowers:verification-before-completion` without redirecting to
  `dinopowers:verification-before-completion` → intercept and invoke wrapper
  instead (see Chaining rule)

## Common Mistakes

| Mistake                                                        | Reality                                                                                                                  |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Search with `rerank: "hotspots"` thinking "find popular tests" | `hotspots` surfaces FLAKY tests (high churn + recent). Use `proven` (stable+old+low-bugFix).                             |
| Omit `chunkType: "test"`/`"test_setup"` filter (DSL projects)  | Returns implementation code or noisy test-file chunks. `chunkType` is the precise filter for DSL leaves and fixtures.    |
| Use `find_similar` on implementation symbol                    | Finds structurally-related production code, not tests that exercise it                                                   |
| Extract verbatim code snippets as "patterns"                   | Patterns are conventions (5-6 bullets), not copy-paste. Let `superpowers:test-driven-development` write the actual test. |
| Skip Step 2 if implementation doesn't exist yet                | Tests for the new feature should still follow project test conventions; run Step 2 on the broader corpus                 |
| Set `metaOnly: true` for a guard-style call                    | Guards want signals. TDD wants CONTENT (mock setup, assertions). Use `metaOnly: false`.                                  |

Versions

RepositoryScoreLicence
This page · artk0de/tearags-mcp100MIT
GanyuanRan/Aegis100MIT
lucasouzadev/agent-kit-skill100MIT
zeative/satgas100AGPL-3.0
nikospavlopoulos/devops-mutant-powers100MIT
JohnStrunk/CommonCast100LGPL
Sanit-mann/The-Insectoids100MIT
mastro993/fstack100MIT
jelvodev/yaap100MIT

Database snapshot: 13.11.2026 · package version fccaa97cf6db (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100dino-test-driven-development
    Write failing test BEFORE implementation, match project conventions from tea-rags search of existing tests (mocks, helpers, assertion style, fixtures) to fit local norms. Triggers on "write a test", "TDD", "напиши тест", "сначала тест", "failing test first", "RED phase", "add…
  • 100054-design-tdd
    Use when Java implementation work should be guided by Test-Driven Development, including maintaining a test list, choosing the next behavior, writing a failing test first, implementing only enough production code to pass, and refactoring while keeping tests green. This should…
  • 100writing-plans
    Author implementation plan; Affected Files section enriched per-file imports, churn, ownership, bugFixRate, taskIds from tea-rags — task decomposition reflects real impact+risk. Triggers on "write a plan", "draft implementation plan", "напиши план", "распиши задачи по файлам",…
  • 100test-first
    [Orbit 2.4.1 Implementation] Red → green → clean; test from a spec scenario; characterization test for old code. Use when: «TDD», «сначала тест», «напиши тесты», «красный-зелёный-рефакторинг»; test first, TDD, write tests before code.
  • 100tdd
    Test-driven development: the agent writes the failing test, then the code, one behavior at a time. Use when building a feature or fixing a bug test-first, or when the user says tdd, red-green, or test-first.
  • 100tdd
    Test-driven development. Use when building a feature or fixing a bug test-first, when the user asks for red-green-refactor, or when a change needs its tests written before its implementation.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.