linear

Linear is the task layer across work, personal, and projects. The model owns the judgment: which labeled task to pick up, what the comment should say, when the task counts as done. Reads and writes go through the Linear MCP, always, OAuth-authorized and tool-typed, with no API key in any environment and no hand-built GraphQL. The label is the control surface, so the agent only touches tasks the user marked for it, and deletion is never performed through the MCP, whatever tools the server exposes.

Exact tool names vary by server, so the agent discovers them at run time and never hardcodes a name. The operation map, the deterministic selection rule, the state-name resolution, and the vault-mirror format live in the Linear MCP reference.

Steps

1. Confirm the MCP is connected. Search the session's tools for the Linear MCP (a ToolSearch for linear, covering issue list/get/update and comment operations). When no Linear MCP is connected or the server still needs OAuth, stop and hand the user the fix (authorize it via /mcp in an interactive session, or the claude.ai connector settings), then resume on the next run. This step is done once the Linear tools are callable, or the run has stopped with that instruction.

2. Resolve the pickup label. Name the label that marks a task for the agent; the default lives in skill.linear.label, read through skill-config. This step is done once the label is named.

3. Select the next task deterministically. List the issues carrying the label in unstarted or started states, then apply the fixed rule from the reference (Urgent before High before Medium before Low, priority-less last, ties to the oldest created), so the same board yields the same choice every run. This step is done once one issue is named, or the empty result is reported plainly rather than filled by invention.

4. Claim it. Read the team's exact state names through the MCP (teams rename their workflow states), then update the issue to its started state (commonly "In Progress"). This step is done once the MCP confirms the new state.

5. Do the work, then prove it. Carry out the task, the judgment the model owns, and route a code change through appsec before it ships. This step is done once the task's acceptance is met and verified against real output per verification-before-completion.

6. Comment the outcome, then close. Record what changed and why as an issue comment through the MCP, then move the issue to the team's done state, or its review state where the team gates on review. This step is done once the comment exists on the issue and the MCP confirms the final state.

7. Visualize and feed the brain. For a dashboard, list the open issues and render counts by state and priority in the fixed shape the reference names. Mirror the worked issue into the vault with the second brain's vault.sh capture task "<ID>: <title>" status=<state> url=<issue-url>, so the Obsidian graph carries the commitment. This step is done once the capture prints the note path, or the user declined the mirror.