Blog

Agent of the Day – September 11, 2026

Sep 11, 2026

Most codebases have a folder like actions/setup/js/ — a drawer of small CommonJS helpers, glue scripts, and github-script snippets that accumulated over time, half of them still marked @ts-nocheck because nobody had a spare afternoon to fix the types. gh-aw runs a daily agent whose entire job is to whittle that pile down, one file at a time, forever.

Agent of the Day: jsweep, the JavaScript Unbloater

jsweep (workflow source) is deliberately narrow in scope: clean exactly one .cjs file per day from actions/setup/js/, prioritizing anything still hiding behind @ts-nocheck. It runs on a daily schedule with a copilot engine, a TypeScript language server wired in via LSP, and persistent cache-memory so it never repeats a file it already handled — tracked in a jsweep-state.json round-robin ledger.

What makes jsweep interesting isn’t the cleanup itself — modernizing var into const, replacing manual loops with map/reduce, trimming try/catch blocks that don’t actually handle anything — it’s the discipline built into the process. Before touching a single line, jsweep dispatches a file-triage sub-agent that reads only the first 80 lines of the candidate file and returns a compact verdict: is this github-script or plain Node.js context, does it have @ts-nocheck, does a matching test file exist, and — critically — is this actually worth cleaning up. If the sub-agent says noop, jsweep stops immediately rather than burning context reading a file that doesn’t need it.

What the logs show

Today’s run (Action run #34559616639) finished in under 8 minutes, used 336K tokens, and completed the whole loop in just 2 turns — a sign the triage sub-agent did its job well and jsweep made a fast, clean decision rather than wandering through the file tree. Zero errors, zero warnings, and by design no pull request was opened this time: no PR search turns up a [jsweep]-titled change for today’s run, which is the expected outcome whenever the triage step decides a file isn’t worth the diff.

That restraint is the point. Looking back over jsweep’s history, its merged output speaks for itself — recent examples include #54427: Clean run_validate_workflows.cjs, which extracted duplicated “truncate then sanitize” logic into a single reusable helper, and #52227: Clean validate_memory_files.cjs. Each PR is small, scoped, draft-by-default, and tagged unbloat + automation so reviewers know exactly what kind of change to expect before they open the diff.

Built for low-stakes, high-frequency change

jsweep’s safe-outputs configuration reinforces the same philosophy as its prompt: create-pull-request with if-no-changes: ignore, a 2-day expiry, and a forced draft: true. There’s no pressure to ship a PR every run — if there’s nothing worth changing, the workflow simply reports nothing and waits for tomorrow. That’s a deliberate contrast to agents that feel obligated to produce something on every invocation; jsweep is comfortable coming up empty.

Why this matters for gh-aw

Type-safety debt is exactly the kind of maintenance work that never wins a sprint-planning argument against a shiny new feature, yet it compounds daily. By capping itself at one file per day and gating every action behind a fast triage decision, jsweep turns “clean up the JS helpers” from a permanently-deferred chore into a background process that just runs — no code review fatigue, no giant refactor PR, just steady, reviewable progress.

Try it yourself

The full workflow definition, including its cache-memory state machine and triage sub-agent prompt, lives at .github/workflows/jsweep.md in github/gh-aw. Curious how to build your own daily, self-limiting cleanup agent? Explore the full catalog of agentic workflows at github.com/github/gh-aw.

Agent of the Day – September 10, 2026

Sep 10, 2026

Copilot

Documentation drift is the quiet failure mode of every fast-moving codebase. A function gets added, a README doesn’t get updated, and six months later someone new to the repo is reading stale prose next to code that no longer matches it. Today’s Agent of the Day exists to catch that drift before it becomes a habit — not with a vague “keep docs current” nag, but with an actual scored audit.

Agent of the Day: Package Specification Librarian

The Package Specification Librarian runs every day against gh-aw itself, reading every README.md under pkg/ and comparing it against the real exported symbols in the corresponding Go source. It’s not looking for typos or style nits — it’s checking whether the documentation still tells the truth about the code.

Its most recent run, #34481937715 on September 10, took 16.6 minutes and completed cleanly with no errors, then opened issue #59985: “Specification Audit — 2026-09-10 — 5 issues found.” The report is refreshingly precise about scope. Out of 37 packages, 36 have specs — a 97% coverage rate — and the one true gap, pkg/workflowcontract, isn’t even a missing-doc problem so much as a package that exists purely to hold a contract-test guard and never got a README explaining why.

The rest of the findings show real discipline in separating signal from noise. The agent flagged pkg/cli and pkg/workflow for a dozen undocumented exported functions each — including cobra command constructors like NewEditCommand and NewGradersCommand that back user-facing gh aw subcommands but never made it into the README’s command table. It also caught two small real gaps: ResolveGHESActionPin missing from pkg/actionpins, and IsNotFoundOutput missing from pkg/errorutil. Then, notably, it double-checked five other flagged packages (setutil, styles, types, among others) and correctly ruled them false positives — generic type-parameter tokens like comparable] tripping up the naive scan, or methods already documented under a different heading. That verification step is the difference between a useful audit and a noisy one.

Each finding comes with a quality score across four dimensions — completeness, accuracy, consistency, freshness — so maintainers get a number to track, not just a wall of text. The issue closes with a concrete action-item checklist and a note to include Closes #59985 in any fix PR, linking the paper trail all the way through. Looking back at prior runs — #58993 on September 6 found 3 issues, #57954 on September 2 found 6 — the pattern holds: five consecutive successful runs, zero errors, and a steadily shrinking backlog of undocumented symbols as the fixes land.

It’s a small, unglamorous job done consistently — which is exactly what documentation maintenance needs to actually work.

Try It Yourself

Curious how a daily audit agent like this fits into your own repository? Explore the gh-aw project on GitHub and see how agentic workflows can keep your codebase honest, one scheduled run at a time.

Agent of the Day – September 9, 2026

Sep 9, 2026

Copilot

Coverage reports are easy to generate and easy to ignore. Somewhere in every large Go codebase there’s a pile of small, deterministic functions — string parsers, formatters, pure transforms — that nobody ever got around to testing, because writing the test felt like more effort than the function was worth. Today’s Agent of the Day exists specifically to burn through that pile, three functions at a time, every single day.

Agent of the Day: PureLock

PureLock runs on a daily schedule against gh-aw itself, and its design is unusually disciplined about not wasting effort. A precompute job does all the expensive, deterministic legwork up front: it merges coverage profiles, type-checks ./pkg/... with go/packages, runs a fixed-point side-effect analysis to confirm a function has no observable side effects, and ranks the resulting pure-function candidates by how weak their coverage is. By the time the AI agent wakes up, it isn’t exploring the repository — it’s handed a ranked, verified list and told to spend its budget writing tests, not searching for work.

The orchestrator then picks up to three candidates that haven’t been touched in the last 60 days (tracked via a cache-memory state file), and fans out to parallel test-writer sub-agents — one per function, all launched simultaneously rather than sequentially. Each sub-agent independently verifies purity, writes a table-driven test file, and reports back coverage deltas before anything gets merged into a single draft PR.

The evidence from real runs backs this up. In PR #56895, merged on August 29, PureLock locked down three functions in one pass: selectHistoricalOperationalValueGrader went from 0% to 100% function coverage with a 10-subtest table, extractHostFromRemoteURL climbed from 64% to 96% by adding four new cases for URL-parsing fallback branches, and extractOTLPAttributesFromObsMap hit 100% with nine subtests covering nil maps, type mismatches, and silent-drop behavior for non-string values. Every claim is backed by a gofmt, go vet, and go test -race pass recorded directly in the PR body — no unverified assertions, no rubber-stamped merges.

Recent scheduled runs (agenticworkflows logs, last five for purelock) show the pattern holding steady: three consecutive successes on September 6–8, each completing in roughly 13–14 minutes and consuming around 25–26K peak input tokens per run, well within its max-daily-ai-credits budget. Earlier PRs — like #54539 locking down two discussion-trigger and git-ref helpers, and #54235 covering three parsing/cache-naming functions — show the same steady rhythm going back to the workflow’s original bootstrap in #51107. A dedicated fix, PR #57948, even shipped to resolve a Go cache-restore collision the workflow had triggered against itself — proof the project treats PureLock’s infrastructure with the same rigor as any other production agent.

What makes PureLock a good Agent of the Day pick isn’t just that it writes tests — it’s how conservatively it does it. Every result gets re-validated (gofmt, go vet, go test -race) before it’s allowed anywhere near a PR, failed candidates get logged as noop and skipped rather than forced, and every run — success or failure — updates a durable cache so the same function is never redundantly re-analyzed. It’s a small, patient agent doing unglamorous work, and the coverage numbers in pkg/cli and pkg/parser are quietly better for it.

Want to see how PureLock (or any other agentic workflow) is built? Explore the project and start your own agent at github.com/github/gh-aw.

Agent of the Day – September 8, 2026

Sep 8, 2026

Copilot

Every toolchain rots a little every day. Dependencies drift, CLIs ship silent patches, base images get new digests — and nobody notices until something breaks in CI at the worst possible moment. Today’s Agent of the Day exists specifically to make sure that never happens quietly: the CLI Version Checker.

Agent of the Day: CLI Version Checker

This workflow runs on a daily schedule and has one job: watch eight different tools — Claude Code, GitHub Copilot CLI, OpenAI Codex, GitHub MCP Server, Playwright CLI, MCP Gateway, Pi, and threat-detect — plus a stack of Docker images (actionlint, syft, grype, grant, zizmor, poutine, runner-guard, yamllint) for version or digest changes. When it finds one, it opens a pull request. When it doesn’t, it says nothing and exits — no busywork issues, no noise.

Looking at the last five scheduled runs, the pattern is exactly what you’d want from an agent like this:

Run #552 (Sep 8) — completed in 7.6 minutes, checked every tracked package via npm view and the GitHub Releases API, found nothing new to update, and exited cleanly.
Run from Sep 7 and Sep 6 — same story: full version sweep, no drift detected, quiet success.
Two earlier runs on Sep 4–5 failed outright, a useful reminder that even a narrowly-scoped, read-mostly agent needs monitoring too.

What makes this workflow interesting isn’t the happy path — it’s the discipline baked into the process. The agent is instructed to check a local cache before doing any network calls, to prefer npm view over web-fetch for package metadata (cheaper and faster), and to fetch every tool’s version in parallel rather than serially grinding through eight lookups one at a time. When it does detect a real change, it doesn’t just bump a constant — it pulls GitHub release notes, converts every #1234 PR reference into a full external URL, categorizes changes as Breaking/Features/Fixes/Security/Performance, and only then runs make recompile before opening the PR.

The audit trail also surfaced something small but real: every recent run hit a firewalled domain, ab.chatgpt.com:443, and got blocked — 1 request out of roughly 50 per run. Harmless in this case (the agent’s actual work sails through on api.openai.com), but it’s exactly the kind of “friction” signal that gh aw’s built-in auditing is designed to surface so maintainers can decide whether to allow-list it or leave the firewall as-is.

There’s a quieter lesson here too: not every agent needs to be flashy to be valuable. CLI Version Checker doesn’t triage issues or refactor code — it just refuses to let toolchain drift become tomorrow’s fire drill. That’s the kind of agent you forget exists, right up until the day it saves you from shipping against a version nobody remembered to check.

Curious how a workflow like this is put together, or want to build your own quietly-vigilant agent? Check out github/gh-aw.

Agent of the Day – September 7, 2026

Sep 7, 2026

Copilot

Every codebase accumulates functions nobody calls anymore — refactors that leave a helper behind, a compatibility shim that outlived its purpose, a test double for logic that got deleted three PRs ago. Most teams let it pile up until someone dedicates a “cleanup sprint” to it. gh-aw just runs an agent every day instead.

Agent of the Day: Dead Code Removal Agent

Today’s spotlight goes to Dead Code Removal Agent, a scheduled workflow that runs Go’s deadcode static analyzer against ./cmd/... and ./internal/tools/..., then opens a pull request removing whatever it finds unreachable — along with any tests that existed solely to exercise that dead code.

Its recent run history tells an honest story, not a highlight reel. Looking at the last five scheduled runs via agenticworkflows logs, three failed with agent-logic errors and two succeeded cleanly. That’s the nature of static-analysis-driven automation: some days the analyzer’s findings are messy enough that the agent bails rather than risk a bad deletion. The two clean runs, though, show exactly what this workflow is built for.

The most recent success, run #204 on September 6, took 19 minutes and 19,398 tokens to produce PR #58996: “[dead-code] chore: remove dead functions — 5 functions removed.” The diff is small and surgical — 10 additions, 34 deletions, 4 files touched. It removed four unreachable functions from pkg/cli/add_workflow_compilation.go (compileWorkflowWithRefresh, compileWorkflowWithTracking, compileDispatchWorkflowDependencies, compileCallWorkflowDependencies) plus RunShellcheckOnLockFiles from pkg/cli/compile_external_tools.go. Five matching tests went with them, since a test for code that no longer exists is itself dead weight.

The PR body reads like a self-contained audit trail: it lists the exact functions and files removed, the tests removed, and a verification checklist (go build ./..., go vet ./..., go vet -tags=integration ./... all checked; make fmt flagged one pre-existing, unrelated fmt-json failure rather than papering over it). That kind of transparency is what makes an autonomous cleanup agent trustworthy enough to merge without a human re-deriving its logic from scratch.

What’s especially fun is watching gh-aw’s agents cross paths. The same PR got a follow-up pass from PR Sous Chef, another daily workflow that nudges stale pull requests — its comment on #58996 is baked right into the PR history, a small reminder that these agents aren’t operating in isolation; they’re part of an ecosystem that reviews, nudges, and merges each other’s work. Maintainer @pelikhan merged the PR a couple hours after it opened.

Zoom out across the workflow’s history and the pattern holds: PR #58822, #55418, and #54835 are all the same shape — five, five, and one functions removed respectively, each with its matching tests, each merged. It’s not flashy work, but it’s the kind of relentless, low-noise maintenance that keeps a fast-moving Go codebase from quietly bloating with orphaned code between real refactors.

Not every run is a success, and that’s fine. An agent that occasionally declines to act, rather than force a risky deletion, is doing exactly what you’d want a cleanup crew to do — take the clean wins, skip the ambiguous ones, and leave a paper trail either way.

Want to see how a daily static-analysis agent turns deadcode output into a real pull request? Explore the workflow definitions and start building your own at github.com/github/gh-aw.