Claude builds something that doesn't match the ticket

You skipped step 1's restatement. Always make it summarize the ticket back before coding — catching a misread spec in a sentence is free; catching it in a diff is not.

The PR diff is huge and touches unrelated files

Constrain it: 'only change files needed for this ticket — if you think something else needs changing, list it as a follow-up, don't do it.' Scope creep is the default failure mode.

Vercel MCP can't find the deployment

The Vercel MCP URL is project-scoped. Confirm the team-slug and project-slug in the install command match the project this repo deploys to — see the Vercel MCP page.

GitHub MCP opens the PR against the wrong base branch

State it explicitly: 'base branch is main' (or your default). MCP defaults vary by repo and won't always guess your trunk.

How long does it take to ship a feature: linear ticket to vercel deploy with claude?

About 30 minutes (10 to set up the first time, 20 per feature after). Difficulty: advanced.

What do I need for this?

Linear, GitHub. Turn them on in Claude or ChatGPT, then run the prompts — no code.

Do I need to know how to code?

No. Turn the connectors on in your AI's settings and paste the prompts in plain words.

Recipe

Ship a feature: Linear ticket to Vercel deploy with Claude

Take a Linear ticket from 'todo' to a live preview URL in one conversation — read the spec, write the code, open the PR, deploy.

30 minutes (10 to set up the first time, 20 per feature after) advanced 3 connectors for Indie hackers and full-stack devs who'd rather ship through chat than memorize CLI flags

What you'll need

Linear Reads the ticket — spec, acceptance criteria, comments — so Claude builds the right thing.

Required

GitHub Creates the branch, commits the change, and opens the pull request.

Required

Vercel Triggers and reports the preview deployment so you get a live URL to check.

Optional

Do this, in order

1
Read the ticket properly

Read Linear ticket [TEAM-123]. Summarize back to me: what's being asked, the acceptance criteria, and anything ambiguous you'd want clarified before writing code. Don't write code yet.

You'll get: A plain restatement of the ticket plus a short list of ambiguities. If there are none, that's a green light. If there are, you answer them now, not after the code is wrong.
2
Plan the change

Given that ticket, list the files you'd change and the approach in 5 bullets. Flag anything that touches auth, data, or a public API so I can decide if it needs more care.

You'll get: A short change plan you approve or correct before any code exists. This is the cheapest place to catch a wrong approach.
3
Build it on a branch

Create a branch named after the ticket, make the change, and open a draft PR against main. PR description should reference the Linear ticket and list what you changed and how to test it.

You'll get: A draft PR URL. The branch exists on GitHub, the diff is scoped to the plan from step 2, and the description links the ticket.
4
Deploy a preview and report back

Check the Vercel preview deployment for this branch. When it's ready, give me the preview URL and confirm the build passed. If it failed, show me the build error and the likely fix.

You'll get: A live preview URL and a green build, or a specific build error with a proposed fix. You open the URL and verify the ticket's acceptance criteria yourself.

You're done when

A Linear ticket goes from 'todo' to a live, reviewable preview URL with a linked draft PR — in one conversation, without you opening four tools. You stay the reviewer and the merge decision; the wiring between tools stops being your job.

Why this workflow exists

A small feature is rarely hard. What’s expensive is the relay: read the ticket in Linear, switch to the editor, write the change, switch to GitHub to branch and PR, switch to Vercel to check the deploy, switch back to Linear to update status. Six tool switches for a two-hour change, and every switch is a place to lose the thread.

This workflow keeps the whole relay in one conversation. Claude reads the ticket where it lives, writes the change, opens the PR, and reports the deploy — and you stay exactly where the judgment matters: is this the right thing, is this diff scoped, does the preview actually satisfy the ticket. The tool-switching tax disappears; the review responsibility does not.

The first run takes ~30 minutes for setup. After that a small feature is ~20 minutes of conversation plus your review.

Install in 10 minutes

You need Linear MCP and GitHub MCP. Vercel MCP is optional but it’s what closes the loop with a live URL instead of “it should deploy.”

1. Install Linear MCP

claude mcp add --transport sse linear https://mcp.linear.app/sse

Auth is OAuth in the browser on first use. The maintained endpoint is on the Linear MCP page. Verify with /mcp — linear should be connected.

2. Install GitHub MCP

claude mcp add github -- npx -y @modelcontextprotocol/server-github

Set GITHUB_PERSONAL_ACCESS_TOKEN with repo and pull request write scope. Scopes are on the GitHub MCP page.

3. (Optional) Install Vercel MCP

claude mcp add --transport http vercel https://mcp.vercel.com/<team-slug>/<project-slug>

Replace <team-slug> and <project-slug> with the project this repo deploys to — it’s project-scoped. Details on the Vercel MCP page.

The first run

Pick a genuinely small ticket for the first run — a copy change, a config flag — not your hardest feature. Run prompt 1 and read the restatement carefully; this is the step that prevents building the wrong thing. Approve the plan in prompt 2.

Let it build and open the draft PR in prompt 3. The PR is a draft on purpose — nothing merges without you. Check the preview in prompt 4, open the URL, and verify the acceptance criteria yourself. Then you merge, by hand, like always.

What success looks like

You picked a ticket. You had one conversation. You ended with a draft PR linked to the ticket and a live preview URL where the feature actually works. You never opened the editor, GitHub’s PR form, or the Vercel dashboard. You did do the two things only you should do: confirm the approach and verify the result.

Going further

Auto-update the ticket. Add: “when the PR is open and the preview is green, move the Linear ticket to In Review and comment the preview URL.”
Guardrail prompt. Keep a standing rule: “never touch migrations, auth, or billing code without stopping to ask me first.” Cheap insurance on the high-risk paths.
Pair with review. Once the PR is up, run the PR auto-review sweep so even your own change gets a second pass before merge.

Linear MCP — reads the ticket
GitHub MCP — branches, commits, opens the PR
Vercel MCP — the preview deployment

If something breaks

Claude builds something that doesn't match the ticket: Fix: You skipped step 1's restatement. Always make it summarize the ticket back before coding — catching a misread spec in a sentence is free; catching it in a diff is not.
The PR diff is huge and touches unrelated files: Fix: Constrain it: 'only change files needed for this ticket — if you think something else needs changing, list it as a follow-up, don't do it.' Scope creep is the default failure mode.
Vercel MCP can't find the deployment: Fix: The Vercel MCP URL is project-scoped. Confirm the team-slug and project-slug in the install command match the project this repo deploys to — see the Vercel MCP page.
GitHub MCP opens the PR against the wrong base branch: Fix: State it explicitly: 'base branch is main' (or your default). MCP defaults vary by repo and won't always guess your trunk.

Linear GitHub Vercel