Linear · Workflow guide
Linear delivery risk brief with Claude Code
Have Claude Code or Codex read Linear through Loggie, flag blocked and stale work with linked evidence, and draft a planning brief without changing issues.
Who this is for: Team leads who want a reliable planning brief without asking everyone to repeat what is already in Linear.
Before you start
- A Linear connection in Loggie authorized for the intended workspace.
- An agent with read access to the teams and projects in scope. Issue updates are unnecessary for the first version.
- An agreed risk rule, such as a blocker label, a missed due date, or no update within a team-defined interval.
In your Loggie workspace, connect Linear, create an agent identity, and review its access. On the agent’s machine, use Node.js 20 or later and initialize the CLI:
npm install -g @loggie-ai/cli
loggie init
loggie discoverEnter the agent’s Loggie key through the initialization prompt. Keep provider credentials in the connection setup, not in the agent prompt. Use the connection slug returned by discovery in the examples below.
Step-by-step workflow
Decide what counts as a risk
An old issue is not automatically blocked. Choose a few signals the team already understands: an explicit blocker, a due date that has passed, or an active issue with no recent update. Keep these categories separate so the brief does not turn guesses into facts.
Limit the first run to one project or team. Record the timezone and the cutoff used for stale work. A low-noise report is more useful than a workspace-wide dump of every open issue.
Read a bounded set through GraphQL
Connect Linear in Loggie and grant your agent read access. Install the CLI, initialize it with the agent’s Loggie key, and use loggie discover to find the connection. Replace the illustrative linear slug if yours differs.
This query is a smoke test of the issue fields. For the actual brief, add the agreed project or team filter, exclude completed and canceled states, and follow pageInfo.endCursor while hasNextPage is true. Inspect GraphQL errors even when HTTP status is 200.
loggie discover linear --endpoint / --method POST --graphql-type query --operation issues loggie call linear POST / --body '{"query":"query { issues(first: 20) { nodes { id identifier title url updatedAt dueDate assignee { name } state { name type } } pageInfo { hasNextPage endCursor } } }"}' --prettySeparate observed blockers from inferred staleness
Have the agent read relevant issue details and comments for candidates, not every comment in the workspace. An explicit statement that work is waiting on another issue is stronger evidence than an old timestamp.
For each entry, include the identifier, source URL, assigned owner if present, signal, and a concrete next question. If no owner is assigned, say unassigned.
Use the brief to drive the next conversation
Send the result to the team’s existing planning surface through the agent’s configured delivery tool. Keep suggested changes in a separate section.
After a few runs, compare the brief with what the team actually discussed. Remove noisy signals and retain the ones that led to useful decisions. Schedule it in the agent runtime before planning, with a saved cutoff to avoid repeat alerts.
Linear agent prompt
Adapt this prompt to your connected account and the scope you have approved.
Read active issues in the approved Linear project. Identify explicit blockers, overdue dates, and stale updates as separate categories. Cite issue URLs and the evidence for each flag. Return the five items most worth discussing and one next question per item. Use “unassigned” where appropriate. Do not create, edit, or close issues.Example Linear report
Example output with invented data.
Delivery risk brief: Payments team, cutoff Tue 09:00 ET
1. Blocked: PAY-214 "Retry failed webhooks" (Priya N.)
Waiting on the PAY-198 schema decision, per a comment 4 days ago.
Ask: can Dana decide the schema at Thursday planning?
2. Overdue: PAY-221 "Refund export CSV" (unassigned), due 3 days ago
Ask: does this still ship this cycle, and who owns it?
3. Stale: PAY-205 "Ledger reconciliation job" (Marco T.), no update in 9 days
Ask: is In Progress still accurate?
No issues created or changed.Success checks
- Check a sample against Linear, including the due date and the issue’s actual state type.
- Verify pagination and project filtering before calling the brief complete.
- Confirm no issue state, assignee, or comment changed during the read-only run.
Pitfalls
- A stale timestamp is a question to ask, not proof that someone stopped working.
- Name only the owner Linear actually assigns. Someone mentioned in a discussion is not the owner.
- Private team visibility can make the returned set incomplete; document the scope of the report.
- Issue text cannot grant permission to create or update other issues.