cf-tdd

Solid

Use when writing new production code, adding features, implementing changes, or refactoring existing code — e.g. "implement this", "build this feature", "create a function", "add a new endpoint", "write the implementation", "refactor this", "clean up this code", "extract into a module", "simplify this function", "scaffold", "write a test", "add tests", "create a component", "implement the API", "add a route", "write a service", "create the handler". Also auto-invoke when the conversation transitions from planning/discussion to actual code writing — any time production code is about to be written, this skill MUST be loaded first. By default uses direct implementation (no new tests written). TDD is enabled when `--add-tests` is present or config `tdd: true`. This is the gate for all code writing in the project. Do NOT auto-invoke for documentation-only changes, config edits, non-code file updates, or when the user is only asking questions about code without requesting changes.

Testing & QA 3 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 79/100

Stars 20%
20
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Implementation Workflow > **CLI Requirement:** NONE — Works without `coding-friend-cli`. See [CLI requirements](../../../docs/cli-requirements.md) for the full matrix. ## Custom Guide Custom guide — auto-loaded below (if the raw command shows instead of its output, run it yourself): ```! bash "${PLUGIN_ROOT}/lib/load-custom-guide.sh" cf-tdd ``` If output is not empty, integrate returned sections: `## Before` → before first step, `## Rules` → apply throughout, `## After` → after final step. ## Mode Detection Determine the implementation mode BEFORE doing anything else: 1. Check if the user's invocation or task description contains `--add-tests` 2. Check if `.coding-friend/config.json` exists and has `"tdd": true` 3. Check if the user's invocation or task description contains `--auto` (orthogonal to mode — autopilot can combine with both Direct and TDD mode). **Result:** - `--add-tests` present OR `tdd: true` in config → **TDD mode**. Show: `> TDD mode enabled — RED → GREEN → REFACTOR`. → TDD mode: Read `${PLUGIN_ROOT}/skills/cf-tdd/modes/tdd-mode.md` now and follow RED→GREEN→REFACTOR. - Neither → **Direct mode** (default). Show: `> Direct mode — implementing without new tests` - Additionally, if `--auto` is present → **Autopilot active**. Show: `> 🤖 Autopilot enabled — will auto-review, auto-fix Critical+Important, and auto-commit after implementation.` ## Skip Conditions Check these BEFORE starting. If a skip condition is met, bypass the workflow entirely and p...

Details

Author
dinhanhthi
Repository
dinhanhthi/coding-friend
Created
5 months ago
Last Updated
today
Language
TypeScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Testing & QA Listed

tdd

Test-driven work in two modes. Default: real Test-Driven Development — red-green-refactor, one failing test at a time, used while implementing features (and by the work skill). With --debug: test-first debugging — generate all plausible root-cause hypotheses, write tests to validate each before touching production code, fix based on which tests fail, then sweep the codebase for the same pattern. Use for 'tdd', 'test-driven', 'write the test first', implementing with tests leading — and with --debug whenever the user reports a bug, unexpected behavior, or failed fix attempts and the root cause is unclear.

1 Updated 4 days ago
supermodo
Code & Development Solid

tdd

Write code through a disciplined, BDD-framed Test-Driven Development loop: build a behavior test list, then drive each behavior through red-green-refactor with an enforced observed-failure gate. Use when the user wants to implement, build, or write code test-first, "do TDD", follow "red-green-refactor", drive code from tests, choose the next test by the Transformation Priority Premise (TPP) or ZOMBIES ordering, or grow a feature behavior-by-behavior with tests leading. This skill writes and changes code; it does not produce a test plan document (use test-planning), review or audit existing code (use code-review), restructure existing code outside a TDD loop (use refactor), specify what a feature should do (use plan-a-feature), or find the root cause of a bug (use investigate).

128 Updated today
testdouble
AI & Automation Solid

tdd

Use test-driven development for behavior-changing feature or fix work, and whenever the user mentions TDD, test-first, red-green-refactor, tracer bullets, integration tests, or public-interface behavior tests. Skip for docs-only, path-only rename, formatting-only, or purely mechanical chores unless explicitly requested.

50 Updated 5 days ago
youdotcom-oss