test-driven-development
starsforks
How to install test-driven-development?
omnigentx/jarvis/test-driven-development
$npx -y skills add omnigentx/jarvis --skill test-driven-developmentWrite tests first, watch them fail, then write minimal code to pass. Use for all new features and bug fixes.
SKILL.md
| 1 | # Test-Driven Development (TDD) |
| 2 | |
| 3 | Adapted from [obra/superpowers](https://github.com/obra/superpowers/tree/main/skills/test-driven-development). |
| 4 | |
| 5 | ## Core Rule |
| 6 | |
| 7 | ``` |
| 8 | NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST |
| 9 | ``` |
| 10 | |
| 11 | If you wrote code before the test — delete it. Start over. No exceptions. |
| 12 | |
| 13 | ## Red-Green-Refactor Cycle |
| 14 | |
| 15 | ### RED — Write Failing Test |
| 16 | Write ONE minimal test showing what should happen. |
| 17 | - Clear, descriptive test name |
| 18 | - Tests real behavior, not mocks |
| 19 | - One assertion per test |
| 20 | |
| 21 | ### GREEN — Minimal Code to Pass |
| 22 | Write the **simplest** code that makes the test pass. |
| 23 | - No over-engineering |
| 24 | - No "future-proofing" |
| 25 | - Just enough to go green |
| 26 | |
| 27 | ### REFACTOR — Clean Up |
| 28 | Improve code quality while keeping tests green. |
| 29 | - Extract common patterns |
| 30 | - Improve naming |
| 31 | - Remove duplication |
| 32 | |
| 33 | ## When to Use |
| 34 | |
| 35 | **Always:** |
| 36 | - New features |
| 37 | - Bug fixes |
| 38 | - Behavior changes |
| 39 | |
| 40 | **Exceptions (discuss with team first):** |
| 41 | - Throwaway prototypes |
| 42 | - Configuration files |
| 43 | - Generated code |
| 44 | |
| 45 | ## Anti-Patterns |
| 46 | |
| 47 | - ❌ Writing tests after implementation |
| 48 | - ❌ Keeping "reference" code you wrote before tests |
| 49 | - ❌ Over-engineering with options/config nobody asked for (YAGNI) |
| 50 | - ❌ Testing mock behavior instead of real behavior |
| 51 | - ❌ Skipping the "watch it fail" step |
| 52 | |
| 53 | ## In Meeting Context |
| 54 | |
| 55 | When implementing with TDD in a meeting: |
| 56 | 1. Write the test first — show it in your `speak()` |
| 57 | 2. Run it — show it fails |
| 58 | 3. Write minimal implementation |
| 59 | 4. Run it — show it passes |
| 60 | 5. Report results to QE for review |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
