Files & workspace

Requirement contract

Turn a spoken request into a tickable acceptance list, so done means done.

Free Free to read and free to ask for by email.

Background

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.

Why it is built this way

A requirements document states intent and a contract states acceptance, so the checklist is generated before work starts and every line carries an ID. The five prefixes come from where requirements actually go missing: R hard rule, S delivery spec, C communication preference, N do not do, V acceptance criterion. check_contract.py returns 1 while one item is unticked, which makes the word done something a file can refuse.

make_contract.py extracts those five sections mechanically, because a long document gets read once and then quoted from memory. Ticking happens per item with --mark R-01, so a rework round can show which line changed. The ban on rewriting an unticked item into 'achieved' exists because that edit leaves no trace and produces a contract that always passes. A waiver is written beside the original item, still ticked and annotated, so the decision stays auditable.

Where it bites

• Contract shorter than the document When the requirements run long, only a handful of items get turned into contract lines, and the dropped item is the one that returns as rework. The generator takes all five sections, no selection, and --summary prints the totals so a short contract shows up before delivery.
• An adjective used as acceptance A line reading 'looks smooth' cannot fail, so it always passes and verifies nothing. The rule requires a number, command output or file existence; when a criterion cannot be split into testable parts, the skill says to ask the user instead of inventing a threshold.
• Requirements changed, contract did not A new instruction arrives mid-task, gets remembered verbally, and the contract still lists the old set, so the gate passes while the work is out of date. The second hard rule changes the contract first, then adds the item; exit code 2 keeps a missing or empty contract separate from an unticked one.
• Item quietly rewritten as achieved The fastest route to a green gate is editing the line instead of doing the work, and the edit leaves no evidence behind. The first hard rule forbids it: an unticked item keeps its text and gets a written reason. Waivers go at the end of the contract, with the original item kept.

Inside this skill

1. When to use it
2. Three steps
3. What the contract looks like
4. Hard rules
5. Common mistakes
6. Acceptance

The outline is the skill file's own headings, in the order it uses them.

When to use it

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.

How to use it

1. Ask for the file by email — it is a single SKILL.md.
2. Put it in the skills folder your agent reads, in a directory named requirement-contract.
3. Start a message with the trigger from the description, or name the skill directly.