linear-execute

name	linear-execute
description	Implement the solution for a Linear ticket and open a pull request. Full coding workflow — plan, implement, test, PR.
scopes	["linear","slack"]

Linear Execute

Implement the solution for a Linear ticket and open a pull request. This is the full coding workflow.

Use the linear plugin tools (linear_issue_view, linear_issue_update, linear_issue_create, linear_comment_add, etc.) for all API operations.

Workflow

1. Understand the Ticket

Fetch the ticket with linear_issue (action: view). Read everything:

• Title and description (may contain implementation prompts from #prep / linear-prep)
• Comments (may contain clarifications or decisions)
• Sub-issues (you may be working on one piece of a larger ticket)
• Labels, priority, due date

Use existing context — don't redo prior work. If the description contains a triage report, research report, implementation plan, entry points, or test cases from a prior agent run, treat them as authoritative input. Follow the implementation prompt if one exists. Only re-investigate if a comment explicitly asks you to.

2. Prep Gate

Before writing any code, judge whether the ticket has enough context to start implementation confidently. A well-prepped ticket — whether by linear-prep, a human, or prior agent work — gives you a clear understanding of what to change, where to change it, and what "done" looks like.

Use your judgment. There's no rigid checklist — a detailed description written by a human counts just as much as formal linear-prep output. Ask yourself: "Can I start coding right now without guessing?"

• Yes → proceed to Step 3.
• No, but the task is trivial (obvious single-file fix, typo, config tweak) → proceed to Step 3.
• No → run the linear-prep skill first. Wait for it to complete and re-read the ticket before proceeding.

3. Check In-Flight Work

Before coding, scan for concurrent work that might overlap with your changes.

1. Query Linear for in-progress and in-review tickets on the same team:
   • linear_issue list --team <TEAM> --state "In Progress"
   • linear_issue list --team <TEAM> --state "In Review"
2. Query GitHub for open PRs on the target repo:
   • gh pr list --state open --json number,title,headRefName,changedFiles,additions,deletions
3. Identify overlaps — tickets or PRs that touch the same files, same feature area, or are explicitly related (linked issues, dependency chains).
4. Decide how to proceed:
   • No overlap → proceed normally (branch off main).
   • Prerequisite PR exists (your ticket depends on changes in an open PR) → branch off that PR's branch instead of main.
   • Parallel but overlapping PR (touches the same files but isn't a dependency) → read its diff to understand what's changing and avoid conflicts.
   • Note any overlaps in your implementation plan so reviewers have context.

4. Implement

1. Start from latest main (or a prerequisite PR's branch if Step 3 identified one) — fetch and reset.
2. Create a feature branch — name it after the issue: {identifier}-short-description (e.g. eng-42-fix-auth-flow).
3. Work in a git worktree — isolate your changes from other concurrent work.
4. Follow existing codebase patterns and conventions.
5. Write clear, descriptive commit messages.

5. Verify

• Run the build — fix any compilation/type errors.
• Run tests — fix any failures your changes caused.
• If you added new functionality, add tests for it.
• Check that your changes don't break existing behavior.

6. Open a Pull Request

Push your branch and open a PR with:

• Title: Short, descriptive (include the issue identifier)
• Description: What changed and why, how to test it
• Link to the Linear issue

7. Link the PR to Linear

After opening the PR, always use linear_issue (action: connect_pr) to link the PR URL to the session:

• sessionId: the Linear Agent Session ID from the ## Session section at the top of your prompt
• url: the full GitHub PR URL (e.g. https://github.com/org/repo/pull/123)

This makes the PR visible directly in the Linear ticket UI.

8. Update the Ticket

After opening and linking the PR:

• Move the ticket state to "In Review" (use linear_issue action: update with state: "In Review")
• The PR should auto-link to the ticket if the branch name contains the identifier

Notes

• Your work is not done until there's a PR. Don't stop at "I made the changes."
• If you hit a blocker (missing access, unclear requirements, architectural decision needed), update the ticket with what you found and what you need.
• Clean up your git worktree when done.
• Follow the project's existing patterns — don't introduce new conventions without reason.