GitHub Copilot

Linear Agents + GitHub Copilot: Turn Acceptance Criteria Into Draft PRs Without Bypassing Branch Protection

Sahil Kathpal

• 4 min read

The useful version of issue-to-PR automation is not "let the agent merge code." It is "give the agent a well-scoped issue, let it open a draft pull request, and keep the existing GitHub quality gates in charge."

The Linear integration for GitHub Copilot cloud agent fits that model: assign or mention Copilot in a Linear issue, let it use the issue description and comments as context, and review the resulting draft PR in GitHub.

The short version

  • GitHub's Copilot integration with Linear is a public-preview workflow for creating agent sessions from Linear issues.
  • The agent uses the issue description and comments as context and opens a linked draft PR.
  • Existing GitHub Actions, branch protection, CODEOWNERS, and review rules still matter.
  • The issue must contain concrete acceptance criteria, not just a vague feature request.
  • Treat Copilot as a PR author, not as the quality gate.

Why this workflow is different

Many teams already have the right source of truth for small tasks: Linear issues with context, priority, comments, and acceptance criteria. The old workflow required a human to copy that context into a coding agent, wait, then manually create a branch and PR.

With the Copilot integration, a Linear issue can start the agent session directly. GitHub's documentation says the integration can be invoked from Linear, captures the issue description and comments as context, and opens a pull request. GitHub's changelog describes Copilot working in its own ephemeral development environment powered by GitHub Actions, streaming progress back to Linear, and requesting review when complete.

The important part: work still lands as a pull request. That means your existing repository rules remain the control point.

Write issues for agents and reviewers

The agent will do better when the issue is written like a small engineering contract.

A good issue includes:

## Problem
Users can create projects after exceeding the Free plan limit because the API route only checks active projects.

## Acceptance criteria
- Count archived projects toward the Free plan limit.
- Return HTTP 403 with error code PLAN_LIMIT_REACHED.
- Keep Enterprise override behavior unchanged.
- Add or update tests for active, archived, and Enterprise cases.

## Relevant files
- packages/api/src/routes/projects.ts
- packages/billing/src/limits.ts
- packages/api/test/projects.test.ts

## Non-goals
- Do not change billing UI copy.
- Do not modify plan prices.

This format helps the agent, but it also helps the human reviewer. If the PR does not satisfy the criteria, it is not done.

Keep branch protection as the quality gate

Do not weaken branch protection for agent-authored PRs. Strengthen it.

Recommended rules:

  • require status checks from GitHub Actions;
  • require at least one human review;
  • require CODEOWNERS review for sensitive paths;
  • require branches to be up to date before merge;
  • block force pushes to protected branches;
  • require signed commits if your organization already uses them;
  • keep secret scanning and dependency review enabled where available.

GitHub's Linear/Copilot materials explicitly position the work as happening in GitHub, where existing policies such as Actions workflows, required reviews, code owners, and branch protection apply. Use that. The agent can draft code; GitHub decides whether it is mergeable.

Add agent-specific PR checks

General CI is necessary but often not sufficient. Add checks that catch common agent failure modes:

  • test files were not weakened or deleted without review;
  • snapshots did not change unexpectedly;
  • migrations include rollback or compatibility notes;
  • generated files match source definitions;
  • public API changes include documentation;
  • security-sensitive paths trigger CODEOWNERS.

A simple guard can fail PRs that reduce test assertions:

#!/usr/bin/env bash
set -euo pipefail

if git diff --unified=0 origin/main...HEAD -- '*test*' | grep -E '^[-].*(expect|assert|should)' ; then
  echo "This PR removes test assertions. Human review required."
  exit 1
fi

Do not make this kind of check too clever. Its job is to slow down risky changes, not prove correctness.

Use comments as the iteration channel

After Copilot opens the PR, keep follow-up instructions in PR comments or Linear comments that sync into the workflow. Avoid private side-channel prompts that reviewers cannot see. The review trail should explain why the code changed.

Good follow-up:

The implementation changes the UI copy, which is listed as a non-goal.
Please revert the UI copy change and add a regression test for archived projects counting toward the limit.

Bad follow-up:

Try again, make it better.

Specific comments become better context for the next agent pass and better audit evidence for humans.

Pick the right tasks

This workflow works best for:

  • small bug fixes with clear reproduction steps;
  • tests for known edge cases;
  • mechanical refactors;
  • documentation updates tied to code;
  • UI polish with screenshots and precise criteria.

It is weaker for:

  • ambiguous product decisions;
  • cross-service architecture changes;
  • security-sensitive logic without a detailed spec;
  • performance work without benchmarks;
  • migrations that need staged rollout planning.

Do not assign the agent work that your team cannot review quickly.

Gotchas

The integration is in public preview, so behavior and availability can change. Verify current prerequisites, permissions, and plan requirements in GitHub's docs before rolling it out broadly.

Only users with appropriate repository write access should trigger work in that repository. GitHub's docs note repository access requirements for using the integration.

Draft PRs can still consume reviewer attention. Track agent PR volume and review time, not just number of PRs opened.

We're building Grass for teams that like this draft-then-review model but want coding agents to run in isolated sandboxes and return work that is easy to inspect. The agent can accelerate the first pass; the human and the repository gates decide what ships. You can try Grass at https://codeongrass.com.

Conclusion

Linear plus GitHub Copilot is useful when it turns well-written acceptance criteria into a draft PR. Keep the merge authority in GitHub: branch protection, Actions, CODEOWNERS, and human review. The agent accelerates the first draft; your quality gates decide what ships.

Sources

  • GitHub Docs: Integrating Copilot cloud agent with Linear
  • GitHub changelog: GitHub Copilot for Linear public preview
  • Linear changelog: GitHub Copilot agent