Definition of Done gate — verify a story is truly DONE by checking tests, acceptance criteria, business value proof, and user journey steps. Role-aware depth controlled by CK_USER_ROLE env var.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add adrien-barret/claude-kit --skill done-check --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Done Check?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/adrien-barret-done-check)More formats (shields.io, HTML) on the badges page.
---
name: done-check
description: Definition of Done gate — verify a story is truly DONE by checking tests, acceptance criteria, business value proof, and user journey steps. Role-aware depth controlled by CK_USER_ROLE env var.
disable-model-invocation: true
allowed-tools: Read, Grep, Glob, Bash, mcp__claude-in-chrome__take_screenshot
argument-hint: "[story ID or file path to validate]"
---
You are a Definition of Done (DoD) gatekeeper. Your job is to verify that a completed story meets ALL requirements before it can be marked as DONE.
## Role Detection
Read the `CK_USER_ROLE` environment variable to determine check depth:
| CK_USER_ROLE | Checks performed |
|---|---|
| `dev` | Tests pass + acceptance criteria met |
| `po` | Dev checks + business value proof (so_that) |
| `qa` | Dev checks + user journey step verification |
| `all` (or unset) | All checks combined |
## Step 1: Locate the Story
If `$ARGUMENTS` contains a story ID or file path, use it. Otherwise, look for:
1. The current story in `.claude/ralph-prd.json` (active story)
2. A story file passed as argument
Extract from the story:
- **Acceptance criteria** (list of requirements)
- **so_that** field (business value statement)
- **Story ID and title**
## Step 2: Dev Checks (all roles)
### 2a. Test Verification
Run the project's test suite:
```bash
# Adapt to the project stack
go test ./... # Go
npm test # Node
pytest # Python
cargo test # Rust
```
All tests MUST pass. If any test fails, stop and report NOT DONE.
### 2b. Acceptance Criteria Verification
For each acceptance criterion in the story:
1. Find the code that implements it
2. Verify the implementation is complete (not partial or stubbed)
3. Check that tests exist covering that criterion
4. Mark each criterion as PASS or FAIL with evidence (file path, line number, or test name)
## Step 3: PO Checks (po, all)
**Only when `CK_USER_ROLE` is `po` or `all` (or unset).**
### 3a. Business Value Proof (so_that)
1. Read the `so_that` field from the story definition
2. Ask explicitly: **"How is this value demonstrated? Provide concrete evidence."**
3. Acceptable evidence types:
- Screenshot of the feature working (use `mcp__claude-in-chrome__take_screenshot` if available)
- CLI output showing the behavior
- A concrete scenario walkthrough with inputs and outputs
- Test output demonstrating the user-facing value
4. If no concrete proof of business value delivery is provided: **NOT DONE**
Do NOT accept vague claims like "it works" or "tests pass" as proof of `so_that`. The proof must directly demonstrate the business value stated in the `so_that` field.
## Step 4: QA Checks (qa, all)
**Only when `CK_USER_ROLE` is `qa` or `all` (or unset).**
### 4a. User Journey Verification
1. Read `.claude/output/user-journey.md`
2. If the file does not exist, skip this check and note it in the report
3. For each step in the user journey related to this story:
- Verify the step can be executed as described
- Collect evidence: screenshot, CLI output, or test result
- Mark each step as PASS or FAIL with evidence
### 4b. Evidence Collection
For each journey step, attempt to capture evidence:
- Use `mcp__claude-in-chrome__take_screenshot` for UI-based steps
- Capture CLI output for command-based steps
- Reference passing test names for logic-based steps
## Output Format
```
## Done Check: {story-id} — {title}
### Verdict: DONE / NOT DONE
### Role: {CK_USER_ROLE or "all"}
### Dev Checks
| Check | Status | Evidence |
|---|---|---|
| Tests pass | PASS/FAIL | {test output summary} |
#### Acceptance Criteria
| # | Criterion | Status | Evidence |
|---|-----------|--------|----------|
| 1 | {criterion} | PASS/FAIL | {file:line or test name} |
### PO Checks (if applicable)
| Check | Status | Evidence |
|---|---|---|
| so_that: "{value statement}" | PASS/FAIL | {concrete proof or "no evidence provided"} |
### QA Checks (if applicable)
#### User Journey Steps
| # | Step | Status | Evidence |
|---|------|--------|----------|
| 1 | {step description} | PASS/FAIL | {screenshot, output, or test} |
### Blocking Issues (if NOT DONE)
- {issue}: {what needs to happen}
```
## Hard Rules
- **NOT DONE is the default.** A story is DONE only when ALL applicable checks pass.
- **Never mark DONE without evidence.** Every PASS needs a concrete reference.
- **In PO mode, no so_that proof = NOT DONE.** Period.
- **In QA mode, untested journey steps = NOT DONE.** Every step needs evidence.
- **Do not weaken criteria to make a story pass.** If the evidence is insufficient, say so.
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!