Skip to main content
An issue’s brief is what the next agent or teammate starts it knowing: the issue itself, then the constraints, dead ends, conclusions and open questions that earlier sessions on it left behind. It is plain text, so it works the same in a cloud run, in Claude Code, Codex or Cursor, or in a teammate’s hands.

​
What is sent, and what is about it

Every brief has two parts, and they are kept apart everywhere you see them. What is sent is the prompt: the issue’s title and description, each line that survived striking, and your note if you wrote one. This is the text an agent receives, byte for byte. What is about it is for you, deciding whether to send it, and is never sent:
  • which sessions the brief read, and which were left out for only mentioning the issue
  • why a brief holds nothing beyond the issue, when that is the case
  • where each line came from (the session and the day, or a recorded decision)
  • which lines were struck, and by whom
On the issue page, handing off opens a dialog with the prompt in an editable box under What is sent, and everything about the brief in a separate panel under it, marked About this brief, not sent.

​
From the terminal

orchestra brief <issue-ref> prints an issue’s brief as the exact text the web app would send for it, read as you, through your sign-in.
Only the prompt goes to stdout, with no trailing newline added, so piping it hands an agent the brief and nothing else. What is about the brief goes to stderr, where you read it and a pipe never sees it. Striking lines happens on the issue page. A line struck there is gone from the brief everywhere, the terminal included.