---
name: requirement-contract
description: "Use when the user says 'do it per my requirements', 'follow the requirements document', or 'don't miss anything this time', and before saying 'done' prior to delivery; it turns a requirements document or a verbal list of requirements into a tickable acceptance checklist, and you may not declare completion until every item is ticked."
---

> Original skill · commissioned by the user · English edition, 2026-11-12

# Requirement contract

Turn "what the user actually wants" into a tickable DoD (Definition of Done). A requirements document states intent; a contract states acceptance; **declaring completion without a contract equals not having delivered**.

## When to use it

- The user hands over a requirements document (`<REQUIREMENT_LIB>/<domain>/*.md`) and wants the work done per it
- The user verbally lists a string of requirements (size, naming, duration, things not to do) that need to be pinned down first
- You want to say "done" before delivery — run `check_contract.py` first; if the exit code is not 0 you may not say it
- Re-verifying after rework, to prevent "changed A and missed B"

Do not use it for: small talk, single-step operations, anything without acceptance criteria.

## Three steps

```powershell
$S = "<SKILL_DIR>/scripts"

# 1) Requirements document → contract (automatically extracts the five sections: hard rules / delivery spec / communication preferences / repeatedly rejected / acceptance criteria)
python $S\make_contract.py --requirement "<REQUIREMENT_LIB>/<domain>/<requirements>.md" --task "<batch>_<topic>_final-cut" --out "<WORKSPACE>/requirement_contract.md"

# 2) Tick one item as each item gets done (IDs look like R-01 / S-03 / V-02)
python $S\check_contract.py --file "<WORKSPACE>/requirement_contract.md" --mark R-01 --mark S-02

# 3) Pre-delivery gate: exit code 1 while anything is unticked, so you may not say done
python $S\check_contract.py --file "<WORKSPACE>/requirement_contract.md" --summary
```

Exit codes: `0` all ticked / `1` something unticked / `2` file missing or no items.

## What the contract looks like

```markdown
- [ ] `R-01` Lock the aspect ratio as the very first action: landscape 1920×1080, portrait 1080×1920 (past run)
- [x] `S-04` File naming `YYYYMMDD_topic_purpose[_vN]`
- [ ] `V-02` Loudness −14 LUFS (±0.5), true peak ≤−1.0 dBTP
```

ID prefixes: `R` hard rule / `S` delivery spec / `C` communication preference / `N` do not do / `V` acceptance criterion.

## Hard rules

1. **When you cannot tick an item, write the reason; never rewrite the item into "achieved".** Rewriting an item = faking acceptance.
2. A new requirement appears in the document → change the contract first, then add the item; do not just remember it verbally.
3. The user explicitly waives an item → write it clearly at the end of the contract under "items confirmed abandoned by the user", and keep the original item (ticked, annotated "waived by the user").
4. An acceptance criterion must be testable (a number, command output, file existence); words like "looks good" or "smooth" must be split into testable sub-items — if you cannot split them, ask the user.

## Common mistakes

| Practice | Why it is wrong |
|---|---|
| The requirements document is too long, so only a few items are turned into the contract | What you drop is exactly the item that comes back as rework |
| Saying "everything is satisfied" verbally at delivery | There is no machine evidence at all; print the statistics with `--summary` |
| Writing "acceptance criteria" as adjectives | Not testable → equals no acceptance at all |
| Building the contract once and never updating it | The requirements changed but the contract did not, so acceptance is void |

## Acceptance

```powershell
python $S\check_contract.py --file <WORKSPACE>/requirement_contract.md --summary
# Expected: N items total, N ticked, 0 unticked; exit code 0
```