Write Tests Agent Skill
Write failing tests from requirements. Invoke for each todo before /implement.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/huggingface/OpenEnv --skill write-testsThe instruction itself
9 sections, as written by the author/write-tests
Write failing tests that encode acceptance criteria.
Usage
/write-tests
/write-tests Add logout button to header
When to Use
- After creating a todo that requires implementation
- Before running
/implement - When you have clear acceptance criteria
When NOT to Use
- Implementation already exists (tests would pass immediately)
- You're exploring or prototyping (not TDD mode)
- Just adding to existing test coverage
What It Does
- Analyzes the current todo/requirement
- Reads existing tests to understand patterns
- Writes test files that verify acceptance criteria
- Verifies tests FAIL (proves they test something real)
- Returns test file paths for
/implement
Output
The tester agent will produce:
## Tests Written
### Files Created/Modified
- `tests/test_client.py`
### Tests Added
| Test | Verifies |
|------|----------|
| `test_client_reset_returns_observation` | Reset returns valid observation |
| `test_client_step_advances_state` | Step mutates state correctly |
| `test_client_handles_invalid_action` | Error handling for bad input |
### Verification
All tests FAIL as expected (no implementation yet).
### Next Step
Run `/implement` to make these tests pass.
Rules
- Read existing tests first to understand patterns and conventions
- Test behavior, not implementation - write from user's perspective
- Integration tests first, then unit tests if needed
- Each test verifies ONE thing clearly
- Run tests to verify they fail before returning
Anti-patterns (NEVER do these)
- Writing tests that pass without implementation
- Testing implementation details instead of behavior
- Writing overly complex test setups
- Adding implementation code (that's
/implement's job) - Writing tests that duplicate existing coverage
Completion Criteria
Before returning, verify:
- Tests compile/run successfully (pytest can collect them)
- Tests FAIL (no implementation yet)
- Test names clearly describe what they verify
- Tests follow existing project patterns (see
tests/for examples)
Other skills for the same job
different authors, same section of the catalogue
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Prepares and structurally reviews readiness evidence for ISO management-system and laboratory-competence standards - ISO 13485 medical device QMS, ISO 14971 device risk management, ISO/IEC 17025 testing and calibration laboratories, and ISO 15189 medical laboratories. Use when organizing declared scope, controlled documents, risk-management files, scope of accreditation, traceability, CAPA, external-provider controls, or bounded local evidence manifests, and when separating ISO certification from laboratory accreditation, FDA QMSR inspection, CLIA certification, MDSAP, and EU MDR/IVDR evidence boundaries. Not for legal applicability, compliance, certification, or accreditation decisions; contains no clause text.
Sample-size and statistical power calculations for planning studies. Use whenever someone asks "how many subjects/samples/replicates do I need", wants an a priori power analysis, a minimum detectable effect (MDE), a power curve, or needs to justify a sample size for a grant, IRB protocol, or pre-registration. Covers closed-form power for t-tests, ANOVA, proportions, correlations, chi-square, and regression, plus simulation-based (Monte Carlo) power for designs with no formula — logistic/Poisson regression, mixed models, cluster-randomized trials, survival, and interactions. Use this skill even when the request only mentions an effect size, alpha, or "80% power" without saying "power analysis" explicitly. For laying out the study (randomization, blocking, factorial/DOE, crossover, sequential designs) use experimental-design; for analyzing data already collected and reporting it use statistical-analysis.
Universal QA checklist for generated scientific plots: overlapping labels, clipped text, missing axes/legends, overcrowded data, and cross-journal resolution/format guidance.
Senior Elite Software Engineer (15+) and Senior Product Designer. Full workflow with planning, architecture, TDD, clean code, and pixel-perfect UX validation.
Run PinchBench benchmarks to evaluate OpenClaw agent performance across real-world tasks. Use when testing model capabilities, comparing models, submitting benchmark results to the leaderboard, or checking how well your OpenClaw setup handles calendar, email, research, coding, and multi-step workflows.
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Verify PowerToys behavior end-to-end with the winapp CLI across two scenarios: (A) a module's release checklist against the installed build; (B) PR validation — derive each PR's checklist from its description + diff, then drive it against the installed build (a merged/shipped PR, or a whole release/hotfix set) or by building + sideloading the module when the PR isn't in the build yet (unmerged or not-yet-released). Drive each item via UIA invoke / Named Events / settings.json edits / clipboard / GPO / SendInput, and emit a structured PASS / FAIL / BLOCKED verdict per item with evidence (FAIL distinguishes product defects from stale/ambiguous checklist items). Use when asked to verify a module checklist, validate a PR, sign off a release/hotfix's PRs, or QA installed/sideloaded PowerToys bits. Combines generic winapp ui mechanics (references/winapp-ui-testing.md) with PT-specific recipes, per-scenario playbooks (references/scenarios/), and the helper .ps1 files shipped with this skill.
How to use it
Take huggingface/write-tests from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.