---
name: charter
description: "Write, revise or review a charter: the one document that tells an executor what to deliver, what is out of bounds, what the owner already decided, and how each success check will be proven. Use when work needs a written brief before someone else does it, or when asked to write, change or check a charter."
requires:
  programs: []
  harness:
    - {slot: 4.shell, need: required}
    - {slot: 4.file-read-write, need: required}
---

# charter

A charter is one markdown file that says what to deliver and how everyone will know it was
delivered. A task is named by its charter
filename. `charter` writes it; `deliver` carries a released charter out. Any kind of project
uses it: software, documents, campaigns, research, operations. The owner is whoever owns the
work (often the user); speak to them in the language they use.

Prerequisites: none to use it; its selftest needs bash and python3.

Read `references/template.md` for the file layout and `references/questions.md` before asking
the owner anything.

## Rules that keep a charter useful

- Preserve the owner's words and decisions. Never invent a decision, a fact or a requirement.
  A missing choice that would change the outcome is asked once, one question at a time, at the
  end of a message; independent work continues while it waits, and silence is not approval.
- Read the existing work first (files, documents, data, earlier decisions). Ask nothing they
  already answer.
- Every success check names what will be observed, where, and how, and can be answered pass or
  fail by a real run or inspection. The expected result comes from the requirement or from
  independent data, never from pasting the program's own output. For a defect, the check
  reproduces the defect first.
- Before adding a precondition, check, section or approval step, name the failure it detects
  and what would change if it failed. If nothing changes, leave it out. By default no checksums,
  sign-off records, warm-up runs, baselines, fixed snapshots or report formats are entry
  conditions.
- By default a security check, a full test suite or a full evaluation enters a charter only if
  the owner names it. Propose it as a question that says what it would check and what it would
  block; do not write it in as a requirement on your own judgment. A project may choose
  otherwise.
- Say what happens on failure: which operation is logged with its error, what continues. A
  record or report failure never disables the main result; a real failure stays a failure.
- Time is finite. A check that takes long states its expected duration from existing timings;
  by default no full suites unless the owner asks.
- State what the executor may not do without the owner: publish, send to other people, spend,
  delete, overturn a recorded decision.

## Write

1. Read the request, adjacent notes and the existing work. Cite settled decisions without
   copying or locking their source. When the work depends on a third-party product, service or
   version, read its current official documentation and record the facts that constrain the
   work with the page and version.
2. Draft Owner decisions, Outcome, Scope and non-goals, and Success checks from the template.
   Length follows the work: a few lines for a small task, a sliced charter (named slices, each
   with its own checks) for a big one. There is one kind of charter, not sizes.
3. Read it as the executor: for each check, could someone tell pass from fail without asking?
   Walk one real example through it. Fix the gaps that would make the result fail. Do not run
   the future work to plan it.
4. One independent review for the owner's intent and concrete defects (`peer-review` when it
   is installed, otherwise a second agent). Fix material findings; no second round unless the
   owner asks.
5. Tell the owner what the charter will deliver and any genuine open decision, in plain
   words, ending with the one question. After the owner approves, set `status: released` and
   hand the path to the executor, or to whoever supervises the work.

By default an agent alone never releases a charter: it records the owner's decisions. When the
owner is away, leave the charter as a `draft` for them to release; a project may choose
otherwise.

## Revise

A scope change updates the affected decisions and checks in the same edit, sets `updated`, and
leaves the rest alone. A replaced charter gets `status: superseded` and a pointer to its
successor. Delivery records `delivered` only through `deliver`; never infer it from the header.

## Review only

Read the charter and the affected work. Report concrete mismatches, their consequences and the
smallest corrections in one local file; do not edit the reviewed charter. Questions go in the
conversation. Applying accepted corrections is Revise.