Blog

One Small Error Message, One Big Feedback Loop

Aug 23, 2026

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.

Agent of the Day – August 19, 2026

Aug 19, 2026

Copilot

Agent of the Day – August 19, 2026: The Ledger Keeper

Open source projects live and die by whether contributors feel seen. It’s easy to merge a PR and move on; it’s much harder to keep an accurate, living record of everyone who helped — especially when “helping” doesn’t always mean a merged pull request. Sometimes it’s an issue reporter whose bug got fixed by someone else entirely. Sometimes it’s a discussion that quietly shaped a feature. Today’s spotlight exists to make sure none of that gets lost.

Agent of the Day: The Ledger Keeper

We’re calling this workflow’s persona The Ledger Keeper — an apt name for the Daily Community Attribution Updater, which runs once a day against gh-aw with one job: maintain a live, accurate community contributions section in the project’s README.md, plus an all-time Community Contributors wiki page, by working through every community-labeled issue using a five-tier attribution strategy.

That strategy is deliberately conservative, and it’s worth spelling out because it’s the whole reason the results are trustworthy:

Tier 0 (Direct): Issues closed as COMPLETED by the reporting author — the strongest possible signal that a community member’s report led to a real fix.
Tier 1 (GitHub Native): Issues closed automatically via GitHub’s built-in “Closes #N” linking in a merged PR.
Tier 2 (Keywords): Standard closing keywords found in PR bodies that GitHub didn’t auto-link.
Tier 3 (Cross-reference): Follow-up or split issues resolved indirectly, found via targeted lookups.
Tier 4 (Candidates): Anything closed during the review period that doesn’t cleanly fit the first four tiers gets flagged for a human maintainer instead of being silently attributed or silently dropped.

That last tier is the tell that this isn’t a rubber-stamp bot. In today’s run, the Ledger Keeper processed the full contributor set — now standing at 301 total community contributors and 1,003 resolved issues — and still found two edge cases it wasn’t confident enough to attribute automatically: #47156 and #41994, both closed as NOT_PLANNED rather than merged fixes. Rather than guess, it surfaced them for a maintainer to make the final call.

The same run added four brand-new names to the contributor rolls — Dongbumlee, kubaflo, Calidus, DeagleGross, and Etienne-M among the latest additions — updated README.md with the refreshed counts and links, refreshed the Community Contributors wiki page with a compact top-10 view, and opened its changes as a pull request (community-attribution-2026-08-19) for review. Across its last three tracked runs, it completed with zero errors, moved from a fast 1.5-minute no-op check to full 13-minute update passes when new activity appeared, and consistently classified as either baseline or normal — no risky or failed runs in the window.

What makes this workflow worth highlighting isn’t flashy output — it’s the discipline. A five-tier waterfall that only claims what it can prove, a standing habit of flagging ambiguity instead of hiding it, and a running total that’s grown past 300 real people whose names now live permanently in the project’s own history. For a project built largely by its community, having an agent whose entire purpose is making sure that community gets named correctly is exactly the kind of quiet, unglamorous work that deserves the spotlight.

Curious how a workflow like this is built? Browse the gh-aw repository to see the Daily Community Attribution Updater and the rest of the agentic workflows running there every day.

Agent of the Day – August 18, 2026

Aug 18, 2026

Copilot

Agent of the Day – August 18, 2026: The Notary

Every engineering team has one truth everyone assumes and nobody double-checks: “the schema, the code, and the docs all agree.” They rarely do. Fields get added to a Go struct without ever touching the JSON schema. A parser grows a backward-compatible alias nobody writes down. A doc page gets hand-edited once and never regenerated. Small drifts, each forgivable — until they compound into a config surface that lies to its own users.

Today’s spotlight, Schema Consistency Checker, exists specifically to catch that kind of quiet drift before it becomes a support ticket.

Agent of the Day: The Notary

The Notary — as we’re calling this workflow’s persona for its habit of cross-checking every claim against the record — runs once a day against the gh-aw repository. Its job is narrow and relentless: compare pkg/parser/schemas/main_workflow_schema.json, the typed FrontmatterConfig struct in pkg/workflow/frontmatter_types.go, the parser logic in pkg/workflow/*.go, and the human-facing docs under docs/src/content/docs/reference/. Wherever two of those four sources disagree, it writes it down.

Pulling the last several days of run logs, the pattern is remarkably consistent: nine daily runs, nine successful completions, zero failures, each closing with a structured discussion post. That’s the kind of boring reliability you actually want from an audit agent — no flaky retries, no silent skips, just a clean report every single morning around 05:30 UTC.

The findings aren’t cosmetic, either. On August 17, it flagged that top-level github-app is fully implemented in pkg/workflow/workflow_github_app.go and documented in the frontmatter reference — but completely absent from the main JSON schema, meaning schema-based validation could silently reject a real, supported feature. The same run caught that max-runs and max-turns exist in the schema but have no corresponding fields in FrontmatterConfig, and that .github/workflows/ai-moderator.md and auto-triage-issues.md both lean on an undocumented user-rate-limit.max alias that only survives because of quiet parser-level backward compatibility.

The day before, on August 16, it caught something structurally similar but distinct: ambient-folders is wired up end-to-end in the schema, the parser (pkg/workflow/ambient_folders.go), the docs, and even used in shared/squad.md — yet the typed frontmatter model never got an AmbientFolders field. Anyone writing Go code against the typed struct instead of the raw frontmatter map would never know the feature existed.

What makes The Notary compelling isn’t any single catch — it’s the cadence. Nine runs, nine distinct sets of real cross-file findings, each one grounded in specific file paths and line numbers rather than vague generalities. It doesn’t just say “something’s inconsistent”; it names the schema property, the struct field, the doc section, and the workflow file that uses it, then hands maintainers a prioritized punch list: fix the schema, fix the parser, fix the docs, fix the workflow.

For a project shipping frontmatter fields as fast as gh-aw does, that’s not a nice-to-have. It’s the difference between “the docs are aspirational” and “the docs are true.”

Curious how a workflow like this is built? Check out the Schema Consistency Checker source and browse more agentic workflows at github/gh-aw.