From Linear issue to tested pull request
Turn a Linear issue into an implementation task with clear acceptance checks, decide what the agent may touch in the tracker, and review the result against the ticket.

Implementation got cheap. Tickets didn't get any clearer. A ticket can be ready for a planning meeting and still be nowhere near ready for an agent. "Make exports handle large accounts" captures a concern. It leaves open whether the problem is a timeout, a memory limit, or a product expectation that hasn't been decided.
Before delegating a Linear issue, identify the observable behavior you want changed. The agent can investigate missing implementation details. It should ask when the missing detail is a product decision.
Pick the repository first
A Linear issue names a symptom, not a codebase. "Exports time out" could be a bug in the API, the worker that builds the file, or the frontend that polls for it. Decide which repository and base branch the agent starts from before it reads a line of code, particularly when similar service names appear across repositories.
If the ticket spans repositories, split it. One agent working in two checkouts against one vague description produces two incomplete fixes and a merge conflict.
If you don't want to do that routing for every ticket, Hoplite's Linear integration maps a Linear team to a repository once, and each run then starts from the issue itself.
Put the acceptance check in the prompt
Take an issue about duplicate rows in a CSV export. A useful description says which export is affected, gives a sanitized example, and explains what the exported result should contain.
You might delegate it with this prompt:
Implement the CSV export issue linked below. Reproduce the duplicate-row behavior using development fixtures. Each invoice should appear once, including when it has several line items. Preserve the existing column order and formatting. Add a regression test with a multi-line-item invoice, run the export tests, and prepare a draft PR. Ask before changing the export schema or introducing a new dependency.
The acceptance check names a business property: one row per invoice. It leaves the agent room to find the cause without giving it permission to redefine the export.
If the ticket lacks the required example, ask the agent to investigate and return a short explanation before editing. That first pass can turn a vague ticket into a precise one without producing a speculative implementation.
Tracker permissions
Attaching an issue reference to a task is not the same as authorizing the agent to read or write the tracker. Most integrations treat the link as metadata. Asking for an implementation or a pull request doesn't authorize status changes either.
If you want the agent to read the latest issue discussion, say so. If you want a completion comment after review, authorize that separately and specify what it should include. For example:
Read the linked Linear issue and its comments for acceptance criteria. Do not change its status or post updates. Summarize any conflicting requirements here before implementing.
That prevents the ticket getting marked complete because a branch exists somewhere.
Review the result against the issue
Inspect what the agent ran as well as what it wrote. Read the commands, the test output, and any approvals it asked for. If it paused on something and nobody answered, the summary may describe work that didn't finish.
For the CSV example, inspect an actual generated fixture output in addition to the test assertions. Check row count, column order, and formatting. Ask the agent to state the commands it ran and any failures it couldn't resolve. A passing unit test doesn't answer whether a consumer still accepts the file if the test never checks its format.
Keep the resulting PR focused enough that a reviewer can compare it directly with the issue's acceptance criteria. Put unrelated cleanup into a separate PR. Leave auto-merge off. Once the patch is reviewed and merged, update Linear according to the team's normal convention, with explicit authorization if the agent does that step.
Pick one issue that already has a reproduction and expected result. Make the first review about whether the delivered behavior matches the ticket.