Skip to content
Back to skills

Done Check

ASecurity

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.

  • 8 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 6, 2026
testingpythonrustgobashnode

Works with

  • cli
  • mcp

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add adrien-barret/claude-kit --skill done-check --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Done Check?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Done Check
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/adrien-barret-done-check/badge)](https://www.skillsdirectory.com/skills/adrien-barret-done-check)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…