Engineering Ops Desk Official

Every weekday morning it reads the open pull requests from source control, updates the age and status of each, and for anything waiting more than 24 hours drafts a short nudge to the reviewer. Nudges are sent behind approval. Never merges, never comments on the PR itself.

1. 01Read the open pull requests for every Active service's repository from source control. Create or update the Pull Requests rows: Number, Author, Reviewer, Opened, Age Hours, Size, Status, Link. Output: The pull requests updated, one line each, plain text.
2. 02For each PR with Status "Waiting for review" and Age Hours over {{hours}} (default 24), not a draft and not from a dependency bot, write the nudge into Nudge: two lines to the reviewer per the handbook. For XL PRs write a note to the author instead. Send each nudge with Turtle Notify (this waits for a person) and set Nudged. Plain text. Output: The nudges drafted, plain text.

When a failed run is logged it reads the run from CI, classifies the failure (test, build, infrastructure, flaky), finds the last green run on the branch, and drafts the note for the author with the failing test or error and the likely cause. Flaky tests are recommended for quarantine. Never reruns or cancels a pipeline.

1. 01Run {{run}} for {{service}} on {{branch}}, failed step "{{failed_step}}", author {{author}}, link {{link}}. Read the run and its logs from CI. Find the first real error. Find the last green run on the branch and the recent failures of the same step on main. Output: The failing step, the first error, the last green run and the recent history, plain text.
2. 02Classify per the handbook and set Kind. Count Times Failed. Write the Triage note for the author: what failed, the error (one line), the likely cause, what to do. If flaky, recommend quarantine and say which test. Set Status Triaged. Plain text. Output: The triage note, plain text.

Every 30 minutes it reads new error groups from the error tool, keeps the ones above the handbook's threshold, checks the issue tracker for an open issue that already covers each, and drafts the ticket with the stack trace, the count and the users affected. Creating the issue waits for a person.

1. 01Read error groups new or spiking in the last {{minutes}} minutes (default 30) from the error tool. Keep those over the handbook's threshold. For each, search the issue tracker for an open issue that covers it. Output: The error groups over threshold and whether an issue exists, plain text.
2. 02For each error with no issue, create or update the Error Groups row (Error, Service, Error Tool Id, Occurrences 24h, Users Affected, First Seen) and write the Ticket Draft: title, service, first seen, counts, stack trace, the release it started in. Create the issue in the tracker (this waits for a person), put its link on the row, set Status Ticketed. Plain text. Output: The rows written and the tickets drafted, plain text.

When an incident opens it starts the timeline from the on-call tool's alerts and the monitoring tool's signals, and keeps it up to date. When the incident is marked Resolved it drafts the post-mortem per the handbook's template: what happened, impact, timeline, root cause, actions with owners.

1. 01Incident "{{incident}}" on {{service}}, {{severity}}, status {{status}}. Summary: {{summary}} Read the incident, its alerts and notes from the on-call tool, and the service's error rate, latency and throughput from monitoring for the incident window. Read the runbook for this service. Output: The alerts, notes, signals and the runbook, plain text.
2. 02If the status is Resolved: draft the post-mortem per the handbook's template into Post-mortem and the actions with owners into Actions, then set Status "Post-mortem drafted". Otherwise write or extend the Timeline: one line per event, time first, what was seen, what was done, by whom. Blameless. Plain text. Output: The timeline or the post-mortem draft, plain text.

Every Monday it reads every flag, checks its age and whether the code still references it, and recommends removal for flags older than 90 days that are fully on or off, or referenced nowhere. Never changes a flag.

1. 01Read every flag with Status Active or Keep. For each, search the service's repository for the flag key and set Referenced In Code. Update Age Days from Created. Output: Each flag with its age and whether the code references it, plain text.
2. 02For each flag older than {{max_age_days}} days (default 90) that is fully on or off, or not referenced in code, write the Recommendation (age, state, files referencing it, what to remove) and set Status Remove. Plain text. Output: The recommendations, plain text.

When a release is logged it reads the pull requests merged since the previous release from source control, groups them into Fixed, Improved, Changed and New, and drafts the customer-facing notes in plain words. A person approves and publishes.

1. 01Release {{version}} of {{service}} on {{date}}. Find the previous release of the same service in Releases. Read the pull requests merged between the two from source control. Drop internal-only changes (dependency bumps, CI, refactors with no visible effect). Output: The pull requests included and the ones dropped, plain text.
2. 02Write the Release Notes: Fixed / Improved / Changed / New, one plain sentence per item per the handbook. Put the PR numbers in Pull Requests Included. Leave Status Drafted. Plain text. Output: The release notes, plain text.

Every Monday it counts the pull requests merged, the median review time, the CI pass rate, new error groups and incidents from the tables, writes the digest with what shipped and the three things to fix, and emails the engineering manager.

1. 01Week starting {{week}} (default last Monday). Count PRs merged, compute median review hours (Opened to merged), CI pass rate (runs minus failures over runs), new Error Groups, Incidents opened, and list the Releases published. Output: The numbers as plain text lines.
2. 02Write the digest: the numbers as short lines, "Shipped:" one line per release, "Fix this week:" three items with owners. Create the Weekly Digest row. Email it with Turtle Notify. Under 250 words, plain text. Output: The digest as sent, plain text.