Routines
Design recurring work with a clear trigger, useful output, and a way to pause it.
Give repetition a purpose
A routine should produce a useful result each time it runs. Start with the decision it supports: a weekly readiness review, a check for changed dependencies, or a summary of unfinished work. Repetition alone is not a reason to create more activity.
Define the trigger, responsible owner, input sources, and expected output. A schedule should include its time zone. An event-driven routine should explain which change triggers it and how repeated events are handled.
Keep every run bounded
A routine needs the same task and approval boundaries as one-off work. Give each run a budget, a stop condition, and a rule for missing information. A recurring trigger should not expand permission to publish, send messages, or make external changes.
Decide what happens if one run has not finished when another would begin. The proposed model should make overlapping work visible and avoid creating duplicate tasks for the same result.
A weekly release reviewEvery Monday at 09:00 in the team's chosen time zone, collect the current readiness notes. Report changes, unresolved dependencies, and decisions needed. Prepare an update; require separate approval before distributing it externally.
Define when people should hear from it
- Notify when the result changes a decision or needs attention.
- Keep unchanged checks quiet unless a regular report is useful.
- Explain failures with the attempted action and next step.
- Provide a clear owner and a way to pause the routine.
- Review its purpose, access, and budget periodically.
For now, use these questions to plan a routine rather than schedule one through the preview. Persistent run history, notifications, automatic triggers, and background execution remain planned capabilities.