hoangnguyen0403/common-tdd
skills/common/common-tdd/SKILL.md
Implements a strict Red-Green-Refactor loop to ensure zero production code is written without a prior failing test. Use when: creating new features, fixing bugs, or expanding test coverage.
$ install --global
skillsauthnpx skillsauth add hoangnguyen0403/agent-skills-standard common-tddInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jul 15, 2026, 3:26 AM56.6s9 files scanned
SKILL.md
- name:
- common-tdd
- description:
- Implements a strict Red-Green-Refactor loop to ensure zero production code is written without a prior failing test. Use when: creating new features, fixing bugs, or expanding test coverage.
Test-Driven Development (TDD) Standard
Priority: P0 (CRITICAL)
Iron Law: NO PRODUCTION CODE WITHOUT FAILING TEST FIRST. Code written before test MUST deleted. Start over.
Step 1: RGR Loop (Red-Green-Refactor)
[!TIP] Orchestration: If sub-agents are available, delegate each AC implementation to
specialist-tdd-implementer.
- RED: Write minimal failing test. Verify failure (Expected error, not typo).
- GREEN: Write simplest code to pass. Verify pass.
- REFACTOR: Clean up code while staying green.
Red Flags
- Stop if code exists before test: Delete it. Restart from RED.
- Stop if test passes first run: You tested old behavior.
- Stop if "tests after" appears: That is not TDD.
AAA Structure (Mandatory)
Every test must follow Arrange-Act-Assert:
- Arrange: Set up inputs, stubs, mocks, and expected values.
- Act: Call single unit under test.
- Assert: Verify output and side effects. One logical assertion per test. (See AAA Example for code structure).
Step 3: Verification & Thresholds
- Minimum Coverage: 80% (Stat/Func/Line), 75% (Branch).
- Mocks:
- Always mock: HTTP, Time/Date, Filesystem.
- Never mock: Fast internal services (<200ms), pure domain logic.
- See Test Runner Reference for environment-specific commands.
Step 4: Principles & Mocks
- Watch it Fail: Prove test works before writing code.
- Minimalism: Don't add features/options beyond current test (YAGNI).
- Isolation: Mock external APIs (HTTP) and Time.
- Realism: Prefer real DBs (test containers) and fast internal services (<200ms).
Rationalization Prevention
- "Too small to test": Small code still regresses. Write the test.
- "Manual testing is enough": Manual checks do not prove the RED step.
- "Keep code as reference": Pre-test code biases the implementation. Delete it.
- "Tests after are equivalent": Passing immediately proves little.
Verification Checklist
- [ ] Every new function/method failing test first?
- [ ] Failure message expected?
- [ ] Minimal code implemented passed?
- [ ] AAA structure followed?
- [ ] Coverage thresholds met?
Expert References
- AAA Example
- AAA Methodology
- Test Runners
- TDD Patterns
- Testing Anti-Patterns
Anti-Patterns
-
No test-after: Writing tests post-implementation defeats TDD. Delete and restart.
-
No assertion-free tests: test without assert not test.
-
No testing implementation: Test behavior and contracts, not internal calls.
-
A passing test alone is not enough: the failing test must demonstrate missing behavior before implementation.
Related Skills
hoangnguyen0403/common-operator-profile
testing
VerifiedTrustedCommunity
Infer the requesting operator's technical fluency from message content (never ask directly) and adapt register — business, hybrid, or technical — across SDLC workflow output. Use when starting sdlc, brainstorm-feature, plan-feature, verify-work, publish-notes, or session-report, or whenever a request's phrasing signals a non-technical or cross-stack operator.
524SKILL.mdUpdated Jul 12, 2026
hoangnguyen0403/database-transactions
documentation
VerifiedTrustedCommunity
Define transaction boundaries, locking, and consistency guarantees for multi-step writes. Use when designing atomic operations, retries, idempotency, or concurrent write behavior.
524SKILL.mdUpdated Jun 19, 2026
hoangnguyen0403/database-schema-design
development
VerifiedTrustedCommunity
Design relational or document schemas from access patterns, cardinality, and lifecycle. Use when modeling entities, choosing embed vs normalize, or shaping schema boundaries before implementation.
524SKILL.mdUpdated Jun 19, 2026
hoangnguyen0403/database-query-performance
data-ai
VerifiedTrustedCommunity
Diagnose database latency with explain plans, index ownership, and query-shape review. Use when a query is slow, an index is missing, or scans and N+1 patterns appear.
524SKILL.mdUpdated Jun 19, 2026