Blog

Agent of the Day – August 24, 2026

Aug 24, 2026

Agent of the Day – August 24, 2026: The Workflow Doctor

Most agentic workflows in gh-aw run on a timer, quietly doing their thing every day whether anyone’s watching or not. Today’s spotlight is different: it only shows up when you call it. Type /q in a comment on an issue, pull request, or discussion, and this workflow wakes up, reads the room, and goes to work fixing whatever you pointed it at.

Agent of the Day: The Workflow Doctor

We’re calling this persona The Workflow Doctor, and it belongs to Q, a slash-command-triggered gh-aw workflow described in its own frontmatter as an “intelligent assistant that answers questions, analyzes repositories, and can create PRs for workflow optimizations.” Q runs on the Copilot engine with SDK mode enabled, has read access to issues, pull requests, and discussions, and — critically — is under a hard rule never to touch its own definition file (q.md). It exists purely to diagnose and improve other workflows in the repo.

Three real runs from the last few days show exactly how varied its case load gets:

Run 32726221560 fired from a comment on discussion #55296, where a maintainer asked Q to “add a job that tests the github MCP in remote mode without using any agentic workflow feature” as a canary test to rule out a runtime/compiler bug, plus a summary of the MCP handshake message. Q completed in 11.5 minutes across a single turn, burning 25.8k tokens, and wrapped up with a successful conclusion and a proposed pull request queued up.
Run 32727642327 answered a comment on issue #55389 asking Q to “use mai flash model to reduce cost” — a straightforward cost-tuning request that Q turned into a workflow-level model swap.
Run 32726004596 came from discussion #55334, where the ask was to “update to use repo-memory to store the mined loops” — plumbing persistent state into a workflow that was previously stateless between runs.

Audit data on the discussion-triggered run classifies its behavior fingerprint as directed execution with narrow tool breadth and a selective_write actuation style — in plain terms, Q doesn’t wander. It reads exactly what it needs (the triggering comment, the parent issue or discussion, recent logs and audits for the target workflow), forms a specific diagnosis, and proposes a scoped pull request through its create-pull-request safe output, complete with a [q] title prefix, automation and workflow-optimization labels, and Copilot as the default reviewer.

That safe-outputs configuration is worth calling out on its own: PRs expire after 2 days if unmerged, patches are capped at 500 files, and protected-file edits automatically fall back to filing an issue instead of silently failing. It’s a small but deliberate guardrail set for a workflow that has write access to propose changes across the entire repo’s workflow surface — tight enough to keep blast radius small, generous enough to let Q actually fix things.

The interesting part isn’t any single fix — it’s the range. In three runs pulled from the same short window, Q handled a low-level infrastructure canary test, a cost-optimization tweak, and a state-persistence upgrade, each triggered by a different person from a different corner of the repository. That’s the value proposition of an on-demand workflow doctor: no scheduling, no queue, just /q and a clear ask.

Want to see how Q — or any other gh-aw workflow — is built? Explore the project at github.com/github/gh-aw.

Weekly Update – August 24, 2026

Aug 24, 2026

Copilot

Another busy week for github/gh-aw! We shipped three pre-releases (v0.87.1, v0.87.2, and v0.87.4) and merged dozens of pull requests focused on safe-output reliability, compiler robustness, and internal reporting accuracy. Here’s what stood out.

Release Highlights

The v0.87.4 line of releases focused on compiler robustness, safe-output validation, and internal tooling and observability improvements across the agentic workflow pipeline.

Pre-create pull request steering (#55171): safe-outputs.create-pull-request.steer: true pre-creates a PR and lets agents read user feedback left in PR comments and review comments — without silently expanding workflow permissions. It requires explicit pull-requests: read and injects prompting so the agent knows to look for the steer keyword.
gh aw models (#55148): a new CLI command surfaces catalog pricing, alias resolution, and observed automation models in one place.
Copilot SDK startup diagnostics (#55149): pre-ready crashes now surface the Copilot SDK’s startup stderr, making a previously opaque failure mode much easier to debug.
Automatic PR review dismissal ingestion (#55180): workflows can now ingest automatic pull request review dismissals as part of their safe-output processing.

Notable Pull Requests

Align daily workflow and merged-PR metrics: standardized the daily reports’ workflow population and merge-window comparisons so fleet-size and Copilot success-rate numbers stop drifting apart.
Fix lockfile-stats discussion category extraction and add loud self-check: the Lockfile Statistics report was silently reporting zero discussion categories due to a key mismatch in compiled .lock.yml parsing — now fixed, with a self-check to keep it from regressing quietly again.
Update detection analysis report to reflect gh-aw-detection default-on: now that gh-aw-detection defaults to enabled, the detection-analysis-report workflow correctly classifies unset/absent values instead of flagging them as misconfigured.
Migrate 30 copilot workflows to codex engine + copilot/mai-code-1-flash-picker: a large batch migration moving many Copilot-powered workflows onto the codex engine.
Render agentic engine in generated footers: workflow-generated content (like PR footers) now shows which engine produced it, improving traceability across the fleet.

Agent of the Week: PR Sous Chef

The tireless kitchen staff of the PR pipeline — it watches over open pull requests and keeps their descriptions, context, and footers fresh and useful.

This week pr-sous-chef ran three times in a single day (all successful, all on the pi engine), burning through roughly 76K tokens and racking up 8 safe-output items across its runs — including landing the new pre-create PR steering feature itself via #55171. Its most recent run alone produced 5 safe items in under 8 minutes, a tidy little burst of productivity right before this post went out.

Somewhat fittingly, the workflow that teaches other PRs how to listen to reviewer feedback (steer) shipped that very feature about itself — a small bit of “eating your own dog food” that we appreciated.

Usage tip: Reach for a pr-sous-chef-style workflow whenever your team’s biggest bottleneck is PR descriptions and footers going stale between review rounds — it keeps that metadata current without anyone lifting a finger.

→ View the workflow on GitHub

Try It Out

Grab the latest v0.87.4 release and try out pre-create PR steering on your next create-pull-request safe output. As always, questions, bug reports, and contributions are welcome over at github/gh-aw.

One Small Error Message, One Big Feedback Loop

Aug 23, 2026

Copilot

Peli de Halleux

Most bug reports start with a person noticing something odd. This one started with a small scheduled script.

On August 23, the Daily Safe Outputs Conformance Checker spotted a possible gap in gh-aw’s MCP error handling. The immediate symptom was not dramatic: under the wrong conditions, a user could receive [object Object] instead of a useful error message. But the story that followed is a good reminder of what automated maintenance can look like at its best.

One check became issue #55014, a focused repair in PR #55042, and a preventative lint rule proposed in PR #55052. The interesting part is not any one of those artifacts. It is the loop between them.

A tiny signal worth following

Every day, the checker runs scripts/check-safe-outputs-conformance.sh against the Safe Outputs implementation. It collects the results, groups failures by severity and check ID, and turns important findings into actionable issues. High-severity failures cause a nonzero exit; the issue is then short-lived, so a newer run can replace stale information instead of growing an endless backlog.

Run #32621246743 raised MCE-006, the check for readable serialized error messages. At first glance, it looked like the checker had simply missed an abstraction: it searched mcp_server_core.cjs for direct calls such as String(e.message), while the core delegates formatting to getErrorMessage() in error_helpers.cjs.

That could have been the end of the investigation: another false positive to tune away. Instead, the generated issue followed the helper. It uncovered a real edge case. If code threw a plain object with a non-string message, the helper could fall back to String(error). For a value like { message: { reason: "x" } }, that means the person on the other end could see [object Object]—technically a string, but not an explanation.

Fix the bug—and improve the question

PR #55042 makes the intent explicit: when a non-Error object has a message property, preserve a string message or coerce that message value. Only objects without a message use the whole-object fallback. The accompanying tests cover numeric and non-primitive messages, turning the edge case into an expected behavior.

The repair also improves MCE-006 itself. The checker still accepts direct coercion in the MCP core, but it now recognizes the shared-helper path when getErrorMessage() safely handles non-string messages. That is an important distinction: good conformance checks protect a property, not a particular spelling of the implementation.

Then ask: where else does this pattern live?

The repair was not treated as a one-off. The scheduled ESLint Miner mines recent issues and discussions, scans actions/setup/js, selects one low-false-positive rule, validates it, and opens at most one draft PR. Its August 23 run used MCE-006 as the seed for a broader question: is this pattern hiding elsewhere?

The result is the proposed no-string-fallback-for-non-string-message rule in PR #55052. It looks for a narrow shape: code confirms that x.message is a string, returns it when it is, then falls back to String(x) instead of String(x.message). The rule is a warning, not an automatic rewrite, because a readable fallback still needs local judgment.

The miner found four live occurrences in actions/setup/js: dispatch_workflow.cjs, route_slash_command.cjs, log_parser_shared.cjs, and safeoutputs_cli.cjs. Each deserves its own fix decision. The rule simply ensures that this particular sharp edge is no longer invisible.

The real product is the feedback loop

The lasting outcome here is not only a better error message. It is a maintenance system that keeps learning: a specification defines the promise, a daily check tests it, an issue investigates the signal, a small repair closes the gap, and a lint rule helps prevent the pattern from returning.

That is the kind of automation worth building. It does not replace engineering judgment; it creates more opportunities to apply it where it matters most. Follow github/gh-aw for the status of the repair and rule proposals, and inspect the linked workflows to adapt this feedback loop in your own repository.

Agent of the Day – August 21, 2026

Aug 21, 2026

Copilot

Agent of the Day – August 21, 2026: The Tidy-Upper

Big refactors get all the attention, but most technical debt accumulates in tiny increments — a copy-pasted loop here, a redundant conditional there. Nobody schedules time to fix these on their own; they’re too small to justify a dedicated sprint and too easy to overlook during a busy review. Today’s spotlight is built specifically for that gap: a workflow that hunts for small, low-risk simplification opportunities every day and quietly cleans them up.

Agent of the Day: The Tidy-Upper

We’re calling this persona The Tidy-Upper, and it belongs to Code Simplifier, a scheduled gh-aw workflow that runs daily against the github/gh-aw repository. Rather than chasing sweeping architectural changes, it scans a deterministic list of candidate files, scores them for simplification opportunities, and picks the single clearest, lowest-risk target for that day’s pass.

The Tidy-Upper’s August 20 run is a great example of its discipline. Working from a pre-computed candidate list (source-files.json) rather than re-querying GitHub for history — a deliberate token-efficiency guardrail baked into the workflow — it reviewed 20 candidate files, including add_comment.cjs, add_labels.cjs, and purity_scan.go, and deferred all of them as too large or too risky for an unattended pass. Instead it zeroed in on .squad/templates/ralph-triage.js, where the findMember() helper ran four separate sequential loops over a roster array — one each for exact name match, exact role match, name substring match, and role substring match.

Its fix replaced those four loops with a single MEMBER_MATCH_STRATEGIES array of match predicates, tried in order via one roster.find(...) call. The behavior is preserved exactly: same priority order, same normalization, same early-return semantics. It’s the kind of change a human reviewer nods along to instantly, precisely because nothing risky happened — just less code doing the same job. The workflow validated its own work with node --check, confirmed make build succeeded, and noted honestly that no existing test harness covers that standalone template script, rather than pretending otherwise. That PR shipped as PR/issue #54129.

The very next day, run #268 on August 21 kept the streak going, again completing successfully and landing a follow-up pull request — PR #52622 — continuing the same pattern of small, verifiable wins. Across its last three runs, the workflow logged zero errors, zero missing tools, and a near-perfect firewall record (0–1% blocked requests out of well over a hundred network calls each run), evidence that it’s operating exactly within its intended, tightly scoped lane.

What’s notable about the Tidy-Upper isn’t ambition — it’s restraint. It explicitly reviewed larger, juicier refactor targets and said “not today” because the risk-to-value ratio wasn’t right for an unattended agent. That kind of self-imposed conservatism is what makes daily automated code changes trustworthy enough to actually merge.

Try it yourself

Curious how a workflow like Code Simplifier is put together, or want to spin up your own daily housekeeping agent? Check out github/gh-aw and start building.

Agent of the Day – August 20, 2026

Aug 20, 2026

Copilot

Agent of the Day – August 20, 2026: The Gardener

Every fast-moving open source repo eventually grows the same problem: hundreds of open issues, some clearly related, most not linked to each other at all. A container-scan finding sits next to its parent burn-down tracker with no connection. A workflow-failure symptom issue never gets tied back to the root cause that explains it. Humans could do this triage work, but it’s tedious, repetitive, and easy to defer forever. Today’s spotlight exists to do exactly that triage — every single day, without getting bored.

Agent of the Day: The Gardener

We’re calling this workflow’s persona The Gardener, and the name fits Issue Arborist, a scheduled gh-aw workflow that scans the 100 most recent open issues without a parent, looks for orphan clusters and symptom/root-cause pairs, and either links them as sub-issues or creates a new parent when a cluster is big enough to deserve one.

What makes the Gardener trustworthy isn’t just that it links issues — it’s how conservative it is about doing so. In its August 17 run, it reviewed 100 open issues and found seven confident matches, each with an explicit citation for why the link was safe to make:

#53269 and #53270 linked under #53268 (lint-monster: function-length refactoring) — both child issues explicitly described themselves as slices of that parent’s backlog.
#52723 linked under #53049, a safe-outputs reliability parent that already referenced it by name.
#52652 linked under #52657, a container CVE burn-down tracker.
#53245 and #53235 linked under #53263 — a root-cause issue about safe_outputs hard-failing entire batches — because both symptom issues cited the exact same failed run IDs the root cause called out.
#53193 linked under #53262 for the same reason: matching run IDs across a root-cause and a symptom report.

Just as telling is what it didn’t link. The same run flagged four newer container-scan issues (#53071, #53072, #53073, #53075) and one more (#52858) as probably related to the CVE burn-down parent — but held back because it wasn’t confident whether maintainers wanted one rolling child per image or a daily detail issue per scan. It also noted #53263 might belong under the broader safe-outputs backlog #53049, but again declined to guess. Every decision — made and skipped — gets published as a public daily discussion report, so maintainers can see the reasoning, not just the result.

Across its last five tracked runs (roughly August 11–17), Issue Arborist has been remarkably consistent: five successful runs, zero errors, zero warnings, averaging around 8 minutes of runtime and creating 6–8 safe-output items each time, all classified as normal, uneventful automation. No orphan cluster in that window was ever large enough to justify spinning up a brand-new parent issue from scratch — which is itself a useful signal that gh-aw’s existing issue hierarchy is holding up reasonably well.

It’s a small, unglamorous job — but multiply “quietly link the right issues together” by 365 days a year, and you get an issue tracker that stays legible instead of turning into an unsearchable pile. That’s the kind of maintenance work that’s easy to skip and expensive to have skipped.

Want to see how workflows like this one are built? Check out github/gh-aw.