agentleFS
Sign inStart free
learner0408learner0408/Skills/test-case-writer/SKILL.md

test-case-writer

Skill0 starsChanged 3 months agoMITView on GitHub

Write test files for newly written code and features, run them, and report results. Use when asked to add tests, cover code with test cases, or write unit/integration tests after implementing code. Skip for reviewing existing tests, debugging failures, fixing code, or test plans without code.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. skinnerlee1225/enterprise-prd-toolkit★ 45same name
    2. ukkuru/testmetry-skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository6 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test plan documents without test files

    line 71

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Instructions

  1. Read conventions — project-local CONVENTIONS.md if present, else ~/.config/opencode/CONVENTIONS.md. Read ARCHITECTURE.md at the project root if it exists and map the target code to its modules.
  2. Determine the test framework — from CONVENTIONS.md, or inspect package.json / config files (e.g. vitest.config.ts, jest.config.js, Playwright configs). Match the existing project layout: co-located *.test.ts files or a __tests__/ directory, whichever is already used.
  3. Choose the scope — default to code that was just written: new files, the recent diff, or explicitly named functions. Use full-scope only when the user asks.
  4. Grill ONLY when necessary — resolve the test target, mocking strategy, and unit-vs-integration split from the code and config first. If they cannot be determined, load the grilling skill and ask the minimal number of questions needed. Otherwise decide from evidence and note the reasoning in the report. Do not grill for its own sake.
  5. Write the tests — unit tests for pure logic and isolated functions; integration tests where components interact. Use the project's patterns and mocks. Cover normal paths, edge cases, and failure cases.
  6. Execute the tests — run them with the project's test command scoped to the new files. Record which pass and which fail.
  7. Report, do not fix — output the report below. Do not modify or patch the code under test. Suggested fixes are handed to the coding agent to implement.

Output Format

## Test Summary
- Files written: [paths]
- Framework: [name + version]
- Scope: [newly written code | full project]
- Tests added: [count]

## Results
- Passing: [count] — [name or file list]
- Failing: [count] — [name or file list]

## Suggested Fixes (for coding agent)
### [Failed test / file]
- **File**: path/to/file.ts:42
- **Failure**: error message or assertion
- **Suggested fix**: what to change and why

Example

Input: "write tests for the new billing module" With a backend using Vitest and src/billing/ just added:

  • target src/billing/*.ts, co-located *.test.ts
  • tests covering createInvoice, applyDiscount, edge cases (negative totals, missing customer), failure path (payment declined)
  • run npx vitest run src/billing
  • report passing/failing counts and hand suggested fixes to the coding agent

Out of scope

  • Fixing or patching the code under test — suggested fixes go in the report for the coding agent to apply
  • Reviewing or debugging existing tests the skill did not write
  • E2E authoring unless explicitly requested
  • Test plan documents without test files

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free