# Plan a Linear Issue Against a Go Codebase

Yes. An agent reads the Linear issue and your Go packages, changes no code, and writes a plan: the files to change, the tests to add, the risks and open questions.

[Run this on Rush](https://cloud.getrush.ai/run/plan-linear-issues/go/), in a Project that has your repository.

## What the agent does

A plan run reads and does not write. The agent clones the repository into its own cloud sandbox, reads the issue, and then reads the code the issue touches. Take a feature request against a Gin API like `gothinkster/golang-gin-realworld-example-app`: "Let authors save an article as a draft. Drafts are visible only to their author and appear in no list or feed until published." The agent starts at `go.mod` (Go 1.21, Gin 1.10, GORM 1.25 with the SQLite driver) and the package layout: `users/`, `articles/` and `common/`, each split into `models.go`, `routers.go`, `serializers.go` and `validators.go` with a `unit_test.go` beside them.

Then it follows the data. `ArticleModel` in `articles/models.go` embeds `gorm.Model` and has no notion of state, and the schema comes from `db.AutoMigrate(&articles.ArticleModel{})` in `hello.go`, so a new column is a struct field rather than a migration file. Every reader path has to learn about drafts: `FindManyArticle(tag, author, limit, offset, favorited)` behind `ArticleList`, `GetArticleFeed` behind `ArticleFeed`, `FindOneArticle` behind `ArticleRetrieve` for `GET /articles/:slug`, and the tag branch of `FindManyArticle`, which loads articles through the `ArticleModels` association and would need the same filter. `ArticleModelValidator` binds `title`, `description`, `body` and `tagList`, so a `draft` field is a new binding there.

It checks how tests are written before suggesting new ones. `common.TestDBInit()` opens a SQLite file for tests, `common.HeaderTokenMock` signs a request as a user, and `articles/unit_test.go` drives the routers with `httptest`. The CI workflow in `.github/workflows/ci.yml` runs `scripts/gofmt.sh` and `scripts/coverage.sh` on Go 1.21, 1.22 and 1.23, and a separate job runs the Postman collection in `api/Conduit.postman_collection.json` with newman.

The plan it writes names each file with the reason it changes, the Go tests to add (a draft is absent from list, feed and tag queries; retrievable by its author; 404 for anyone else; publishing makes it appear), the risks, and the questions only the issue's author can answer. One risk the code makes plain: this app implements the RealWorld API spec, and the Postman run checks responses against it, so a new field in the article response has to be additive.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Read the Linear issue in this run's resources and the code it touches in the users and articles packages. Change no code. Reply with an implementation plan: the files to change with the reason for each, the Go testing tests to add, the risks, and the open questions for the author.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    },
    {
      "url": "https://linear.app/your-workspace/issue/ENG-42"
    }
  ]
}
```

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 the plan as the run's answer: the session read returns it as `result`, and a run started by the Linear state trigger posts it as a comment on the issue. It is organised as the prompt asks. A file list with one reason per file, for this example `articles/models.go`, `articles/routers.go`, `articles/validators.go`, `articles/serializers.go` and `hello.go` only if a new model is introduced. A test list naming the cases and the file each belongs in. Then risks and open questions.

The questions are where a plan earns its keep. For drafts in the Gin app they include whether a draft keeps its slug when published or gets a new one, whether favouriting a draft is allowed, whether a published article can return to draft, and whether the RealWorld response shape may gain a field. A reviewer, usually the issue's author or the engineer who will build it, answers those on the issue before anyone writes code.

Nothing is pushed and no branch is created. The session's record keeps every file the agent opened and every command it ran, so a reader can check a claim like "the tag branch of `FindManyArticle` bypasses the main query" against what the agent actually read.

## Run it on every Linear issue moved to Planning

Add an automation to the Project with a Linear trigger on `linear.issue.state_changed` and map a state, such as `Planning`, to `plan` in its `states`. Moving an issue into that state starts a read-only run that posts its plan as a comment on the issue through the runner's Linear connection. Map a later state, such as `Ready`, to `exec` and moving the issue on starts an ordinary run that builds it.

From your own server, the same plan comes from this request with the issue's URL in `resources`; read the plan from the session's `result` when the `run.completed` webhook arrives.

## Why run it on Rush?

A plan is only as good as the code read behind it. On Rush the agent reads the actual repository in its own sandbox, can run `go build` or `go test ./...` to confirm how the code behaves today, and every file and command is kept on the session, so the plan's claims can be checked rather than trusted.

Planning stops being a meeting that waits on one senior engineer. Every issue moved into the planning state gets its own run at the same time, the plans land on the issues where the team already discusses work, and the people who know the product answer the open questions before the build starts.

## Frequently asked questions

### Can a plan run change my code?

A run started by a state mapped to `plan` is read-only and posts a comment. A run started from the API follows its prompt, which here says to change no code and to reply with the plan, and it opens no pull request.

### Does the plan account for my CI?

The agent reads the workflow files along with the code. In the Gin example it sees the gofmt and coverage scripts, the three Go versions in the matrix and the newman job, and writes any of them the change affects into the risks.

### What if the issue is too vague to plan?

Then most of the plan is open questions, which is still useful: it shows the author exactly what is missing. Answer them on the issue and move it back into the planning state to get a revised plan.

### Will it suggest a new database migration tool?

Not unless the issue asks. The agent plans within the codebase's own conventions, and in this app the schema comes from GORM's `AutoMigrate`, so the plan adds a struct field and notes what that means for an existing production database.