Blog
From ticket to shipped PR: Run in Claude Code
Set up Run in Claude Code: your own routine and fire token, Tengu's GitHub App and a repo link. Then follow one quest from ticket to production.
8 min read
- claude code
- github
- dev loop
- guides
Without a loop around it, Claude Code on client work tends to run like this. Someone copies a ticket into a terminal, waits, opens a PR by hand, pastes the link back into the tracker, pings QA in Slack, and moves the status when they remember. The agent does its part. The loop around it is still manual.
Run in Claude Code closes that loop on the board. A quest goes to Claude Code, comes back as a pull request, gets a preview and a QA run with screenshots, and ships from the board with release notes already written. This guide covers the setup, then follows one quest from start to finish.
Run in Claude Code, QA with Claude, Merge and Ship are on every plan, Free included; the To review queue with Pass and Send back comes with Board.
What you need
- A Tengu workspace with at least one list. Any list in Tengu works, including imported ones.
- A GitHub organization (or a personal account) that holds the repos.
- A Claude account that can run Claude Code routines. This is the account that pays for the runs.
- Optional: the repo deploying on Vercel through its GitHub integration. That gives you preview links on the quest and the move to Live.
Step 1: Connect GitHub
An admin opens Admin > Settings > Claude Code and clicks Connect GitHub. That installs Tengu's GitHub App on your org. You pick which repos it can see.
- An org's owner installs it. A member can request it on GitHub, then click Finish a requested install once the owner approves.
- Add more orgs (or your own account) with Add a GitHub account.
- One GitHub account connects to one Tengu workspace.
The App asks for read and write on pull requests and contents (Merge and Ship need them), read on deployments, checks, commit statuses and metadata, and read on org members, so Tengu can confirm who owns the org. It listens for pull requests, reviews, PR comments, review threads, deployment statuses, check suites and commit statuses. If any of that is missing, or your org hasn't approved it yet, Settings and the ticket's Claude pane say what stops working.
Step 2: Connect your Claude routine
Tengu never holds your Claude login. You create a routine on your own account and give Tengu its trigger.
- On the Claude account that pays for runs, open
claude.ai/code/routinesand create a routine. Give it your repos and the model you want. - Add an API trigger and generate its token.
- Back in Admin > Settings > Claude Code, paste the trigger's URL and the token, and click Connect.
A few details worth knowing:
- Tengu accepts only Anthropic's own fire endpoint as the trigger URL, so the token is never sent anywhere else. It is stored in a vault and shown as "Token saved" from then on.
- Runs use that account's plan, model and GitHub identity. Tengu does not meter or charge for runs. Your Claude plan's own limits apply.
- For QA runs, give the routine's environment network access to Tengu and to your preview domain. Each QA run gets its own short-lived token, so there is nothing else to paste.
- If your Vercel previews sit behind Vercel Authentication, add
VERCEL_AUTOMATION_BYPASS_SECRETto the routine's environment. QA runs send it as a header. - Claude Code routines are a research preview from Anthropic, and the trigger API may change. When a run cannot start, the board says why: the token was refused, the routine is gone, or the account hit a rate limit.
Until both steps are done, nothing of Claude Code shows anywhere else in Tengu.
Step 3: Link a repo to a list
Open Admin > Projects & Lists > Lists, pick the list and open its Code card.
- Repo: one of the repos your GitHub connection reaches.
- PRs into: the base branch Claude opens PRs against (
devby default). - Live from: your production branch (
mainby default).
Click Link repo, then Check branches. A switch on the same card turns Run in Claude Code on or off for that list.
The card also shows What moves the quest, using the list's own statuses:
| GitHub event | Where the quest goes |
|---|---|
| PR opened (or out of draft) | The list's review status |
| Merged into the base branch | The list's shipping status |
| Deployed to production | The list's live status |
A list without one of those statuses leaves the quest where it is. Moves only go forward: a live quest stays live if its PR is reopened. One rule matters for the last row. Merge your base branch into production with a merge commit, not a squash, so Tengu can find each quest's commit in the production deploy.
What happens on the board
1. Run in Claude Code
The quest's assignee, the list's PMs, the project lead or an admin presses Run in Claude Code. Tengu fires your routine with the quest: title, description, subtasks, the latest comments and a link back. A toast links to the live session. A second click within two minutes opens that session instead of starting another.
2. A draft PR with the plan
Claude works on a branch named claude/tengu-<quest id>. As soon as it has a plan, it pushes and opens a draft PR into your base branch, with a link to the quest in its description, which ties the PR to the quest. The plan is a checklist in the PR's body, starting with the quest's subtasks. As Claude ticks an item, Tengu ticks the matching subtask. The quest shows "PR #214 opened as a draft" with the link.
3. The conversation lives on the PR, and in the quest's Claude pane
Claude posts its progress notes and answers as PR comments. Tengu keeps them in the quest's Claude pane, beside the comments, for your team only. They never go to a client. The pane also tracks the PR from plan to live: the draft, its checks, the preview, the review, the merge and production. Write to Claude in the box at the bottom of the pane. Your message goes to the PR as "Your name (via Tengu)", and Claude answers there. If Claude hasn't opened its PR yet, the message waits and goes up the moment it does. Comments from people with access to the repo count. Comments from anyone else are information only.
When the checks on Claude's PR fail, Tengu tells Claude on the PR so it can push a fix. The people who started the run and the quest's assignees hear about it in their inbox too.
4. Ready for review
When the checks pass, Claude marks the PR ready. You can also press Ready for review yourself. The quest moves to the list's review status and lands in the reviewers' To review queue.
5. Preview
When Vercel finishes a preview deploy for the PR, its link is posted on the quest.
6. QA with Claude
On a quest in review, the list's QA, its PMs or an admin can press QA with Claude. That run checks out the branch, runs the repo's own checks, then opens the preview in a headless browser. It walks through what the quest asks for, each subtask and the nearby flows it could break, and takes a screenshot of each scenario and every failure.
If the app has sign-ins, keep a QA account for each role on the project: open any of its quests, then ⋯ > QA accounts, and add the role, email and password. Your testers copy them from there too. A QA run is told only the role names and fetches the sign-ins with its own token while it runs, and Tengu hides every one of the project's passwords in what the run reports.
Findings land in the quest's Claude pane as a report card from "Claude QA": a suggested verdict, each scenario as passed or failed with steps to reproduce, and its screenshots. Whoever started the run, the list's QA and the quest's assignees hear about it in their inbox. A short summary goes on the PR too. The QA run never pushes, approves or moves the quest. Your QA person still decides: Pass, or Send back with a one-line reason, from the card or the review queue.
7. Merge
The list's Release people or an admin press Merge. Tengu squash-merges the PR into the base branch, never into production. It refuses when the PR is still a draft, when changes were requested, when the PR targets production, or when the code changed since you looked. The quest notes who merged it and moves to shipping.
8. Ship
The Ship tab lists each repo you ship, with how many merged quests are waiting. Ship opens a release PR from the base branch into production. Its description is already written:
- a customer changelog in plain words
- a QA checklist to run before production
- the Tengu quests it carries
- folded away: the technical summary, migrations, environment variable changes, security notes, deploy steps, a rollback plan and a risk level
You merge the release PR on GitHub with a merge commit. When the production deploy that contains it succeeds, every quest it carries moves to Live, with the production link on the quest.
What Claude may not do
The run's instructions say it plainly, and Tengu enforces the parts it controls:
- A build run works in the list's repo only, on its own branch. It never merges, pushes to other branches or changes repository settings.
- A QA run reports. It never commits, pushes, approves or merges, and its token only posts that run's screenshots and findings.
- Tengu never merges into production. A release PR goes to production when a person merges it on GitHub.
- If a quest is unclear, Claude says why on the PR instead of guessing.
First draft, QA'd, shipped by you
Agent PRs vary by repo. A well-tested repo with clear tickets gets good first drafts. A repo with no tests and a two-line ticket gets something to argue with. We describe the loop as "first draft, QA'd, shipped by you" for that reason. Claude writes the first draft. Claude QA and your QA person check it. A person on your team merges and ships it.
What the loop changes is the work around the draft. Status moves by itself. The PR, the preview, the QA evidence and the release notes all sit on the quest. The person who wrote the ticket can follow it without asking anyone.

