Linear Pipeline

The Linear Pipeline is an autonomous workflow that takes a Linear ticket and delivers a reviewed GitHub pull request -- with minimal human intervention. It uses a team of specialized AI agents to handle everything from research and planning to code generation, independent review, CI monitoring, and review iteration.

How It Works

The pipeline runs a multi-step orchestration with specialized agents working together:

Step 1: Triage

The system receives a Linear ticket and classifies it:

• Bug -- Includes error reproduction context
• Feature -- Includes acceptance criteria
• Chore -- Includes scope boundaries
• Refactor -- Includes before/after expectations

A type-specific prompt is built for the agents.

Step 2: Preflight Check

Before starting work, the system verifies:

• The workspace directory is clean (no uncommitted changes)
• The target branch doesn't already exist
• Required tools (git, GitHub CLI) are available

Step 3: Research

The system automatically researches best practices for your project:

• Detects your tech stack (supports 20+ frameworks including Next.js, React, Hono, Tauri, and more)
• Searches for relevant documentation and best practices
• Gathers up to 8 actionable recommendations and 5 documentation links
• Research findings are included in the agent's context for better-informed implementation

Step 4: Create Branch

An isolated workspace is created for the changes:

• A git worktree is created from the target branch, keeping your main workspace untouched
• Branch name is generated from the issue slug (e.g., fix/login-timeout-error)
• Project conventions (from CLAUDE.md) and test commands are pre-loaded for the agents

Step 5: Planning

A Planner agent analyzes the ticket and codebase with extended thinking to create a detailed execution plan. The plan includes:

• What files need to change and why
• Implementation approach and order of operations
• Potential risks and unknowns

Step 6: Confidence Gate

Before proceeding with implementation, the system evaluates the plan:

• A confidence score (1--10) is calculated based on factors like test coverage, documentation quality, and plan complexity
• The plan, risks, and unknowns are posted as a comment on the Linear ticket
• If the score is 8 or above, implementation proceeds automatically
• If the score is below 8, the pipeline pauses and waits for your approval on the Linear ticket

To approve, comment with keywords like "approved", "lgtm", or "go ahead". To reject, comment "reject", "cancel", or "stop". The pipeline checks for your response every 2 minutes, for up to 4 hours.

Step 7: Implementation

A Developer agent implements the solution based on the approved plan, making file changes and using available tools within the isolated workspace.

Step 8: Verification

The code is verified with automated checks:

• Lint -- Code style validation
• Type-check -- TypeScript compilation
• Project-specific tests -- Automatically detected from your project configuration
• Retry loop -- Up to 3 automatic fix attempts if checks fail

Step 9: Independent Evaluation

An Evaluator agent performs an independent code review in a completely separate session. This agent:

• Has no access to the developer's reasoning or conversation history
• Reviews the code changes objectively against the original ticket requirements
• Provides feedback that may trigger additional improvements
• Runs in a process-isolated environment for true independence

Step 10: Self-Review

The agent performs a diff analysis of its own changes before creating a PR, checking for:

• Completeness against the original ticket
• Code quality issues
• Unintended changes

Step 11: Create PR

A GitHub pull request is created with:

• Descriptive title and body linking to the Linear ticket
• Targeted git staging (filters out sensitive files like .env, .key, .pem)
• Self-review and evaluation findings included in the PR description

Step 12: CI Monitoring

After the PR is created, the pipeline monitors your CI checks:

• Polls GitHub Actions every 60 seconds for up to 15 minutes
• If all checks pass, the pipeline moves to the review phase
• If checks fail, the agent automatically analyzes failure logs and pushes fixes

Step 13: PR Review Loop

The pipeline monitors for human review feedback:

• Polls every 5 minutes for new review comments
• 24-hour window for the review cycle
• Up to 10 fix iterations responding to reviewer feedback
• Automatically pushes fixes and requests re-review

Step 14: Slack Notification

A Slack message is sent to your configured channel:

• Links to the PR for human review
• Summary of what was done
• Request for final approval

Step 15: Update Linear

The Linear ticket is updated:

• Status changed to "Done"
• PR link posted as a comment
• Status comments posted throughout the process in your preferred language

Multi-Repository Support

If a ticket spans multiple code repositories, the pipeline can automatically split it into separate sub-tickets:

• Repositories are detected from ticket attachments, description, comments, or your configured mappings
• Up to 5 sub-issues are created on Linear, one per repository
• Each sub-issue runs through its own pipeline in parallel
• Progress is tracked across all sub-issues

Webhook Processing

The pipeline can receive Linear tickets via webhooks with multi-layer security:

Trigger Modes

The pipeline can be triggered by ticket assignment, labels, or both:

Trigger Conditions

A ticket is processed when either condition is met:

• Assignee match -- The ticket is assigned to the agent's configured user
• Label match -- The ticket has a label matching one of your configured trigger labels (e.g., "agent-ready")

This lets you trigger the pipeline by simply adding a label to any ticket, without changing the assignee.

Configuration

Configure the pipeline in Settings > Connectors:

Linear Settings

• API Key -- For reading tickets and updating status
• Webhook Secret -- For verifying incoming webhooks
• Team ID -- Which Linear team to monitor
• Assignee Filter -- Only process tickets assigned to specific users
• Trigger Labels -- Labels that trigger the pipeline (e.g., "agent-ready") -- works alongside or instead of assignee filtering
• Poll Interval -- How often to check for new tickets (polling mode)

GitHub Settings

• Personal Access Token -- For creating branches and PRs

Slack Settings

• Webhook URL -- For sending notifications
• Channel -- Where to post updates

Pipeline Settings

• Workspace Directory -- Where code changes happen
• Default Branch -- Base branch for new branches (e.g., main)
• Auto-Process -- Whether to start automatically on new tickets
• Max Concurrent Pipelines -- How many tickets can be processed at the same time (default: 3)

Budget Limits

• Max per Ticket -- Maximum cost for a single ticket (default: $10)
• Max per Day -- Maximum total daily cost across all tickets (default: $100)

The pipeline checks budget limits before starting a new ticket. If either limit is reached, the ticket is rejected until the budget resets (daily) or you adjust the limits.

Required Approval Categories

You can configure categories (e.g., "security", "database", "infra") that always require human approval before implementation, regardless of the confidence score. If a ticket's labels, title, or description match any category, the pipeline will pause and wait for your approval on the Linear ticket.

Agent Capabilities

Control what the pipeline is allowed to do. By default, the agent can create branches and PRs but cannot merge or deploy:

All credentials are stored encrypted at rest using industry-standard encryption.

Timeouts and Limits

Status Updates

Throughout the pipeline, status updates are posted to the Linear ticket as comments. These updates are available in all six supported languages (English, Chinese, Spanish, French, Hindi, and Portuguese) and include:

• Phase transitions (e.g., "Starting implementation", "Creating pull request")
• The confidence score and plan summary
• PR links and CI results
• Error details if something goes wrong

Error Handling

The pipeline handles errors at each phase:

• Phase-level retries -- Each step can retry on transient failures
• State persistence -- Pipeline state saved to disk for recovery after restarts
• Graceful degradation -- If Slack fails, the PR is still created
• CI auto-fix -- Failed CI checks trigger automatic fix attempts
• Logging -- Comprehensive logging for debugging

Learn More

• Agent System -- How the agent executes tasks
• Workspace Security -- How the workspace is protected
• Desktop Application -- Overview and setup