ENGINEERING
Flag breaking OpenAPI changes in pull requests
On every pull request that touches your OpenAPI spec, diff the new spec against the base branch, classify each change as breaking or additive.
How it runs
The automated pipeline, trigger to output.
- TriggerPull request opened or updatedGitHub
- ActionFetch proposed and base OpenAPI specsGitHub
- ActionRun structural OpenAPI diffShell
- LogicAny breaking changes?
- ActionMap breaking paths to affected consumersShell
- OutputPost blocking or approving PR reviewGitHub
What it does
Watches pull requests for changes to your OpenAPI/Swagger file, computes a structured diff against the base branch, and decides whether the change is safe to merge. Breaking changes (removed endpoints, narrowed types, new required fields) get a blocking review; additive changes pass with a note.
When to use it
Use this as a required status check on any repo that publishes an API other teams depend on. It stops accidental contract breaks before they reach a release branch, without forcing a human to eyeball every spec diff.
How it works
- 1A pull request opened or synchronized event fires from GitHub.
- 2The flow fetches the proposed spec and the base-branch spec via the GitHub API.
- 3An OpenAPI structural diff runs in a shell step, emitting a list of changes tagged breaking or additive.
- 4A logic branch checks whether any breaking changes exist.
- 5If breaking, the flow cross-references a consumer map (which services call which paths) to name the affected teams.
- 6It posts a PR review on GitHub: a blocking request-changes comment for breaking diffs, or an approving note for additive-only diffs.
Set it up
What you configure once, before turning it on.
- 1Connect GitHubRepos, issues, pull requests, actions.
- 2Connect ShellRun sandboxed commands inside the workspace.
- 3Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 4Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 5Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More Engineering workflows
Gate breaking API PRs behind downstream consumer acknowledgement
When a PR introduces a breaking contract change, comments the impact summary back on the PR, applies a blocking label.
Publish a versioned API changelog to Confluence on each release tag
On a new semver release tag, gathers the contract changes since the last release and writes a clean.
Agent reviews model-license fit and suggests compliant swaps on the PR
When a PR adds a Hugging Face model, an agent reads the model card and license, judges fit against your commercial-use policy.
Upgrade Impact Router to Module Code Owners
Maps a dependency-bump PR's affected modules to their CODEOWNERS, then DMs each owner on Slack with only the changelog slice that touches code they own.
Re-Voice IVR Prompts on Phone-Tree Config Merge
When a phone-tree config change merges in GitHub, regenerates the ElevenLabs audio for any prompt whose script changed in the diff and opens a follow-up PR adding the new audio…
Upstream Release to Notion Upgrade Brief
When a watched package publishes a new release, fetches the release notes, maps them to the internal modules that depend on it.
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.