How to use a Righthand with Linear

Use Linear for a focused triage queue

Use Righthand with Linear to prepare a triage brief for a named team and project. The useful result is an issue queue with explicit owner questions and source links. It should help the engineering lead decide what needs clarification without treating a label or comment as permission to change a release plan.

Linear's GraphQL guide describes querying issues and related information. Keep an issue's stable identity alongside its human-readable identifier. A short identifier helps the reviewer, while the underlying identity helps reconcile renamed or moved issues.

Give triage its own scope

Provide the team, project, included states, and the exact meaning of priority and blocking relationships in your process. For an illustrative reliability review, select open issues in one project and the dependencies explicitly linked to them. Avoid expanding into every team merely because a search can return more results.

Check the exposed Linear reads in integrations. If the selected connection cannot retrieve the needed fields, provide an approved issue export or authorize a browser inspection. Do not assume that provider mutation examples imply native issue-writing tools.

A worked brief

At 9 AM America/Los_Angeles on Tuesday, review open issues in the named reliability project for the selected team. Produce a private triage brief with issue ID and identifier, title, current state, assignee, explicit dependency links, and the latest relevant supplied evidence. Group missing reproduction details, missing owners, and unresolved dependency questions separately. Do not change priority, status, or assignees. Send to me for engineering-lead review and reconcile pagination, archive exclusions, and unique issue count.

This example is illustrative. A bug report's symptom is evidence of a reported problem, not proof of its root cause or severity. Keep any proposed classification visibly separate from the recorded fields.

Define an actionable result

An example entry might say: “Issue ENG-example; assignee absent; report includes an error message but no reproduction steps; lead must assign an investigator and request the missing context.” The assistant can propose a clear question without inventing a technical diagnosis.

If a dependency is inaccessible, retain its link and mark it unavailable. An issue with a completed dependency can still need verification of the resulting behavior. Do not turn the linked issue's status into a claim that a customer-visible defect is fixed.

Reconcile repeated triage

Match issue identities on later runs. Show new evidence, owner changes, and resolved questions within the existing entry, rather than creating another copy of the same escalation. A moved issue can retain its identity while its team context changes; ask the owner to confirm whether it remains in scope.

If approved writes are supported, apply only the reviewed field changes and reread each issue afterward. An access error or partial page should produce an incomplete brief with the missing coverage stated.

Use Righthand's responsibility guide to define a recurring triage checkpoint. Check plans for the scope of ongoing engineering coordination.