test-driven-development
Build with Test-Driven Development
Teams often ship changes without proof that tests catch the intended behavior. This skill guides Claude, Codex, and Claude Code through a strict red, green, refactor workflow.
Install with my Agent
Copy this request to your Agent. It includes the canonical Skill page and manifest.
Review the Skillstore skill "test-driven-development" from https://skillstore.io/skills/cygnusfear-test-driven-development.md and its manifest at https://skillstore.io/api/skills/cygnusfear-test-driven-development/manifest. Verify the artifact. You may proceed after verification, subject to the environment's own policy.Your Agent should still show its plan and request any confirmation required by the security policy.
Agent-readable resources
Use these links when an AI agent, crawler, or script needs clean context instead of reading the full page.
Test it
Using "test-driven-development". Implement retry behavior for failed operations.
Expected outcome:
- A first failing test that expects three attempts before success.
- A minimal implementation plan that only satisfies that behavior.
- A refactor step after the focused test and related tests pass.
Using "test-driven-development". Fix empty email submissions being accepted.
Expected outcome:
- A reproduction test showing empty email input returns a validation error.
- A small validation change that makes the test pass.
- A note to keep edge cases covered before marking the fix complete.
Using "test-driven-development". Review tests that rely heavily on mocks.
Expected outcome:
- A list of assertions that test mock behavior instead of product behavior.
- Recommendations to use real components or lower-level test doubles.
- A simplified test structure that preserves meaningful side effects.
Security Audit
SafeThe static backtick findings are Markdown fences, inline examples, and routine npm test snippets, not executable Ruby backticks. The reconnaissance findings are ordinary TDD prose about tests passing and reading the bundled anti-patterns reference. No prompt injection, exfiltration intent, or malicious automation was found.
Risk Factors
⚙️ External commands (27)
Share & cite this report
Share the versioned assessment report, neutral badge, embed card, and citations. Skillstore reports evidence without deciding whether this Skill is safe.
Copy report link
https://skillstore.io/skills/cygnusfear-test-driven-development/audits/8?utm_source=security_passport&utm_medium=share&utm_campaign=versioned_reportMarkdown badge
[](https://skillstore.io/skills/cygnusfear-test-driven-development?utm_source=security_passport_badge)HTML badge
<a href="https://skillstore.io/skills/cygnusfear-test-driven-development?utm_source=security_passport_badge"><img src="https://skillstore.io/badges/skills/cygnusfear-test-driven-development/security.svg" alt="Skillstore security assessment" loading="lazy"></a>Embed card
<iframe src="https://skillstore.io/embed/skills/cygnusfear-test-driven-development.html" title="Skillstore Security Assessment" sandbox="allow-popups allow-popups-to-escape-sandbox" loading="lazy" referrerpolicy="no-referrer" width="420" height="180"></iframe>Academic citations (APA · BibTeX · CFF)
APA citation
Cygnusfear. (2026). test-driven-development security audit report (audit version 8) [Author version unspecified]. Skillstore. https://skillstore.io/skills/cygnusfear-test-driven-development/audits/8BibTeX citation
@techreport{cygnusfear-cygnusfear-test-driven-development-2026,
author = {Cygnusfear},
title = {test-driven-development security audit report (audit version 8)},
institution = {Skillstore},
year = {2026},
number = {8},
url = {https://skillstore.io/skills/cygnusfear-test-driven-development/audits/8},
note = {Author version unspecified}
}CITATION.cff
cff-version: 1.2.0
message: "If you use this Skill, cite its author and this versioned security audit report."
title: "test-driven-development security audit report (audit version 8)"
version: "unspecified"
type: report
authors:
- name: "Cygnusfear"
date-released: "2026-07-05"
url: "https://skillstore.io/skills/cygnusfear-test-driven-development/audits/8"
identifiers:
- type: other
value: "skillstore:cygnusfear-test-driven-development:audit:8"
description: "Skillstore immutable audit report identifier"
Compare variants
10 installable variantsEach author remains a separate installable skill. The recommended variant is ranked by Skillstore evidence.
Why this variant is first
dmjgilbert-test-driven-development
2026-09-09
obra-test-driven-development
2026-09-09
cycleaddict-test-driven-development
2026-09-09
cygnusfear-test-driven-development
2026-09-09
addyosmani-test-driven-development
2026-09-22
dyai2025-test-driven-development
2026-09-09
codingcossack-test-driven-development
2026-09-09
zhanlincui-test-driven-development
2026-09-09
sickn33-test-driven-development
2026-09-09
davila7-test-driven-development
2026-09-09
Skillstore Score
Why this score Evidence Confidence: HighWhat You Can Build
Add a Feature Safely
Write one failing behavior test, implement only enough code, and refactor after all tests pass.
Fix a Regression
Capture the bug with a failing test before changing code, then keep the test as future protection.
Improve Test Quality
Review mocks, test-only helpers, and vague assertions against concrete anti-pattern guidance.
Try These Prompts
Use the test-driven-development skill for this feature: [describe feature]. Start with one failing test and explain the expected failure before implementation.
Use the test-driven-development skill to fix this bug: [describe bug]. First write a failing reproduction test, then implement the smallest fix.
Use the test-driven-development skill while refactoring [area]. Confirm existing tests pass, make small changes, and keep behavior unchanged.
Use the test-driven-development and testing anti-pattern guidance to review this plan: [paste plan]. Identify missing failing tests and risky mocks.
Best Practices
- Watch each new test fail for the expected reason before writing production code.
- Keep each test focused on one observable behavior with a clear name.
- Refactor only after the focused test and related tests pass cleanly.
Avoid
- Writing production code before a failing test exists.
- Testing mocks instead of the real behavior users depend on.
- Adding methods to production classes only to support tests.
Frequently Asked Questions
When should I use this skill?
Can I use it with Claude, Codex, and Claude Code?
Does it run tests automatically?
Does it require a specific test framework?
What if I already wrote the code?
How does it help with mocks?
Developer Details
Author
CygnusfearLicense
MIT
Skillstore revision
r1
Version notice
The author did not declare a version.
Ref
7e9e368dc1a370f2040369ebcd0db06d90cb48e5
Maintenance freshness
7/18/2026
Usage
4 downloads · 300 views
File structure