メニュー
Test-driven workflow: write failing tests first, verify red/green, cover edge cases, and keep the full suite green before merge. Use when implementing features, fixing bugs, or refactoring — before and alongside production code.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | code-testing |
| description | Test-driven workflow: write failing tests first, verify red/green, cover edge cases, and keep the full suite green before merge. Use when implementing features, fixing bugs, or refactoring — before and alongside production code. |
How to test code correctly — test-first when possible, always verify tests catch real failures, and stress edge cases until the suite is green. Complements code-writing (how to implement) and code-reviewer (pre-merge review).
Test commands and fixtures live in the repo's CLAUDE.md (e.g. pytest, npm test).
Core principle: If you did not see the test fail for the right reason, you do not know it tests the right thing.
Default (test-first):
Ask before skipping test-first:
Never skip tests entirely for production paths — at minimum add or extend tests before calling work done.
RED Write one minimal failing test (one behavior)
↓
VERIFY RED Run targeted test — must fail for expected reason (not typo/import error)
↓
GREEN Minimal production code to pass
↓
VERIFY GREEN Run targeted test + full suite — all green
↓
REFACTOR Clean up (no new behavior); stay green
↓
REPEAT Next behavior or edge case
One test, one behavior. Name states what should happen.
Good: clear name, asserts real behavior, minimal setup, uses real code paths.
Bad: vague name (test1), tests mock call counts instead of outcome, multiple
unrelated assertions, "and" in the name (split tests).
Prefer testing observable behavior (return value, raised error, side effect on real objects) over implementation details.
For numerical / research code, also assert: shapes, finfinite, known limits,
regressions against a reference value when available.
Run the single test (or smallest file):
pytest path/to/test_module.py::test_name -q
# or project equivalent from CLAUDE.md
Confirm:
Skipping VERIFY RED is the most common way to ship useless tests.
Write the simplest code that passes. No extra features, config knobs, or refactors outside scope (code-writing §3). Complexity is allowed when tests or requirements prove the simple version fails — document why.
If other tests break, fix before moving on.
Only after green: rename, dedupe, extract helpers. No new behavior without a new RED test.
After happy path, add tests for behavior your change touches:
| Category | Examples |
|---|---|
| Empty / minimal | zero length, None where allowed, single element |
| Boundaries | min/max, off-by-one, saturation |
| Invalid input | wrong type, out of range, malformed config |
| Failure modes | I/O error, missing file, timeout |
| Numerics | NaN, Inf, denormal, dtype/shape mismatch |
Loop: add test → verify red (if bug exists) or green (regression guard) → fix → full suite green. code-reviewer expects this coverage for changed code.
Do not fix bugs without a regression test unless the user explicitly waives it.
| Quality | Good | Bad |
|---|---|---|
| Scope | One behavior per test | Kitchen-sink test |
| Name | Describes expected behavior | test_foo, test_works |
| Subject | Real code path | Mock interaction only |
| Proof | Saw it fail, then pass | Written after code; passed first run |
| Edges | Explicit cases listed | Happy path only |
mock.assert_called() without checking outcomeIdeal: test-first. When code already exists:
Tests-after that pass on first run do not prove they catch regressions — add a deliberate break or mutation check when unsure.
| Problem | Try |
|---|---|
| Don't know how to test | Write desired API/assertion first; ask user; simplify interface |
| Test setup huge | Extract fixtures; simplify design |
| Must mock everything | Reduce coupling; inject dependencies |
| Numerical test unstable | Tight tolerances with justification; fixed seeds; reference values |
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks; test is cheap |
| "I'll test after" | Pass-on-first-run proves nothing |
| "I manually tested" | Not repeatable; no regression net |
| "Keep code as reference" | You'll adapt it; that's tests-after |
| "Deleting work is wasteful" | Unverified code is debt |
| Skill | Role |
|---|---|
| code-writing | Surgical impl; simplicity vs needed complexity |
| code-reviewer | Confirms suite green + edge coverage on diff |
Repo CLAUDE.md | pytest paths, markers (slow), GPU fixtures |
Workflow: code-testing (this skill) while implementing → full green suite → code-reviewer before merge.
Deep-read an academic paper and produce a durable, critical research note — not a loose summary. Use when given a paper title, DOI, arXiv ID, publisher/PDF/GitHub URL, or local PDF, or when asked to read closely, summarize, extract contributions, analyze experiments, critique, compare to related work, reproduce results, or maintain a paper-reading repository index. Works across fields (astro/physics, ML, bio, security, …); examples lean astro-ph but the workflow is general.
Remote, slice-level access to FLAMINGO HDF5 files on COSMA via the `hdfstream` Python module — no need to download whole snapshots. Covers install, server connection, navigation, dataset slicing, multi-slice batched reads, and integration with swiftsimio. Use when reading any FLAMINGO data product remotely.
FLAMINGO past-lightcone products: virtual observers, particle lightcones, HEALPix shell maps, integrated_maps, and halo lightcones. Use when building mock surveys, stacking Compton-y or lensing maps, or cross-correlating with observations.
Review code changes against requirements and quality standards before merge. Use when dispatching a review subagent, after major features, before merging, or when the user asks for a code review. Requires reading the actual diff.
Style and structure for research manuscript text: IMRaD, hourglass narrative, formal tone, topic sentences, reproducible Methods, captions that tell the story. Use when drafting or editing titles, abstracts, sections, captions, or reports.
Iterative VLM review of compiled LaTeX PDFs for layout clashes (text vs figures, tables, long equations). Use after the first compile or any float/equation edit; loop fix-recompile-recheck until no clashes remain.