test-driven-development
A repo-local TDD workflow requiring failing tests before code implementation for Lambda functions.
Install
mkdir -p .claude/skills/test-driven-development-lynxpardelle && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15360" && unzip -o skill.zip -d .claude/skills/test-driven-development-lynxpardelle && rm skill.zipInstalls to .claude/skills/test-driven-development-lynxpardelle
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Repo-local TDD workflow for Zoolanding Lambda implementation work. Use before behavior-changing handler or helper code changes. Skip as the default path for docs-only or SAM-config-only edits.Key capabilities
- →Define a failing proof with a narrow test
- →Verify the proof fails for the correct reason
- →Write minimal code to satisfy the failing proof
- →Re-run the narrow proof to confirm pass
- →Run smallest adjacent regression check
- →Refactor code only after tests pass
How it works
This skill guides a Test-Driven Development workflow by first defining a failing test, then implementing the minimal code to make that test pass, and finally refactoring.
Inputs & outputs
When to use test-driven-development
- →Implementing handler logic
- →Writing unit tests for lambdas
- →Refactoring code safely
About this skill
Test-Driven Development
Write the failing proof first, then write the smallest code that makes it pass.
Default Scope In This Repo
Use this for:
- handler behavior changes
- helper logic changes
- request validation or response behavior changes
- storage-contract changes that can be pinned to a reproducible event
Do not treat this as the default path for:
- docs-only changes
- SAM-config-only changes with no behavior change
Workflow
-
Define the failing proof first.
- Add or update the narrowest test or local harness case that demonstrates the intended behavior change.
- If the repo lacks unit tests for the area, create the smallest reproducible event before implementation.
-
Verify the proof fails for the right reason.
- Confirm the failure matches the missing or broken behavior.
- Fix the test if it fails because of setup noise instead of the intended reason.
-
Write the minimal implementation.
- Change only the code needed to satisfy the failing proof.
- Avoid speculative helpers and unrelated cleanup.
-
Re-run the narrow proof.
- Confirm the targeted test or harness case now passes.
-
Run the smallest adjacent regression check.
- Add one nearby test or focused verification step when the change could break adjacent behavior.
-
Refactor only after green.
- Keep behavior unchanged while improving structure.
Repo-Specific Guidance
- Pair this skill with
karpathy-guidelinesfor scope control. - Use the existing local harness when a full unit test harness is not present.
When not to use it
- →When making docs-only changes
- →When making SAM-config-only changes with no behavior change
- →When the change does not alter handler or helper code behavior
Limitations
- →The skill is for handler behavior changes, helper logic changes, request validation or response behavior changes, and storage-contract changes
- →The skill requires writing a failing proof first
- →The skill requires running adjacent regression checks
How it compares
This skill enforces a specific TDD workflow for behavior-changing code, ensuring that every change is driven by a failing test, unlike a traditional code-first approach.
Compared to similar skills
test-driven-development side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| test-driven-development (this skill) | 0 | 3mo | No flags | Intermediate |
| chrome-devtools | 41 | 7mo | Review | Intermediate |
| obsidian-local-dev-loop | 3 | 29d | Review | Intermediate |
| testing | 5 | 2mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by LynxPardelle
View all by LynxPardelle →You might also like
chrome-devtools
mrgoonie
Browser automation, debugging, and performance analysis using Puppeteer CLI scripts. Use for automating browsers, taking screenshots, analyzing performance, monitoring network traffic, web scraping, form automation, and JavaScript debugging.
obsidian-local-dev-loop
jeremylongshore
Configure Obsidian plugin development with hot-reload and fast iteration. Use when setting up development workflow, configuring test vaults, or establishing a rapid development cycle. Trigger with phrases like "obsidian dev loop", "obsidian hot reload", "obsidian development workflow", "develop obsidian plugin".
testing
lobehub
Testing guide using Vitest. Use when writing tests (.test.ts, .test.tsx), fixing failing tests, improving test coverage, or debugging test issues. Triggers on test creation, test debugging, mock setup, or test-related questions.
cts-triage
gfx-rs
Run CTS test suites and investigate failures
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
playwright-browser-automation
lackeyjb
Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms, take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test websites, automate browser interactions, validate web functionality, or perform any browser-based testing.