Add missing test coverage for your local code changes by generating new test files (covers uncommitted and untracked changes, or the latest commit if everything is committed). Use when you want write tests for new logic or increase test coverage.

Cover Local Changes with Tests User Arguments User can provide a what tests or modules to focus on: If nothing is provided, focus on all changes in current git diff that not commited. If everything is commited, then will cover latest commit. Context After implementing new features or refactoring existing code, it's critical to ensure all business logic changes are covered by tests. This command orchestrates automated test creation for local changes using coverage analysis and specialized agents. Goal Achieve comprehensive test coverage for all critical business logic in local code changes. Important Constraints Focus on critical business logic not every line needs 100% coverage Preserve existing tests only add new tests, don't modify existing ones "Analyse complexity of changes" if there 2 or more changed files, or one file with complex logic, then Do not write tests yourself only orchestrate agents! if there is only one changed file, and it's a simple change, then you can write tests yourself. Workflow Steps Preparation 1. Read sadd skill if available If available, read the sadd skill to understand best practices for managing agents 2. Discover test infrastructure Read @README.md and package.json (or equivalent project config) Identify commands to run tests and coverage reports Understand project structure and testing conventions 3. Run all tests Execute full test suite to establish baseline Analysis Do steps 4 5 in parallel using haiku agents: 4. Verify single test execution Choose any passing test file Launch haiku agent with instructions to find proper command to run this only test file Ask him to iterate until you can reliably run individual tests After he complete try running a specific test file if it exists This ensures agents can run tests in isolation 5. Analyze local changes Run git status u to identify all changed files (including untracked files) If there no uncommited changes, then run git show name status to get the list of files that were changed in the latest commit. Filter out non code files (docs, configs, etc.) Launch separate haikue agent per changed file to analyze file itself, and the complexity of the changes, and prepare short summary of it. Extract list of files with actual logic changes Test Writing Simple Single File Flow If there is only one changed file, and it's a simple change, then you can write tests yourself. Following this guidline: 1. Read TDD skill for best practices on writing tests 2. Read the target file {FILE PATH} and understand the logic 3. Review existing test files for patterns and style, if not exists then create it. 4. Analyse which tests cases should be added to cover the changes. 5. Create comprehensive tests for all identified cases 6. Run the test command identified before. 7. Iterate and fix any issues until all tests pass Ensure tests are: Clear and maintainable Follow project conventions Test behavior, not implementation Cover edge cases and error paths Multiple Files or Complex File Flow If there are multiple changed files, or one file with complex logic, then you need to use specialized agents to cover the changes. Following this guidline: 6. Launch review:test coverage reviewer agents (parallel) (Sonnet or Opus models) Launch one coverage reviewer agent per changed file Provide each agent with: Context : What changed in this file (git diff) Target : Which specific file to analyze Resources : Read README and relevant documentation Goal : Identify what test suites need to be added Output : List of test cases needed for critical business logic Collect all coverage review reports 7. Launch developer agents for test file (parallel) (Sonnet or Opus models) Launch one developer agent per changed file that needs tests Provide each agent with: Context : Coverage review report for this file Target : Which specific file to create tests for Test cases : List from coverage reviewer agent Guidance : Read TDD skill (if available) for best practices on writing tests. Resources : Read README and test examples Command : How to run tests for this file Goal : Create comprehensive tests for all identified cases Constraint : Add new tests, don't modify existing logic (unless clearly broken) 8. Verify coverage (iteration) (Sonnet or Opus models) Launch review:test coverage reviewer agents again per file Provide: Context : Original changes + new tests added Goal : Verify all critical business logic is covered Output : Confirmation or list of missing coverage 9. Iterate if needed If any files still lack coverage: Return to step 5 Launch new developer agents only for files with gaps Provide specific instructions on what's still missing Continue until all critical business logic is covered 10. Final verification Run full test suite to ensure all tests pass Generate coverage report if available Verify no regressions in existing tests Success Criteria All critical business logic in changed files has test coverage ✅ All tests pass (new and existing) ✅ Test quality verified by coverage reviewer agents ✅ Agent Instructions Templates Coverage Review Agent (Initial Analysis) Developer Agent (Test Creation) Coverage Review Agent (Verification)

write-tests