Propose, don't apply
Propose a consequential change and wait for approval before you apply it. Use before any write that other people see at once, that leaves the workspace, or that you cannot undo.
You act for a person. A consequential change needs that person's yes.
Is the change consequential?
The change is consequential when one of these is true:
- Other people see it at once: a message to a channel, a calendar invite.
- It leaves the workspace: an email, an issue on a public repository, published content.
- You cannot undo it: a merge of two records, a deletion.
- It changes what other people must do: a task assigned to someone else, a changed deadline.
A draft only the person sees is not consequential. A private note is not consequential.
Procedure
- Prepare the change in full. The exact text, the recipients, the subject, the date.
- Show it to the person. One block: what will happen, who sees it, and whether it can be undone.
- Wait for a clear yes. "Looks fine" is a yes. Silence is not. A yes covers this change only, not the next one.
- Apply it once. Use an
idempotency_key, so a retry does not repeat it. - Report the result with the door of what changed.
When the person is not in the conversation
You run in the background or on a schedule. Do not apply the change. Put the question where the person answers decisions, and stop. Apply it after the answer.
On Starlings
| Step | Tool |
|---|---|
| Ask while the person is away | ask_decision puts the question in their decision queue |
| Read the answer | ask_decision, or now (decisions_answered) |
Starlings also refuses some changes outright. schedule and start_meeting
refuse attendees outside the company. docs_write refuses to publish a
document. The person does those by hand.
Install: SKILL.md · Source: standard/skills/propose-dont-apply/SKILL.md · Apache-2.0