# Add Shell Completion to a Go CLI from a Linear Issue

Yes. An agent picks up the Linear issue, documents and tests Cobra shell completion for your Go CLI, runs go test and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/add-shell-completion/go-cli/), in a Project that has your repository.

## 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`

```json
{
  "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"
    }
  ]
}
```

1. **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.
2. **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.
3. **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.

## 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.