Run any Skill in Manus with one click

test-first

Stars1

Forks0

UpdatedJuly 3, 2026 at 10:53

Enforces test-driven development - derive observable behaviors from the requirement, write failing tests first (including edge and negative cases), confirm they fail for the right reason, implement the minimum to pass, refactor green, and report red-to-green evidence. Never weakens assertions to make tests pass.

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

ianshank

ianshank/Agents

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

File Explorer

2 files

SKILL.md

readonly

name	test-first
description	Enforces test-driven development - derive observable behaviors from the requirement, write failing tests first (including edge and negative cases), confirm they fail for the right reason, implement the minimum to pass, refactor green, and report red-to-green evidence. Never weakens assertions to make tests pass.
when_to_use	Use when implementing a new feature, fixing a bug, or changing behavior in code that has (or should have) a test suite. Not for docs, config-only changes, or exploratory spikes the user explicitly marks as throwaway.

Test-First Implementation

Write the tests before the implementation, and let the failing tests specify the work.

Procedure

Derive behaviors. From the requirement, list the observable behaviors as input → expected output pairs (or state transitions / emitted effects). Include boundary values. If a behavior cannot be stated as observable, ask the user to clarify before writing anything.
Write failing tests. Using the repo's existing test framework and conventions, write unit tests covering the listed behaviors, including at least one edge case and at least one negative case (invalid input, error path, or forbidden state). Do not touch implementation code yet.
Confirm red for the right reason. Run the new tests and verify each fails with the expected failure mode — an assertion failure or missing-symbol error that points at the unimplemented behavior. A test failing due to a typo, bad import, or fixture error is not a valid red; fix the test and re-run. Record the failure output.
Implement minimally. Write the smallest implementation that makes the new tests pass. Resist adding behavior no test demands. Run the new tests plus the surrounding suite; all must pass.
Refactor green. With tests passing, clean up duplication and naming in both implementation and tests. Re-run the suite after each refactor step; never leave the suite red between steps.
Report red → green evidence. Summarize: the behaviors covered, the initial failing output (step 3), and the final passing run (steps 4–5), with the exact commands used.

Rules

Never weaken an assertion to make it pass. Do not broaden equality to containment, delete checks, mark tests skipped, or raise tolerances to absorb a failure.
If a test itself is wrong (misreads the requirement, asserts on incidental behavior), fix the test — and state the rationale for the change explicitly in your report, quoting the requirement it now reflects.
If the requirement changes mid-task, return to step 1 and re-derive behaviors; do not patch tests ad hoc.
Pre-existing unrelated test failures: note them, do not fix them silently, and do not let them block the red/green cycle for your change.

More from this repository

same repository

architecture-drift-guard

ianshank/Agents

Detect and block architecture drift in CI by comparing a codebase's actual Python import graph against a declared C4 component model. Use this whenever the user wants to enforce architecture in CI/CD, fail builds on undocumented dependencies, keep C4/Mermaid diagrams in sync with code, set up architecture tests or fitness functions, prevent layering violations, or guard/lint/gate their architecture — even if they don't name C4 or Mermaid explicitly. Also use it to bootstrap an architecture manifest from an existing repo or to remediate a failing drift check.

2026-07-071

eval-corpus-forge

ianshank/Agents

Build, validate, and package reusable evaluation datasets for agent and LLM systems from prompts, traces, tool-call logs, metadata, and expected outcomes. Use this when the user asks to gather eval data, create benchmark datasets, normalize traces, define reusable ground truth, bootstrap eval suites, or produce retrieval, tool-invocation, response, or end-to-end evaluation artifacts.

2026-07-071

model-bench

ianshank/Agents

Benchmark and A/B-test multiple LLMs or systems-under-test on one evaluation dataset. Use this whenever the user wants to compare models side by side, rank candidates by a score, run a multi-model comparison, set up a persistent A/B eval campaign, decide whether a new model is significantly better than a baseline, or produce a comparative HTML/JSON benchmark report.

2026-07-071

openai-judge

ianshank/Agents

LLM-as-a-judge evaluations over OpenAI-compatible APIs (including NVIDIA Nemotron & LM Studio). Use whenever evaluating output quality, correctness, or scoring responses using standard rubrics.

2026-07-071

c4-docs

ianshank/Agents

Generates or updates C4 architecture documentation as Mermaid diagrams in the host repo (docs/architecture/ by default, or the repo's existing docs location). Produces Level 1 context and Level 2 container diagrams, plus Level 3 components only for the subsystem being changed. Updates existing diagrams in place and flags drift between diagrams and code instead of silently rewriting them.

2026-07-031

code-review

ianshank/Agents

Runs a security and quality review checklist over a diff or named files in an isolated forked subagent. Covers injection, secrets, authz/authn, error handling, resource leaks, concurrency, compatibility, test coverage, and hardcoded config. Returns severity-ranked findings with file:line and a blocking/non-blocking/clean verdict. Read-only - never edits code or proposes inline fixes.

2026-07-031

name	test-first
description	Enforces test-driven development - derive observable behaviors from the requirement, write failing tests first (including edge and negative cases), confirm they fail for the right reason, implement the minimum to pass, refactor green, and report red-to-green evidence. Never weakens assertions to make tests pass.
when_to_use	Use when implementing a new feature, fixing a bug, or changing behavior in code that has (or should have) a test suite. Not for docs, config-only changes, or exploratory spikes the user explicitly marks as throwaway.

Test-First Implementation

Write the tests before the implementation, and let the failing tests specify the work.

Procedure

Derive behaviors. From the requirement, list the observable behaviors as input → expected output pairs (or state transitions / emitted effects). Include boundary values. If a behavior cannot be stated as observable, ask the user to clarify before writing anything.
Write failing tests. Using the repo's existing test framework and conventions, write unit tests covering the listed behaviors, including at least one edge case and at least one negative case (invalid input, error path, or forbidden state). Do not touch implementation code yet.
Confirm red for the right reason. Run the new tests and verify each fails with the expected failure mode — an assertion failure or missing-symbol error that points at the unimplemented behavior. A test failing due to a typo, bad import, or fixture error is not a valid red; fix the test and re-run. Record the failure output.
Implement minimally. Write the smallest implementation that makes the new tests pass. Resist adding behavior no test demands. Run the new tests plus the surrounding suite; all must pass.
Refactor green. With tests passing, clean up duplication and naming in both implementation and tests. Re-run the suite after each refactor step; never leave the suite red between steps.
Report red → green evidence. Summarize: the behaviors covered, the initial failing output (step 3), and the final passing run (steps 4–5), with the exact commands used.

Rules

Never weaken an assertion to make it pass. Do not broaden equality to containment, delete checks, mark tests skipped, or raise tolerances to absorb a failure.
If a test itself is wrong (misreads the requirement, asserts on incidental behavior), fix the test — and state the rationale for the change explicitly in your report, quoting the requirement it now reflects.
If the requirement changes mid-task, return to step 1 and re-derive behaviors; do not patch tests ad hoc.
Pre-existing unrelated test failures: note them, do not fix them silently, and do not let them block the red/green cycle for your change.