Add unit test

Skill tmj-90/gaffer/runner/skills/add-unit-test

Self-hosted AI coding factory — sandboxed agents deliver tickets to merged code, gated by a human in a dashboard. Local-first, cost-transparent, human-in-the-loop.

Install

npx -y skills add tmj-90/gaffer --skill add-unit-test

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when a ticket asks for new unit tests, or when an acceptance criterion requires test coverage for a function/module/component and none exists. Invoke for "add tests for X", "cover the Y edge case", or raising coverage on a specific unit.

SKILL.md

2.6 KB, as published. Nobody here has run it

Add a unit test

Add focused, behaviour-asserting unit tests for the unit named in the ticket — matching the repo's existing test framework and conventions, not introducing a new one.

Steps

Find the unit + its existing tests. Locate the source file and any sibling test file. Read 1–2 existing tests in the repo to copy the framework, naming, and assertion style (Vitest/Jest/pytest/JUnit — use what's already there).
Enumerate behaviours to cover from the ticket/AC: the happy path, each meaningful branch, boundary values, and the error/throws cases. Prefer behaviour ("returns empty array when no match") over implementation detail.
Write tests in the repo's test location and naming convention, one assertion focus per test, Arrange-Act-Assert. No test without a real assertion; no over-broad mocks that assert nothing.
Run the test command (use the repo's test script — see the context packet's verification commands). Iterate until green. If a test reveals a real bug, note it; fix only what the ticket scopes.
Evidence: the test command + its passing summary, and the new test file paths. Then use the record-evidence skill to record test_output against the AC and submit for review.

TypeScript specifics

Async functions: await the call and assert on the resolved value, or use await expect(fn()).rejects.toThrow(...) for the failure path — never leave a floating promise, or the test passes before the assertion runs.
A meaningful assertion pins the observable outcome: the returned value, a thrown error, or a call made to a genuine collaborator with the expected arguments. Asserting that a mock you fully control was called (expect(mock).toHaveBeenCalled() with no argument or outcome check) tests the mock, not the unit — prefer a real return/throw assertion over an empty mock check.
Fake time and randomness (vi.useFakeTimers() / seeded RNG) so timing- or random-dependent behaviour is deterministic rather than flaky.

Rules

Match existing conventions; do not add a new test framework or runner.
Tests must assert behaviour and fail if the behaviour breaks.
Keep scope to the ticket — don't refactor source unless the AC requires it.
Run on a branch (the create-branch skill); never on a protected branch.