What the agent does
The agent starts from the Linear issue and the repository in its own sandbox, and finds how the Cobra root command is defined. In a codebase like charmbracelet/glow (module charm.land/glow/v3, Go 1.26.7, Cobra v1.10.2), main.go declares rootCmd with Use: "glow [SOURCE|DIR]", ValidArgsFunction that currently returns ShellCompDirectiveDefault with no file filter, and subcommands config and man via rootCmd.AddCommand. There is no checked-in documentation that walks through glow completion bash|zsh|fish, and glow_test.go only parses flags such as -p, -s and -w.
Cobra already ships a hidden completion command on the root when using the default setup, so the agent verifies that glow completion bash, zsh and fish emit scripts, documents those commands in the README, and tightens ValidArgsFunction so file arguments complete Markdown files (for example *.md) instead of every path. It keeps directory completion where Glow treats a directory as a README search, matching sourceFromArg behaviour.
It extends tests: golden or substring checks that completion bash|zsh|fish output looks like shell functions, and that the Markdown file completer returns only matching names for a temp directory fixture. It runs go test ./... from the module root.
Last, it opens a pull request that links the Linear issue, shows the README snippet users can paste into their shell rc files and lists the ValidArgsFunction change with the new tests.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add Shell Completion to a Go CLI. Document and test Cobra's completion command for bash, zsh and fish, and make file arguments complete Markdown files only.\" Do the work in this repository, add tests for it, run go test ./..., and open a pull request that links back to the issue.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a pull request on its own branch. The description explains that Cobra's completion subcommand was available but undocumented, that ValidArgsFunction accepted any file, and that the change documents bash/zsh/fish setup and filters completions to Markdown. The Linear issue is linked.
The transcript keeps go test ./... with output from the new completion tests and the existing flag tests in glow_test.go. No invented timing claims; the session record is the proof.
Before merging, a reviewer runs one completion script locally if they want, checks that directories still complete when appropriate, and confirms the README commands match Cobra's actual subcommand names for the pinned Cobra version.
Run it on every Linear issue labelled agent
In the console, an automation with a linear trigger on linear.issue.labeled and the label agent starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.
From your own server, the same run is one POST /o/{org}/sessions per issue: put the repository in resources, and add the issue's https://linear.app/<workspace>/issue/<ID> URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts run.completed or run.failed when the turn finishes, with the session_url to read the result.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Completion behaviour is easy to break with a wrong ShellCompDirective, and the failure only shows up inside generated shell scripts. In a Rush sandbox the agent generates those scripts with the real binary under test, asserts on them in go test and keeps the log, without installing completion into the reviewer's interactive shell.
A Linear label turns into a documented CLI change with tests on its own branch. Several CLI polish issues can run in parallel sandboxes, each capped by the key's max_concurrent limit, with the transcript proving completion output was checked.
Frequently asked questions
Does it install completion into my shell rc automatically?
No. It documents the glow completion … (or your binary's) commands and how to source them. Installing into a user's home shell is left to the reader.
What about PowerShell?
The issue names bash, zsh and fish. The agent covers those three; PowerShell can be a follow-up issue if the team wants it.
Will non-Markdown files become impossible to open?
Completion filtering only affects tab completion suggestions. Passing a path on the command line still works the way sourceFromArg already does.
Cobra already has a completion command. Why a PR?
Because undocumented completion and an open ValidArgsFunction are what users trip on. The PR makes the shells explicit in the README and locks Markdown filtering with tests.