Tdd

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.claude/agents

.claude/skills

.github/CLAUDE.md

CLAUDE.md

apps/backend/CLAUDE.md

import { test, expect } from "../../fixtures/test-base";

apps/web/generated/licenses.json

Audit 0.4.1 · source sha 786d4817799e · 18 Oct 2026Report an issue or request a re-scan

• Publisherkdlbs GitHub organizationOwner of the repository this skill is read from
• Source folderkdlbs/kandev/.agents/skills/tddThe exact folder we audited
• LicenceAGPL-3.0As the repository states it
• Commit pinned for this verdict786d4817799eA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Implement changes using Test-Driven Development (Red-Green-Refactor). Use for code changes that need coverage or requested test-value audits.

---
name: tdd
description: Implement changes using Test-Driven Development (Red-Green-Refactor). Use for code changes that need coverage or requested test-value audits.
---

# TDD

## Execution Context

Use this procedure directly in the primary conversation for every code change,
regardless of size. The user may switch that conversation to the lower-cost
implementation model before beginning the Red-Green-Refactor cycle.

Implement code changes using strict Red-Green-Refactor. Iron law: **no production code without a failing test first.**

Wrote code before a test? Delete it. Start over from a failing test.

## Related skills

- **`/e2e`** — Follow this procedure when the current task needs Playwright E2E coverage.
- **`/pr-fixup`** — After the task-defined checks pass and the PR opens, use it
  only for CI or actionable reviewer findings.

## When to use

- Bug fixes — write a test that reproduces the bug before fixing
- New functions, methods, or utilities
- Refactoring existing logic that lacks tests

**Skip** for: pure UI components (we don't test React components), config files, generated code.

For UI rendering bugs, prefer extracting or using a pure helper and testing that helper. Add Playwright only when the behavior is truly visual or integration-level. Avoid adding React component tests just to assert DOM output; that does not match this project's testing convention.

## Test-value gate

Before adding or changing a test, answer these questions:

1. What observable behavior, invariant, or independent contract does it protect?
2. What credible regression makes its assertion fail?
3. Why does existing coverage miss that regression?
4. Does it require a production export, flag, or injection hook that only tests use?

Resolve a missing answer before writing the test. Prefer extending an existing
case over repeating the same contract. Give each contract a primary test owner
at the boundary that can expose its failure. Keep additional layers for distinct
transport, lifecycle, platform, or input-handler risks.

For test-only seams, first look for proof through an existing production boundary.
Keep necessary performance instrumentation only with a named invariant and no simpler proof.

For a requested test audit or consolidation, load [test-audit.md](references/test-audit.md).
Do not start a broad cleanup as part of ordinary TDD.

## Determine test scope

When implementing a UI work order, read its ASCII UI preview and linked plan
before changing the surface. Use the structural requirements to guide the
existing rendered checks; do not test ASCII whitespace or treat it as exact
pixel geometry. Keep any design revisions synchronized through
`docs/specs/guide/plans-and-work-orders.md#ascii-ui-previews`.

- **Go unit** (`apps/backend/`): test file next to source as `*_test.go`. Run:
  ```bash
  cd apps/backend && go test -v -run TestName ./internal/path/to/package/...
  ```
- **TypeScript unit** (`apps/web/lib/`): test file next to source as `*.test.ts`. Run:
  ```bash
  cd apps && pnpm --filter @kandev/web test -- --run path/to/file.test.ts
  ```
- **Web E2E** (`apps/web/e2e/`): follow `/e2e` when the current task needs Playwright tests.

For Go test fixtures, load [backend-tests.md](references/backend-tests.md).

Choose the right level:
- **Unit:** pure logic or isolated service behavior.
- **Integration:** handler/service/repository boundaries, SQLite-backed flows, filesystem behavior, or process boundaries.
- **E2E:** critical user-facing browser flows; keep these focused and use `/e2e`.

Prefer state/output assertions over interaction assertions. Mock only slow, nondeterministic, or external boundaries; use real implementations or fakes when they keep the test deterministic.

When one behavior has separate wheel, keyboard, touch, or pointer handlers,
inventory and test every handler with distinct branching. For input at a hard
boundary where the underlying position cannot change, dispatch the input event
or gesture directly. Cover the eligible direction at the boundary, the wrong
direction or off-boundary no-op, one physical gesture firing at most once, and
listener cleanup when the change adds subscriptions. An E2E case for one input
modality does not cover the other handler paths.

When a work order names an `AC-*` acceptance criterion, keep the mapping visible
in the test name or a nearby `@covers AC-...` comment. Do not copy the complete
requirement into the test.

For failure-path tests, inject the error at the boundary the production code claims to handle and exercise the real downstream call chain; do not short-circuit by mocking the handler under test.
When production code has a defensive nil/fallback branch or sanitizes an internal error into a public error, inject that alternate return at the interface boundary and assert the public result plus absence of internal details or sensitive content.
For a test asserting that a side effect does not occur, enable every prerequisite
that would otherwise cause it and add a positive control with the same setup to
prove the side effect is reachable. Observe the actual side effect, not a proxy
that can remain unchanged.

For parser, canonicalization, or sanitization tests, build fixtures from the
producer's exact serialized shape. Include boundary cases such as optional
whitespace, adjacent records, terminators without a newline, and malformed or
unclosed input; assert that untrusted content is removed or fails closed while
independent following content is preserved. A test-only normalized fixture can
pass while the real wire framing still fails.

### Cross-layer contracts

When adding or renaming a field that crosses backend, WebSocket, and frontend
boundaries, use `rg` to trace every producer, DTO, store upsert or partial
merge, reconnect/readiness handler, and consumer before editing. Add focused
coverage at the affected boundaries, including refresh/reconnect and an update
that omits the field, so a partial payload cannot silently d

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/kdlbs/kandev
git -C kandev checkout 786d4817799e

Works in

1. 2026-10-18
   !CAUTION B 89 / 100

   first audit · source 786d4817799e

Questions about Tdd

• github.com/kdlbs/kandev/tree/main/.agents/skills/tdd — the audited source at commit 786d4817799e and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology