Use Cases and Examples
Start with one workflow for work that's repeatable, easy to verify, and low-risk, then grow it as results build trust. The examples on this page are good starting points.
Choosing your first workflow
Good first workflows share a few traits:
- Repeatable: the same kind of change, many times, such as across dozens of repositories or a recurring ticket type.
- Verifiable: tests, builds, or CI can tell whether a change works.
- Small pieces: each change is independent and quick to review.
- Easy to undo: a mistake is caught in review, or simple to revert.
Leave new features, security-sensitive logic, and fixes to live incidents with people at first, or add more approval steps.
Examples
Ticket to code
Take a bug ticket to a reviewed pull request.
| Step | Type |
|---|---|
| A ticket is labeled for an agent | Webhook trigger |
| Check whether the ticket has enough information | Automation (prompt) |
| If not: comment on the ticket asking for details | HTTP request |
| If so: generate the change and open a pull request | Automation (coding) |
| An engineer reviews the change | Approval |
| Update the ticket | HTTP request |
Dependency upgrades
Keep a library current across every service that uses it.
| Step | Type |
|---|---|
Monthly, at midnight UTC on the 1st (0 0 1 * *) | Schedule trigger |
| Check for available patch and minor versions | Automation (prompt) |
| If none: post to Slack | HTTP request |
| If some: open a tracking ticket | HTTP request |
| Upgrade the library and open pull requests | Automation (coding) |
| Owners review the changes | Approval |
Vulnerability fixes
Patch a vulnerability everywhere it appears.
| Step | Type |
|---|---|
| A scanner reports a finding | Webhook trigger |
| Triage the finding and identify affected services | Automation (prompt) |
| Generate the fix and open pull requests | Automation (coding) |
| Service owners approve | Approval |
| Wait for CI to finish | Wait |
| Post a summary to the security channel | HTTP request |
Standards alignment
Bring services in line with a standard, such as adding secret scanning to every repository.
| Step | Type |
|---|---|
| Started manually for the services that fail a scorecard check | Manual run |
| Add the missing configuration and open pull requests | Automation (coding) |
| Owners review the changes | Approval |
Incident response (no code)
Get the right people moving when an alert fires.
| Step | Type |
|---|---|
| An alert fires | Webhook trigger |
| Gather the service's owners, dependencies, and recent changes | Automation (prompt) |
| Open an incident and notify the owning team | HTTP request |
Growing a workflow over time
Most workflows start with a person reviewing every step, then loosen as results build confidence. A typical path:
- Start supervised: run it manually on a few services, with an approval before every change.
- Widen the reach: run it across more services once changes merge with few edits.
- Add a trigger: let tickets, alerts, or a schedule start runs on their own.
- Remove approvals where they're not needed: keep them for services or changes that need a person, and drop them for routine ones.
Each step should be backed by results from the workflow's own runs. If failures or reverts increase, add approvals back.
Updated about 6 hours ago