Run any Skill in Manus with one click

write-tests

Stars3

Forks1

UpdatedJuly 4, 2026 at 14:45

Derives tests from acceptance criteria, writes a failing regression test before fixing a bug, runs the suite, and reports coverage of the specific behavior. Use when asked to "write tests", "add test coverage", "test this change", "write a regression test", or when implementing a feature or fixing a bug that ships without tests. Use before committing any behavior change.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

luminik-io

luminik-io/alfred

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	write-tests
description	Derives tests from acceptance criteria, writes a failing regression test before fixing a bug, runs the suite, and reports coverage of the specific behavior. Use when asked to "write tests", "add test coverage", "test this change", "write a regression test", or when implementing a feature or fixing a bug that ships without tests. Use before committing any behavior change.
license	MIT

Write tests

When to use

You implemented a feature and the acceptance criteria are not yet covered.
You are about to fix a bug (write the failing test FIRST).
A PR changes behavior but adds no test.
A reviewer asks "how do we know this works?".

This skill is about tests that verify the SPECIFIC behavior that changed, not about chasing a line-coverage number. A test that passes whether or not the code is correct is worse than no test.

Procedure

Restate the behavior under test in one sentence. If it came from a spec, quote the acceptance criterion. If it is a bug, state the wrong behavior and the correct behavior.
For a bug: write the regression test FIRST and run it. It must FAIL against the current code, reproducing the bug. A test that passes before the fix proves nothing. Only then write the fix and confirm the test flips to green.
For a feature: turn each acceptance criterion into at least one test. Cover the happy path, one boundary (empty, null, max), and one error path. Name each test after the behavior, e.g. test_widget_search_returns_empty_on_no_match.
Use the repo's existing test framework and fixtures. Read a neighboring test first and match its style; do not introduce a new runner or assertion library.
Run the full suite (for example npm test, pytest, or ./gradlew test depending on the repo), not just the new file, so you catch a regression the change caused elsewhere.
If a test is flaky or environment-dependent, fix the test's determinism (seed, clock, fixed input) rather than adding a retry or a sleep.

Output

The new or changed test files, each test named after the behavior it pins.
For a bug: a note confirming the regression test failed before the fix and passes after.
The suite result (pass count, any skips and why).
A short coverage statement in prose: which acceptance criterion or bug each test covers. Do not report a coverage percentage as if it were proof; report which behaviors are now pinned. Example: "GET /v1/widgets pagination is covered by 3 tests (page 1, last page, out-of-range page)."

More from this repository

same repository

add-observability

luminik-io/alfred

Adds structured logging at decision points, one metric per new outcome, and a trace span per new I/O boundary, all behind config-driven levels. Use when asked to "add logging", "make this observable", "add metrics", "instrument this", "add a trace span", or when shipping a feature or path that would be a black box in production. Use when a change adds a new outcome, branch, or external call that operators will need to see.

2026-07-043

changelog-and-release-notes

luminik-io/alfred

Reads the diff and writes a CHANGELOG entry in the repo's own voice, and bumps the VERSION when asked. Use when asked to "update the changelog", "write release notes", "add a changelog entry", "bump the version", or when a change is ready to ship and the CHANGELOG has not been updated. Use before or as part of shipping a user-visible change.

2026-07-043

migrate-dependency

luminik-io/alfred

Migrates a dependency to a target version by pinning it, reading the changelog for breaking changes, updating call sites, running the tests, and writing a migration note. Use when asked to "upgrade this dependency", "bump the version of X", "migrate to X v2", "update the library", or when a dependency is out of date, deprecated, or has a security advisory. Use before merging any dependency version bump.

2026-07-043

review-security

luminik-io/alfred

Reviews a change through a STRIDE-lite security lens (injection, authorization, secret handling, SSRF and egress) and reports concrete findings with severity and a fix. Use when asked to "security review", "check this for vulnerabilities", "review the auth path", "is this safe to merge", or when a change touches untrusted input, authentication, secrets, or outbound network calls. Use before merging any change on a trust boundary.

2026-07-043

spec-to-issues

luminik-io/alfred

Turns an approved spec or roadmap item into scoped, single-repo agent:implement issues with testable acceptance criteria and an explicit out-of-scope block. Use when asked to "break down this spec", "turn this into issues", "scope this roadmap item", "create implementation issues", or "plan the work for this feature". Use when a spec is approved and needs to become the tickets a fleet can pick up.

2026-07-043

code-review-and-quality

luminik-io/alfred

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

2026-07-033

name	write-tests
description	Derives tests from acceptance criteria, writes a failing regression test before fixing a bug, runs the suite, and reports coverage of the specific behavior. Use when asked to "write tests", "add test coverage", "test this change", "write a regression test", or when implementing a feature or fixing a bug that ships without tests. Use before committing any behavior change.
license	MIT

Write tests

When to use

You implemented a feature and the acceptance criteria are not yet covered.
You are about to fix a bug (write the failing test FIRST).
A PR changes behavior but adds no test.
A reviewer asks "how do we know this works?".

This skill is about tests that verify the SPECIFIC behavior that changed, not about chasing a line-coverage number. A test that passes whether or not the code is correct is worse than no test.

Procedure

Restate the behavior under test in one sentence. If it came from a spec, quote the acceptance criterion. If it is a bug, state the wrong behavior and the correct behavior.
For a bug: write the regression test FIRST and run it. It must FAIL against the current code, reproducing the bug. A test that passes before the fix proves nothing. Only then write the fix and confirm the test flips to green.
For a feature: turn each acceptance criterion into at least one test. Cover the happy path, one boundary (empty, null, max), and one error path. Name each test after the behavior, e.g. test_widget_search_returns_empty_on_no_match.
Use the repo's existing test framework and fixtures. Read a neighboring test first and match its style; do not introduce a new runner or assertion library.
Run the full suite (for example npm test, pytest, or ./gradlew test depending on the repo), not just the new file, so you catch a regression the change caused elsewhere.
If a test is flaky or environment-dependent, fix the test's determinism (seed, clock, fixed input) rather than adding a retry or a sleep.

Output

The new or changed test files, each test named after the behavior it pins.
For a bug: a note confirming the regression test failed before the fix and passes after.
The suite result (pass count, any skips and why).
A short coverage statement in prose: which acceptance criterion or bug each test covers. Do not report a coverage percentage as if it were proof; report which behaviors are now pinned. Example: "GET /v1/widgets pagination is covered by 3 tests (page 1, last page, out-of-range page)."