Standalone testing skill — owns writing and running tests, verifying behavior, and two-pass TDD orchestration. Default mode analyzes changed scope and runs the relevant tests; `--unit`/`--integration`/`--e2e`/`--all` scope by test type; `--verify` reruns exactly the prior failures; `--all-phases <plan>` sweeps every completed phase for regression. `--tdd --prepare`/`--tdd --verify` bracket `ck:cook` for red-green TDD. Never edits production code, and blocks until a phase's `ck:quality` gate i...
Scanned 9/11/2026
Install to Claude Code
npx -y skills add DangQuangSE/team-development-skills --skill ck-test --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Ck Test?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/dangquangse-ck-test-810cb3a4)More formats (shields.io, HTML) on the badges page.
---
name: ck:test
description: Standalone testing skill — owns writing and running tests, verifying behavior, and two-pass TDD orchestration. Default mode analyzes changed scope and runs the relevant tests; `--unit`/`--integration`/`--e2e`/`--all` scope by test type; `--verify` reruns exactly the prior failures; `--all-phases <plan>` sweeps every completed phase for regression. `--tdd --prepare`/`--tdd --verify` bracket `ck:cook` for red-green TDD. Never edits production code, and blocks until a phase's `ck:quality` gate is APPROVED (except `--tdd --prepare`, which runs before any implementation exists).
user-invocable: true
---
# ck:test — Standalone Verification & TDD Orchestration
`ck:test` owns all verification. It never touches production code and never calls `ck:fix` itself — a failure always hands control back to the user.
Modes (pick exactly one; `--tdd` further requires `--prepare` or `--verify`):
- default `<plan-or-phase>` — analyze the changed scope, write any missing tests, run the relevant unit + integration suites.
- `--unit <target>` / `--integration <target>` / `--e2e <target>` — run only that test type against `<target>`.
- `--all <target>` — run every applicable suite for `<target>`'s scope (not necessarily the whole repo).
- `--verify <target>` — rerun exactly the tests that previously failed, plus directly related regression tests; does not redesign the suite.
- `--all-phases <plan-path>` — regression sweep across every already-completed phase in the plan.
- `--tdd --prepare <phase-file>` — write failing tests before `ck:cook` implements anything; confirm RED (failure is due to missing implementation, not a broken test); save a `RED_READY` artifact.
- `--tdd --verify <phase-file>` — after `ck:cook` implements, rerun; confirm GREEN plus regression; detect tests that were weakened, deleted, or modified to dodge a failure rather than fixed by the implementation.
---
### Step 1 — Quality Gate Check
Skip only for `--tdd --prepare`, or for `--unit`/`--tdd --verify` explicitly orchestrated by the active `ck:cook` phase after its Phase Checkpoint recorded tests=yes. This scoped exception lets tests and quality remain independent user choices; it does not apply to standalone test requests.
For every other mode, resolve the phase(s) in scope and verify each has a valid, current quality receipt:
```
python {ck-quality-skill-root}/scripts/receipt.py verify plans/{slug}/quality/{phase}-receipt.json
```
Resolve `{ck-quality-skill-root}` from the installed `ck:quality` skill directory for the active client; do not hardcode `skills/` or `.claude/skills/`.
A missing or invalid receipt stops the run before any test is written or executed:
```
BLOCKED: phase implementation has not passed the Code Quality Gate.
Run or resume /ck:cook for the current phase.
```
### Step 2 — Resolve Scope
- default / `--unit` / `--integration` / `--e2e` / `--all`: the phase's changed files (`git diff` since the phase's last session-notes timestamp), or the given `<target>` path.
- `--verify`: exactly the `failures[].related_files` from the report being verified, plus the tests that exercise them — refreshed against current `git diff` in case scope grew.
- `--all-phases`: every phase in `plan.md`/`plan.json` already `completed` with `quality.status: approved`.
- `--tdd --prepare` / `--tdd --verify`: the single named phase file.
### Step 3 — Run Tester
If a named **`tester`** agent is available, spawn it with: scope, mode, existing test conventions (read 2-3 sibling test files first), and — for `--tdd --verify` — the prepared `RED_READY` artifact's exact test file contents. Otherwise execute the tester process inline. The inline path follows every ownership constraint and writes the same report; it exists so the skill remains standalone on Codex and Antigravity.
`tester` may create or edit only test code, fixtures, mocks, and test helpers. It never touches production code, never weakens an assertion to make a test pass, never deletes a failing test, and never marks a test passed without having run it.
### Step 4 — Run and Verdict
Run the relevant suite(s) for the resolved scope (not necessarily the whole repo, unless `--all-phases`).
| Mode | Verdict values |
|---|---|
| `--tdd --prepare` | `RED_READY` (every new test fails only because the implementation doesn't exist yet) or `BLOCKED` (a test fails for an unrelated reason, e.g. a syntax error in the test itself) |
| default / `--unit` / `--integration` / `--e2e` / `--all` / `--verify` / `--all-phases` / `--tdd --verify` | `PASSED` or `FAILED` |
`--tdd --verify` additionally reports `FAILED` (category `WEAKENED_TEST`) if any prepared test's assertions were loosened, deleted, or its scope narrowed without a corresponding, justified change to the acceptance criteria — regardless of whether the suite otherwise passes.
### Step 5 — Report and Handoff
Write the report to `plans/{slug}/tests/{phase}-test-report.json` (matching `references/test-report-schema.json`); `--tdd --prepare` writes `plans/{slug}/tests/{phase}-tdd-ready.json` (matching `references/tdd-ready-schema.json`) instead. `--all-phases` writes one report per swept phase — never one aggregate file covering multiple phases — then prints a one-line PASSED/FAILED summary per phase.
Update the phase's `testing.status` (JSON) or Quality and Testing State section (Markdown) to mirror the verdict: `PASSED → passed`, `FAILED → failed`, `BLOCKED → blocked_on_quality`. `ck:test` owns this field; nothing else writes it. Field shape and allowed values are defined once in `ck-plan-json/rules/plan-design.md` § Quality and Testing State — don't redefine them here.
On `FAILED`, stop — **do not** call `ck:fix` automatically. Print:
```
[ck:test] {mode} → FAILED
Report: plans/{slug}/tests/{phase}-test-report.json
Next: /ck:fix --from-test plans/{slug}/tests/{phase}-test-report.json, then /ck:test --verify {phase}
```
On `RED_READY`, print the artifact path and hand control back to `ck:cook`:
```
[ck:test] --tdd --prepare → RED_READY
Artifact: plans/{slug}/tests/{phase}-tdd-ready.json
Next: /ck:cook {phase-file} --tdd
```
On `PASSED`, print a short summary (`passed`/`failed`/`skipped` counts) and the report path; no further action is implied.
## Constraints
- Never edit production code — only test code, fixtures, mocks, and test helpers.
- Never call `ck:fix` itself; a `FAILED` or `BLOCKED` report always hands off to the user.
- A phase without an `APPROVED`, current quality receipt blocks every mode except `--tdd --prepare`.
- Do not mark a test passed without having actually run it in this invocation.
- `--verify` and `--tdd --verify` re-run the full previously-failing set, not a subjective subset — do not declare `PASSED` on a partial rerun.
---
Report shape: `references/test-report-schema.json`. TDD-prepare artifact shape: `references/tdd-ready-schema.json`.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!