done-criteria

# Done Criteria Skill

This skill guides you in defining clear, testable acceptance criteria that can be verified by automated testing and browser-based verification.

## What Makes Good Done Criteria

Every criterion must be:

### 1. Observable
Can be seen in the browser or test output. Something a human or automated test can verify.

### 2. Specific
Not vague or subjective. Clear enough that two different testers would agree on pass/fail.

### 3. Testable
Can be verified programmatically or through browser interaction. No "feel" or "seem" language.

## Categories of Criteria

### Functional Criteria
The feature works as expected.

Examples:
- "Clicking 'Submit' button sends form data to the server"
- "User can navigate between pages using the sidebar menu"
- "Search results update as user types in the search box"

### Visual Criteria
The UI renders correctly.

Examples:
- "Profile page displays user name, email, and avatar image"
- "Error messages appear in red text below the input field"
- "Loading spinner is visible while data is fetching"

### Validation Criteria
Errors and edge cases are handled properly.

Examples:
- "Form shows 'Email is required' when submitted without email"
- "Empty state message appears when no results are found"
- "Network error displays 'Unable to connect' message"

### Build Criteria
Code quality standards are met.

Examples:
- "Build completes without errors"
- "No TypeScript type errors"
- "No ESLint warnings"
- "All existing tests pass"

## Examples: Good vs Bad Criteria

### Bad Criteria (Avoid These)

| Bad | Problem |
|-----|---------|
| "Profile page looks good" | Subjective - what is "good"? |
| "Form is user-friendly" | Vague - can't be tested |
| "Performance is acceptable" | No measurable threshold |
| "Errors are handled" | Doesn't specify which errors or how |
| "The code is clean" | Opinion-based, not testable |

### Good Criteria (Use These)

| Good | Why It Works |
|------|--------------|
| "Profile page displays user