Prepare an operations update without sending it. This guide is for the person
who will review the update and choose any subsequent action. Complete the
workflow setup
first:
Sonny 0.12.7 on Linux, a configured model and review-work.yaml.
No messaging or issue-tracker account is needed.
Establish the source of truth
Use these approved fictional notes:
- P1 — Progress: The pilot comparison brief is drafted. Maya will review its arithmetic. No review date was supplied.
- B1 — Blocker: No customer-satisfaction survey exists. No survey owner was assigned.
- D1 — Decision: The team must review the brief before external sharing. No publication date was approved.
The recipient audience is the operations team. Nothing in these notes authorizes publication, assigns the survey to Maya, or makes the brief approved.
Produce a draft
The complete prompt contains those notes and asks for a paragraph plus a proposed-action table:
curl --fail --location https://sonny.sh/examples/cookbook/operations.txt --output operations.txt
sonny run --file ./review-work.yaml --new --no-tools --no-trace --prompt "$(cat operations.txt)"
Expect a draft in your terminal. This fresh session has tools disabled; it cannot post a message, create an issue or read a connected project. The input still goes to your configured model and can enter local history. Keep your own confidential operating notes out of this public fixture.
Review the result
A checked update says that the brief is drafted and awaiting arithmetic review; it does not say the review finished or a survey ran. Use this reference action table when reviewing the model’s proposal:
| Action | Owner | Date | Status and evidence |
|---|---|---|---|
| Review the arithmetic | Maya | Unresolved | Assigned review, P1 |
| Propose a satisfaction measurement plan | Unassigned | Unresolved | Proposed next step based on B1 |
| Review the exact brief before external sharing | Unassigned | Unresolved | Required review, D1 |
The survey-plan proposal is your interpretation of the missing measure, not an existing assignment. Label it accordingly. Check each name and date against the notes. Reject any assertion that the update was sent, a ticket was created, or a person accepted a newly proposed task.
Keep drafting separate from applying a change
This tutorial ends with your reviewed draft. It does not configure or qualify an external write integration. You can copy the exact approved text into your normal approved channel and inspect the audience before sending it yourself.
If your deployment provides a supported write tool, first use its integration instructions to establish access and permission scope. Review the exact operation, project/channel, recipient, fields and final text before authorizing a write. Read access and a generated proposal do not authorize that write. Confirm the resulting record or message after applying it and retain its identifier. A timeout is an uncertain outcome: inspect the target before retrying to avoid duplicates. The MCP trust guide explains the connection boundary; a catalog entry alone does not prove a particular service write is available.
Recover and continue
If Sonny fails before producing a draft, preserve its diagnostic and check the model and credential configuration . If the draft fabricates commitments, correct it against P1/B1/D1 and review again. With tools disabled, any claim of a sent message or created issue is unsupported.
Keep the approved update with its evidence and reviewer. For a shareable local artifact, follow the reviewed PDF workflow . For the software-development peer, build a custom integration with APIC .