# Briefs A brief is a work order. One markdown file, in the project it belongs to. Not a launch slot, not an arc write, not a status Mark clicks. Mark naming the file in the thread is the go. This is the one source for briefs — the grammar and the behaviour. `projects/briefs/GRAMMAR.md` points here. `[MARK]` 2026-08-30 (the grammar), 2026-09-12 (the home and the closure rule, PRJ law 25). Commands in this file are relative to a folder named `beargrassai` on the machine that runs them. If you do not have that folder, you cannot run the commands. Do not invent a home path. ## Where a brief lives — the folder is the status **Open:** `projects/-/briefs/-.md` — in the project it belongs to, beside that project's `tasks.md`, `+law.md` and `CHANGELOG.md`. **Closed, done or dead alike:** `projects/briefs/_archive/`. There is no status field. In the project folder = open. In `_archive/` = closed. Nothing else means anything. - The folder is the owner. No project code and no agent name in the filename. - Date first, so the folder reads top to bottom in time. - `` is a lowercase hyphenated outcome, not a novel. - `projects/briefs/` itself holds only the pointer, the template and the build kit. Never a brief. ## Writing one You are a project agent. You write a brief when Mark asks for one, or when work you cannot do yourself (another project's, a craft you are not packed with, an irreversible act) needs a work order. You write it **into your own project's `briefs/` folder**, copy `projects/briefs/TEMPLATE.md`, and add one dated line on your board pointing at it. You do not write into another project's folder; you draft the brief in yours and say so. Frontmatter, closed: | key | required | values | |---|---|---| | `created` | yes | `YYYY-MM-DD` | | `pack` | when a craft is required | `do` `fd` `ec` | | `human_verify` | when money, live cutover, client-ready claim, medical, or Access | `true` | Nothing else. No `status`, no `owner`, no `id` — the folder says all three. Fossil briefs in `_archive/` carry the old keys and the old shape `BRIEF---.md`; read them through this grammar, do not rewrite them. Body, closed section order. Copy the template; do not add sections. 1. Title: one-line outcome. 2. Why: measured fact, dated if you have a date. 3. Deliverable: exact outcome. No menu. 4. Paths: absolute. 5. Done when: a checklist an agent can close without reinterpretation. 6. Mark gates: push, deploy, promote, send, Access, money. Empty if none. ## Running one You are the project the brief sits under, doing the outcome it states. You are not the factory. You do not approve. You do not close your own brief. 1. Open the file Mark named. One file. Do not ingest the folder. 2. If it is in `_archive/`, stop and say so. Do not execute. 3. If Mark has not named it in the thread, it is not this launch's work. Naming it is the go. There is no Approve click. 4. Do the deliverable. Paths, done-when and Mark gates in the file are the contract. Do not turn a menu of options into the job. 5. Write a `## Progress` section as you go — dated lines, what landed, what is owed. This is what the next agent reads. ## Closing one — two acts, no script 1. One dated line in the project's `CHANGELOG.md` saying what landed. 2. `git mv` the file to `projects/briefs/_archive/`. A brief that is done and still in the project folder is not closed. Mark, or the agent on Mark's word in the thread, does the move. Nothing checks this; it is done or it is not. ## Refuse these - Ingesting a `briefs/` folder and picking the most interesting file. - Writing a brief anywhere but your own project's `briefs/`. - Claiming approved, dispatched, or done. - Treating a brief as a launch slot or writing it onto the pad. - Opening `_archive/` unless Mark named a file there. - A status field, a week folder, a `PACK.md`, an owner that is not a project.