Briefs

Brief format

A brief is a Markdown file with four required sections:

# Brief

## Situation
Facts only, no spin. What is the current state?

## Stakes
What is the upside if we get this right?
What is the downside if we get this wrong?

## Constraints
Budget, timeline, capacity, regulatory, technical debt.

## Key Question
The single most important question for the board to answer.

What makes a good brief

Situation should be factual and neutral. Do not lead the board toward a conclusion. State what is true, what has changed, and what the current position is.

Stakes should quantify upside and downside where possible. “We could lose the deal” is weaker than “This is a $400K ARR contract with 18-month lock-in.”

Constraints should be exhaustive. If there is a deadline, state it. If there is a budget limit, state it. If there is a regulatory requirement, state it. Board members cannot account for constraints they do not know about.

Key Question should be a single, answerable question. “What should we do about our engineering strategy?” is too broad. “Which engineering path compounds capability over the next 18 months?” is actionable.

Brief location

Briefs are stored at:

.pi/ceo-agents/briefs/{brief-id}/brief.md

The brief-id is a slug derived from the brief title, typically in the format YYYY-MM-DD-topic.

Tips

  • Keep briefs under 500 words. The board members get the full brief text plus their persona and instructions. Long briefs consume budget on context.
  • Do not include your preferred answer in the brief. The board’s value comes from independent analysis.
  • Include numbers where available. Revenue, cost, timeline, and capacity constraints sharpen the deliberation.
  • If this is a follow-up to a previous decision, reference the prior memo by brief ID.