Work Test

Work / 4. Test

Write meaningful tests for behavior the product genuinely promises or currently depends on. The testing rules below are binding.

Work directly in the parent conversation. Do not spawn agents or register a goal unless the user explicitly asks. Testing is implementation work: inspect first, show the plan, make the smallest justified edits, run the tests, and report the evidence.

Inspect before writing

Read the applicable project instructions, repository status and diff, implementation, existing tests and helpers, public APIs, consumers, and actual user flows. Identify the behavior users or current callers rely on. Do not invent requirements, hypothetical threats, or unrealistic edge cases.

If the user did not name a target, choose the smallest coherent feature or current change that can be understood and tested safely. State the scope. If no meaningful behavior is worth testing, stop and explain why; never add a test only to increase coverage.

Publish the test plan

Before editing, provide one entry per justified behavior in this exact format:

1. Behavior being protected
2. Why it matters
3. Test level: unit, integration, or end-to-end
4. Exact observable assertion

Keep the plan short. Prefer a small number of high-value tests in this order:

1. Core happy paths.
2. Realistic failure paths.
3. Important boundaries.
4. Previously broken behavior.
5. Data persistence, permissions, billing, authentication, or destructive actions when relevant.

Select meaningful tests

• Test observable behavior, not internal implementation details.
• Test negative behavior only when a real contract or regression needs protection.
• Prefer integration tests for interactions between modules owned by the project.
• Mock external boundaries only when necessary: network APIs, time, randomness, queues, email, payment providers, or databases.
• Use realistic inputs and fixtures. Keep tests deterministic and independent of execution order.
• Assert the actual result, persisted state, returned error, emitted event, or externally visible side effect.
• Keep each test focused on one behavior without splitting a simple workflow into redundant cases.

Do not test unrelated non-events, impossible states the code does not handle, speculative attack surfaces, framework or language behavior, trivial accessors, or library behavior. Do not reproduce the implementation inside the assertion. Do not mock the whole system and merely verify calls.

Implement

Use the repository's existing test framework, conventions, helpers, fixtures, and directory structure. Update obsolete tests when the current owned contract changed; do not retain compatibility tests for a superseded path.

Do not modify production code to satisfy an artificial test. If real behavior is difficult to test, explain the smallest justified production change before making it. Pause for user direction if that change alters public behavior or expands the requested scope.

When a justified test exposes a production bug, preserve and report the evidence. Fix it only when the request clearly includes the repair. Otherwise do not silently broaden test work into product changes or leave the repository with an unexplained failing test; report the exact regression test that should accompany the eventual fix.

Validate

Run the narrowest relevant test command first, then the appropriate broader suite. Re-run failures when useful and distinguish failures caused by this work from established or unrelated baseline failures. Do not claim the suite is green unless the command proves it.

Do not optimize for coverage percentage. Report coverage only when the user explicitly asks, and never use it as a substitute for confidence in real behavior.

Return

Use this compact handoff:

## Work / 4. Test

**Scope:** 

### Test plan
| Behavior | Why it matters | Level | Observable assertion |
|---|---|---|---|
| ... | ... | ... | ... |

**Tests added:** 
**Behaviors covered:** 
**Tests deliberately not added:** 
**Actual bugs discovered:** 
**Validation:** 
**Remaining gap:** 

Say complete, partial, or blocked plainly. Completion means every justified test was implemented and the reported validation ran. A no-change result may also be complete when inspection proves that no meaningful test is justified; say that explicitly instead of creating coverage work.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: xcaeser
• Source: xcaeser/work-skill
• License: MIT
• Homepage: https://skills.sh/xcaeser/work-skill

Install and usage instructions live in the source repository linked above.