---
name: brief-register
description: Turn a client brief and its references into a requirement register with source links, open questions and conflicts, for designer review before concept work. Use when a new brief, programme, client email thread or reference set arrives, or when the designer asks "what does the client actually require".
version: 0.1.0
---

# Brief register

You produce a **requirement register** from the client's own material. You do not design, propose
or fill gaps. Missing information stays visible as missing.

## Inputs (read only)
- The brief: PDF, document, email thread or notes the designer points you to.
- Approved references: images, precedents, site documents, survey, client standards.
- `context/approved.md` if a context pack exists (see the `context-pack` skill).

Ask for the files if none are given. Never search outside the folders the designer names.

## Outputs (write only inside `brief/`)
- `brief/brief-register.md` from `templates/brief-register.md`
- `brief/questions.md` from `templates/questions.md`
- One entry appended to `runs/ledger.md` (format in `../_shared/run-ledger.md`)

## Procedure
1. **Inventory the sources.** List every file with its date or revision. Note any file you could
   not open. Ask before continuing if the brief itself is unreadable.
2. **Extract requirements one by one.** Each row gets: ID (R-001…), requirement in the client's
   words, the source (file, page or line, date), the type, and the status.
   - Type: `fixed` (stated as a must), `preferred` (stated as a wish), `inferred` (you derived it;
     say from what), `regulatory` (code or standard named by the client).
   - Status: `stated`, `open question`, `conflict`.
3. **Dimensions and quantities are copied, never estimated.** A room "about 20 m²" is recorded as
   "about 20 m²", type `preferred`. A missing dimension becomes a row with status `open question`.
4. **Find conflicts.** Two requirements that cannot both hold (budget vs. scope, a fixed wall vs.
   a requested opening, two different areas for the same room) get status `conflict` and a short
   note citing both sources.
5. **Write the questions file.** One question per open item, grouped by who can answer (client,
   site, authority, studio). Each question names the register ID it resolves.
6. **Write the ledger entry.** Inputs with revisions, outputs, every assumption, and the gate:
   "Designer reviews register before concept work · Status: pending".
7. **Stop.** Tell the designer how many rows, questions and conflicts there are, and the three
   items you consider most consequential. Do not start concept work.

## Permissions and gate
- Read: the folders named by the designer. Write: `brief/` and `runs/ledger.md` only.
- Gate: the designer marks the register `approved` in its header before any concept or modelling
  skill may read it. An unapproved register is a draft.

## Checks
- Every row has a source. A row without one is a defect; delete it or mark it `inferred` with the
  reasoning.
- Row count in the register equals the count you report.
- No number appears in the register that does not appear in a source, except IDs and dates.

## Anti-patterns
- Filling a gap with a 'typical' value because the client will probably accept it.
- Merging two conflicting requirements into one row that sounds reasonable.
- Starting concept sketches 'while waiting' for the designer's review.

## Never
- Never invent a requirement, dimension, standard or client preference.
- Never resolve a conflict yourself. Record it.
- Never modify the source files.