Use Linear with Ottermind: From Issue Lists to Clear Next Steps

Bring your Linear issues into a conversation about what needs to happen next. With the Linear skill configured in Ottermind, your agent can read accessible issues and comments, help prepare a review, and draft follow-ups using the context already recorded by your team. After approval, supported writes can put that work back into Linear.

This is useful when the tracker has the details but you still need to connect them. Which issue needs a decision? Are two customer reports describing the same failure? What information would make the next ticket ready for an engineer?

The walkthrough below uses a fictional release with an invitation-link problem. Issue IDs, source facts, and sample outputs are illustrative; they do not represent a connected-workspace test.

Connect the team you want to work with

Use the Linear API skill published by byungkyu. This third-party skill connects through Maton and requires Maton authentication plus an active Linear OAuth connection. The connection determines which workspace and resources the agent can access.

Enable the skill and bind it to the agent handling your task, following the Ottermind Skills guide. If you have multiple Linear connections, specify the intended workspace. Start by asking the agent to read a known issue and confirm its ID and title.

The skill documents issue search, queries, creation, updates, and comments. Writes require explicit approval, and some operations may need additional scopes. The skill's setup instructions describe those requirements.

Prepare a review around the decisions the team needs to make

Suppose your team is preparing a release, and three issues mention invitation links. One is already assigned, another has a recent comment asking for clarification, and the third contains a customer report that has not been reproduced.

Opening the board tells you where the issues are. Preparing the review means understanding which facts need to be discussed together. Ask the agent to read descriptions and relevant comments, then organize a short agenda with links back to the evidence.

Prepare a release-review agenda for [project] in the [team] Linear workspace.
Read the active issues and the comments needed to understand their current state.

For each discussion item, include issue ID, title, status, assignee,
the recorded problem or question, and a link to the supporting issue.
Group the agenda into decisions needed, missing information, and confirmed blockers.
Use recorded facts. Do not infer that an issue is blocked just because it is old.
State what you reviewed and any records you could not retrieve. Do not edit issues.

An effective agenda has enough detail that a teammate knows why each item is on it. In the fictional example, the difference might be:

The agent's job in this request is to assemble evidence and frame the questions. A missing reproduction step is a concrete gap. Declaring the whole release at risk would require more information.

Linear supports filtering issues by their properties and relationships. A specific project, team, or issue set keeps the review focused and makes its coverage easier to assess.

Reading the issue set: Linear filtering reference · Linear GraphQL guide

Once the agenda is ready, ask for a tighter version: “Give me a five-minute opening for the review. Lead with the invitation decision and put information requests afterward.” You still have the fuller evidence table when someone needs to inspect a detail.

Compare similar reports without erasing their differences

The phrase “invitation link is broken” can describe several failures. One user may have opened an expired link. Another may be signed in to the wrong account. A third may see an error after accepting a valid invitation.

Before creating a new issue, use search to find candidate matches. Then ask for a comparison of the descriptions, conditions, and expected behavior. This turns a broad keyword match into a reviewable hypothesis about which reports belong together.

Search issues in [team] for invitation links expiring or failing to open.
Read the relevant issue descriptions and comments.

Compare the reported behavior, reproduction conditions, affected context,
and expected outcome. Include the issue ID and source link for every row.
Suggest pairs worth reviewing as possible duplicates, with a reason for each.
Keep uncertain matches separate. Do not close, merge, or modify issues.

Here is a small example of the comparison to ask for. These IDs and reports are fictional:

DEMO-41 and DEMO-63 are candidates for the same discussion. That does not establish that they share a root cause. DEMO-58 mentions invitations too, but its reproduction condition points to a different question.

A useful follow-up is: “What evidence would tell us whether DEMO-41 and DEMO-63 should be handled in one issue?” The answer might call for matching screenshots, exact error messages, or a comparison of reproduction steps. It should emerge from the reports rather than inventing a diagnosis.

That distinction matters during triage. You want to reduce duplicate investigation while preserving information an engineer may need later.

Turn the agreed behavior into a ticket someone can implement

Now suppose the review reaches a decision: an expired invitation should explain the problem and direct the user to ask a workspace administrator for a new invite. The decision does not include changing invitation validity rules.

Those notes are enough to draft a bounded issue. Continue in the same conversation so the related reports and the reason for the decision are available.

Draft a Linear issue from these approved product decisions: [notes].
Use [team] and [project]. Link the related reports we just reviewed.

Include a concise title, observed behavior, expected behavior,
in-scope work, exclusions explicitly stated in the notes, and acceptance criteria.
Do not invent an implementation approach. Leave owner and priority unset
unless the notes specify them. Show the complete draft before creating it.
After I approve creation, return the issue ID and URL.

For the fictional decision, the draft could contain:

• Title: Explain the next step when an invitation has expired.
• Observed behavior: The reported expired-link flow ends without a useful recovery action.
• Expected behavior: Explain that the invitation expired and direct the user to request a new invitation from an administrator.
• Out of scope: Changes to invitation validity rules.
• Acceptance check: Opening an expired invitation displays the agreed explanation and recovery instruction.

This is a writing example, not a claim that Ottermind created or tested an issue. Its purpose is to show how a decision becomes actionable without silently adding requirements.

Review the expected behavior and acceptance criteria together. If the notes do not say whether the recovery instruction should be a button or plain text, flag that as unresolved. A precise question now is more useful than an invented design detail in the ticket.

The selected skill supports creating issues and adding comments. Once you approve the exact write, ask for the resulting issue link. If the decision belongs on an existing issue, prepare a focused comment there instead of creating another place to follow the same work.

Keep the next step connected to the original report

A good session can leave you with three related artifacts: a review agenda, an issue comparison, and a draft that reflects the team's decision. Each should point back to the records that explain why the work exists.

Start with the Linear skill and one issue group that needs attention. The Skills introduction explains how the capability is made available to your agent. For the wider operating approach, the AI project management guide covers review and handoff, while the agent workspace guide shows how context supports work across steps.