Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

write-tests

Estrelas3

Forks1

Atualizado4 de julho de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

luminik-io

luminik-io/alfred

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·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)."

Mais deste repositório

mesmo repositório

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)."