| version | 2 |
| name | test-driven-development |
| description | 在实现功能、修复 bug 或改变可执行行为前使用;要求先定义失败验证或可观察验收,再做最小实现,最后用新鲜证据确认通过。 |
| allowed-tools | execute_command read_file list_directory |
Test-Driven Development
Purpose
Use this skill to keep implementation honest: prove the current behavior fails or is missing, make the smallest change, then prove the target behavior works.
It is a discipline for executable behavior, not a ritual that blocks every small documentation, frontmatter, or configuration cleanup.
When to Use
Use for:
- new executable features;
- bug fixes;
- behavior changes in scripts, plugins, workflows, jobs, APIs, or routing;
- refactors where behavior must remain stable.
Use a lighter verification path instead of full TDD for:
- pure documentation edits;
- skill frontmatter fixes;
- small memory/routing wording changes;
- formatting-only changes;
- configuration changes where an authoritative state query is the correct proof.
Core Loop
- Define the behavior
- State the expected behavior and the current failure or missing capability.
- Create a failing check
- Prefer an existing test command.
- If no test framework exists, use a small script, dry-run, grep assertion, parser check, or authoritative MoviePilot query that should fail before the fix.
- Verify red
- Run the check and confirm it fails for the expected reason.
- If it fails for setup/syntax reasons, fix the check first.
- Make the smallest change
- Change only what is needed to satisfy the behavior.
- Do not bundle unrelated cleanup.
- Verify green
- Re-run the same check and any minimal related regression checks.
- Refactor only if needed
- Keep the green checks passing.
Property And Invariant Checks
When unit tests are unavailable, define property-style checks for behavior that should always hold:
- parser/frontmatter inputs should preserve required fields and reject malformed structures;
- routing changes should keep the intended owner discoverable and avoid duplicate owners;
- plugin/config operations should preserve existing keys unless intentionally removed;
- media workflows should not confuse recognition, search, download, subscription, transfer, and library states;
- cleanup or file operations should never expand beyond declared scope.
Use generated or varied inputs only when safe and bounded. For MoviePilot operations, prefer read-only state queries and dry-runs over synthetic destructive tests.
MoviePilot Agent Adaptation
Acceptable checks include:
python -m py_compile or a focused script run;
- plugin capability/config queries after safe reload when authorized;
- scheduler/workflow/query tools for state behavior;
- skill/frontmatter structure assertions for Agent skill changes;
git diff/git status for repository hygiene;
- media/library/subscription/download state queries for MoviePilot behavior.
Do not force a unit-test framework where the repository or task does not have one. The important part is observable red/green evidence.
Safety Rules
- Do not use TDD to bypass confirmation for destructive or high-impact actions.
- Do not start downloads, delete files, change credentials, install/uninstall plugins, restart services, or trigger workflows merely to create a test without user consent.
- For risky operations, design a dry-run or read-only check first.
Output Contract
When this skill shapes the work, report:
- the failing check or baseline evidence;
- the smallest change made;
- the passing verification evidence;
- any remaining risk or skipped test with reason.