Briefs, checks and readiness

A brief is a ticket written so that someone who cannot ask can build it. The format is the open Brief Standard; this page is about how NEWWORK Projects works with it.

Write with Nova

On any ticket, and in the New ticket dialog, Write with Nova turns the title and your notes into a brief for the ticket’s type. It names the project’s repositories in Context where your notes point to them, and never invents file paths.

• What it fills in that your notes don’t say is listed as an assumption. Keep it, or strike it and it leaves the brief.
• What it can’t know (names, numbers, limits, exact wording) becomes an open question or a [to confirm] placeholder.
• Acceptance checks come back as their own list, saved with the ticket. Existing checks are kept; one that is a task or a wish is rewritten as a result you can observe.

Answer the questions and choose Apply to description: the answers are worked in and the questions leave the brief. Nothing is saved until you save, and Undo brings your notes back.

Drafts from notes, breakdowns into children and the plans of a brainstorm follow the same format, and each draft shows its readiness before you create it.

Briefs written by hand

When a description in the backlog or to do has no intent, no checks, or checks that are tasks or wishes, a quiet line under it offers Restructure with Nova. It moves your text into the brief’s sections and turns tasks and wishes into checks. It keeps what you wrote and adds no requirements; what is still missing comes back as questions. Not now hides the line for that ticket, Don’t suggest again for all of them. The line itself costs nothing: only the button calls the AI.

Readiness

Every ticket gets a score from 0 to 100, computed from the brief whenever it changes:

Part	Points
An intent	25
Acceptance checks, all of them observable	30
No open questions	25
Context: a repository, file or link	20

While some checks are tasks (“Add an export button”) or wishes (“Export is fast”), they earn 15 of the 30 points. All four parts make it Ready for agent, and board cards and backlog rows show a robot mark. Agents see the score in pm-my-work and pm-item-get, pm-brief-check lists the checks to rewrite, and pm-item-start warns when a ticket isn’t ready.

Acceptance checks

Checks live under the description, one observable statement each. The assignee, the reporter and project managers tick them:

• Passed needs evidence: a pull request, commit or link, or a test and its result. A person’s tick in the app without evidence counts as Confirmed by that person.
• Failed needs a note saying what failed.
• Who ticked, when, how (app or AI agent) and the evidence show next to the check and in the activity.

A description that still has an old “Acceptance criteria” list turns into checks with one click.

Testing

Each check is a test case; there is no second list to keep in step.

• Automated by default. An agent writes a test per check, named after it (PAY-12 check 2: …), and passes the check with that test, its result and the CI run as evidence. pm-item-start tells the agent so.
• Manual when only a person can judge. End the check with “(manual)”, for example “The empty state matches the design (manual)”. Agents can’t pass it; they fail it or say in a comment how to verify it, and a person ticks it.

Verified done

A done ticket is Verified when every check passed with evidence and no linked pull request is still open. Otherwise it shows Not verified, and the tooltip lists what is missing. Verified tickets get a shield mark on cards and rows.