Tools for Writing Tools for Agents

Table of Contents

2026 is turning into a good year for CLIs. And how do we help agents write CLIs for agents and humans to use? With more CLIs, of course!

Here are two tools I’ve been building so my agents can write more tools.

Tool #1: Let the Agents Demo Their Work

I was impressed by Simon Willison’s Showboat and Rodney. Showboat creates executable demo documents - markdown with code blocks that an agent runs, captures output, and a verifier can re-execute to confirm the results match. Rodney drives a persistent headless Chrome instance from the command line. Together, they let an agent prove its web-facing work.

Showboat captures command output as text, but not interactive TUI output. What I wanted was a GIF of a CLI/TUI in action. Then I remembered VHS from the folks at Charm. VHS writes terminal recordings as code. You define a .tape file - a declarative script of terminal actions - and VHS renders it to a GIF or MP4.

Output demo.gif
Set FontSize 14
Set Width 1200
Set Height 600

Type "gh repolint"
Enter
Sleep 5s

This is a natural fit to help agents demo their work. The agent writes the code, writes the tape to demo the code, and produces the demo artifact in the PR branch. The tape file is a reproducible, diffable, and version-controlled script. And the GIF is the output artifact that a human can watch without running anything. Perfect for a demo comment on a pull request.

And the GIF is diffable! You can see the before and after side by side, which is great for demoing bug fixes.

The demo.yml workflow lives in my TUI repos.

The security model

I wanted each new PR to generate a GIF and commit it back to the branch. This sounds simple, and yet it is far from it. Writing to a PR branch from a workflow introduces three interconnected problems:

  1. Triggering downstream workflows. By design, commits made with GitHub Actions’ default token cannot trigger other workflows. This prevents infinite loops, but it also means your branch protection checks won’t run on the new commit. All my repos require checks to pass on the latest commit before merging.

  2. Circular dispatch. If you solve #1 by using a token that can trigger workflows, you must then guarantee the new commit doesn’t re-trigger the same workflow, creating a loop.

  3. Arbitrary code execution. The workflow builds and runs code from the PR branch, and that workflow will have write-capable tokens to commit back to the branch, which creates the potential for a pwn request to exfiltrate credentials.

The solution I landed on uses workflow_dispatch with a GitHub App token:

  • No circular triggers. workflow_dispatch can only be invoked manually, and workflow_dispatch is restricted to users with write access.
  • Downstream CI fires. The GitHub App token (via actions/create-github-app-token) produces commits that do trigger downstream workflows, so branch protection checks run on the generated commit.

The workflow generates the GIF, commits it to the PR branch, and posts a sticky comment with the result. It’s a small amount of friction to dispatch the workflow, but any other solution I tried introduced a large surface area and many edges to protect against. For private repos, this is less likely to be an issue, and triggering the workflow with issue_comment is a nice improvement.

Tool #2: Linting Repositories with gh-repolint

Each CLI should get its own repository, with separate release cycles, collaborators, issue trackers and dependency graphs. But more repos means more toil, more configuration, branch protection rules, merge settings, and CI workflows. The more items under control, the more the repos drift from each other.

So I wrote gh-repolint, a GitHub CLI extension that lints repositories against a set of configurable standards.

gh extension install sethrylan/gh-repolint
gh repolint

It checks repository settings (merge policies, Dependabot, branch protection), validates that required files exist and match reference templates, audits GitHub Actions, and verifies rulesets. Most of what it finds is auto fixable. On a brand new repo, the first command I run is gh repolint --fix to get the settings in place.

Configuration lives in .repolint.yml, at both the repo and org level. Org-level config lives in my sethrylan repo and sets the baseline. gh repolint config shows the merged result with color-coded source annotations.

The part I like most: reference files. Point a check at a template in your org repo (me/me/.repolint/workflows/ci.yml), and gh-repolint will verify the file exists and matches - or create it with --fix, for a single source of configuration.

What’s next?

Building with agents demands a shorter and more secure feedback loop, and I’m eager to see the next generation of CLIs that come out this year. The best ones will enable both humans and agents, in a collaborative loop that humans guide and review, and agents execute and demo. I expect more tools like Rodney and Showboat, and more modes of pre-release artifacts, branch deploys, and short-lived demonstration environments.