TDD Workflow
v1.0.0Test-driven development workflow enforcing 80%+ code coverage with unit, integration, and E2E tests. Write tests first, validate RED state, implement minimal...
⭐ 0· 99·2 current·2 all-time
byDeonte Cooper@djc00p
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
Name/description (TDD enforcing 80%+ coverage) aligns with the instructions and referenced patterns. Required binaries (npm, git) are appropriate for running tests and creating git checkpoints. No unexplained credentials, binaries, or config paths are requested.
Instruction Scope
SKILL.md gives explicit TDD steps (write tests, run npm test, commit at RED/GREEN, run coverage). It references unit/integration/E2E and includes mock examples for Supabase/Redis/OpenAI; these are illustrative. Caution: integration/E2E tests could be written to contact external services or databases in a real project, so inspect test code before running to avoid accidental production access.
Install Mechanism
No install spec and no code files are provided; the skill is instruction-only so it does not download or write artifacts to disk. This is the lowest-risk install posture.
Credentials
The skill itself does not request environment variables or credentials (none declared), which is proportional. However, real test suites in a repository may require DB/API credentials; the skill does not warn about that. Verify test runner configuration (package.json, test setup) and ensure tests run against isolated test/stub environments.
Persistence & Privilege
The skill is not always-enabled and does not request persistent presence or modify other skills. It instructs creating git commits in the local repo, which is expected behavior for a workflow tool.
Assessment
This skill appears to be what it says: a TDD workflow checklist and examples. Before you run it on a codebase: 1) review the repository's test files and package.json to see what npm test actually runs (look for scripts that run end-to-end tests or hit real services); 2) ensure tests run in an isolated test environment (use test databases, mock external APIs, or CI feature flags) so you don't leak or modify production data; 3) inspect any integration/E2E tests for hard-coded endpoints or credentials; 4) when running the workflow locally, confirm your git state and branch (the instructions create commits) or run in a disposable branch; 5) if you use CI, ensure secrets are scoped to test accounts. These precautions mitigate the main practical risk (accidentally running tests that talk to production systems), but the skill itself is coherent and non-malicious.Like a lobster shell, security has layers — review code before you run it.
latestvk972y9jd7ah5rksx5dqy8t1gh584908v
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
Runtime requirements
✅ Clawdis
OSmacOS · Linux · Windows
Binsnpm, git