Test

Input

• A behavior, bug, module, feature, failing test, or uncovered path to test.
• Use explicit input first; otherwise infer from context, recent edits, selected files, or branch.
• Safest default: identify public behavior and highest-risk paths before writing tests.

Workflow

1. Define behavior. Identify the public interface and the behavior that matters to the user.
2. Pick the first slice. Choose one narrow behavior that proves the path end to end.
3. Write or repair tests. Prefer behavior-facing tests over implementation-detail tests.
4. Use TDD when requested. Red: write one failing test. Green: write the smallest implementation that passes. Repeat by slice.
5. Refactor when green. Simplify duplication, names, and module shape after tests pass.
6. Validate. Run relevant tests, typecheck, lint, or build commands.

Output