Write a Linear ticket an agent can run

Turn repo evidence into a reviewed issue, choose its Linear fields, and publish only after approval.

Last updated August 2026Copy a starter prompt ↓

Draft from the outcome and repo reality

A useful agent ticket connects the user outcome to the code, rules, acceptance checks, and stop conditions that will govern the work. Brief can prepare that draft without creating anything in Linear.

Ask your coding agent

Use Brief to draft a Linear ticket for <outcome or problem>. Inspect the relevant repo context, team rules, current behavior, closest reusable implementation, owners, and focused validation. Write a concise title, user value, scope, acceptance criteria, validation, risks, stop conditions, and the proof the future mission should return. Keep unresolved product decisions as questions. Do not publish yet.

Choose issue fields instead of inferring them

Ask your coding agent

Show me the Linear-ready draft, then ask me to choose the team and any assignee, status, labels, cycle, project, priority, due date, estimate, or parent issue. Leave fields I did not choose unset. Do not infer priority, ownership, or scheduling from the ticket text.

Use an exact name or UUID when a Linear field is ambiguous.
Use “me” for the connected user or “current” for the active cycle only when the user chooses it.
Assign a human in Linear; delegate agent work through the Brief mission separately.
Keep the issue in preview until the draft and fields receive explicit approval.

Publish the approved issue once

Ask your coding agent

Show me the final draft and the exact Linear team and fields you will apply. After I approve this exact version, create the issue once, return its identifier and URL, and verify the saved properties. If a name is missing or ambiguous, stop and ask for the exact value or UUID instead of guessing.

Start the mission from the created issue

Ask your coding agent

Start a Brief mission from the Linear issue you just created. Re-read the saved issue, preserve its approved scope and fields, verify its assumptions against the current repo, and return progress only at real transitions: started, blocked, ready for review, completed, or cancelled. Attach concise next steps and proof instead of a running transcript.

Was this guide useful?Help us make Brief easier to learn.

Ready for another workflow?Choose your next mission →