菜单
Use when asked to set up tests or a test runner for a project that has none - installs a test runner and one smoke test so behavior checks become a command, without requiring full coverage
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | test-runner-setup |
| description | Use when asked to set up tests or a test runner for a project that has none - installs a test runner and one smoke test so behavior checks become a command, without requiring full coverage |
This is a standalone helper skill. It sits outside the SPP pipeline state machine — it does not read or write docs/spp/pipeline-state.md, and it is not a numbered phase or a phase checkpoint. It runs whenever asked, triggered by its own description, independent of any pipeline in progress.
A project with no test runner has exactly one way to check behavior: read the code, run it by hand, and trust your own eyes. That's a real fallback, but it doesn't scale — every check has to be repeated by hand, and it's easy to skip "just this once." This skill closes that gap by turning "checked the behavior" into a command: install a runner, add one smoke test, get it green.
This feeds the TDD phase directly. Once a runner exists and one test passes, "behavior check" for the next slice can be an automated test instead of a documented manual walkthrough. That's the whole point — not full coverage, a working command.
Check what's already in the project first — if a test runner is already a dependency, use it, don't add a second one.
If nothing is installed, pick the standard runner for the stack:
pytest for Python). Don't improvise a custom test harness when a standard one exists.Versions and install commands drift — check the runner's current docs before installing rather than assuming last year's flags still apply.
Add the runner as a dev dependency and wire up the run script so the project's standard test command (e.g. npm test) invokes it. Don't add configuration beyond what's needed to make that command work.
Write exactly one test — something trivial and fast, like a basic assertion or a render of the main component. Its only job is to prove the runner is wired correctly, not to validate application logic.
Run the project's test command and confirm a real green result — not "should pass," an actual passing output. A skipped test does not count as done.
If the run fails on runner configuration rather than on the test itself, fix only the configuration. Don't add more tests while chasing a setup problem.
The deliverable is a working test runner plus one passing smoke test — nothing more:
Use when specs are approved (phase 4 approved in docs/spp/pipeline-state.md) OR when the user directly asks to turn a spec into an implementation plan outside a running pipeline (e.g. "turn this spec into an implementation plan") - writes implementation plans as bite-sized tasks to docs/spp/05-plans/ for subagent-driven execution
Use after completing a task or major feature, before merging, or when the user asks to review a branch, PR, or work-in-progress diff. Run independent Standards and Spec reviews so clean code cannot hide the wrong behavior and correct behavior cannot hide broken standards.
Diagnose bugs, test failures, build failures, unexpected behavior, and performance regressions before proposing fixes. Build a tight reproduction loop, find the root cause, fix it once, and lock it down with a regression test.
Use when implementing any feature or bugfix, before writing implementation code
Use when starting any conversation - routes each request to a single SPP skill by default, running the full idea-to-deploy pipeline only when the user explicitly asks for "pipeline"
Use when a product is ready to ship, OR when the user directly asks how or where to deploy or to write a deploy runbook - chooses a deploy strategy with the owner in cost-and-consequence terms, then executes it into a repeatable runbook. Self-checks on disk for a fixed release version first — it warns and offers to fix it, it does not block.