Skip to content

Ticket to pull request with approval of every write

Takes one tracker ticket and decides whether it is ready, too big or too vague. Ready tickets get a fix and tests in a sandbox, a self review and a pull request. Too big tickets are split, vague ones get questions posted back. Every write to the tracker or the code host stops for a person to approve, edit or reject the exact arguments.

EngineeringWorks with LangGraph · Claude Code+1Community example
Build your promptSee requirements

What it does

  • Reads the ticket and sorts it as ready, too big or unclear
  • Changes code and runs tests in a sandbox, then reviews its own diff
  • Prepares a branch, the pushed files and a pull request
  • Prepares a ticket comment and status change
  • Keeps an audit log of every write, allowed or refused

Your approval boundaries

Creates drafts

These actions always wait for your yes:

  • Creating a branch, pushing files or opening a pull request
  • Commenting on, moving or creating tickets
  • Merging anything

You decide what happens next.

More about this workflow

This setup is for developers and small engineering teams who want fewer chores. It takes a repeat chore off your plate and hands back something you can check quickly.

First, it reads the ticket and sorts it as ready, too big or unclear. Next, it changes code and runs tests in a sandbox, then reviews its own diff. Then it prepares a branch, the pushed files and a pull request. After that, it prepares a ticket comment and status change. Finally, it keeps an audit log of every write, allowed or refused. It works with your issue tracker, git host and CI, each on its own login with limited access.

You get the prep work done and waiting for you. The agent stops and asks for your yes before creating a branch, pushing files or opening a pull request, commenting on, moving or creating tickets and merging anything, and says plainly if a step cannot be undone.

“Every Jira and GitHub write stops for a human first”
YanivBohbot YanivBohbot on GitHub · Nov 9, 2026
Before you startIssue tracker · Git host accessScoped permissionsLangGraph or Claude Code
Explore required tools and model recommendations

Tools and access

  • Linear

    Handles the issue tracker part of this job. Grant read plus create in one triage team.

    API required: Yes. Needs a personal API key or an OAuth app.

    Sign up: Linear

  • GitHub

    Handles the git host and ci part of this job. Grant a fine-grained token, read code and write comments.

    API required: Yes. Needs a GitHub App or a fine-grained personal access token scoped to the repos it needs.

    Sign up: Create a GitHub account

Official links only. Not sponsored, no affiliate links.

Model recommendations

Best pick

Claude Opus 5.5

Its maker points to it for long running coding work.

$4 per million input tokens, $20 per million output tokens.

Anthropic docs as of October 11, 2026

Cheaper backup

Claude Sonnet 5.5

Half the price per token and still strong for reviews and docs.

$2 per million input tokens, $10 per million output tokens.

Anthropic docs as of October 11, 2026

Our own picks. Not sponsored, no affiliate links.

Build your prompt

Add your details, then copy the prompt into your tool.

1Your details

Fill these in and the prompt updates as you type.

e.g. agent/

2Your prompt

4 of 4 still empty
Fill these in before you run it: [TICKET ID] [TARGET REPO] [BRANCH PREFIX: e.g. agent/] [TEST COMMAND] You are the Ticket to pull request with approval of every write agent. Takes one tracker ticket and decides whether it is ready, too big or too vague. Ready tickets get a fix and tests in a sandbox, a self review and a pull request. Too big tickets are split, vague ones get questions posted back. Every write to the tracker or the code host stops for a person to approve, edit or reject the exact arguments. Use only the details filled in above. If any [BRACKETED] item is still blank or unclear, stop and ask for it first. Do not guess. What you do on your own: - Reads the ticket and sorts it as ready, too big or unclear - Changes code and runs tests in a sandbox, then reviews its own diff - Prepares a branch, the pushed files and a pull request - Prepares a ticket comment and status change - Keeps an audit log of every write, allowed or refused What you must never do without a yes from a person: - Creating a branch, pushing files or opening a pull request - Commenting on, moving or creating tickets - Merging anything Rules: - Before any step on the list above, stop and ask. Say in plain words what you want to do, who it affects, and whether it can be undone. - If something cannot be undone, say so first, in one short line. - Write drafts, not final actions. A person sends, pays, posts, or deletes. - Keep a short log of every action you took and every source you read. - If you are unsure, ask instead of guessing.
View run instructionsPaste into: LangGraph, Claude Code, Cursor

Your answers stay in this browser only.

Run your workflow

Connect your tools with only the access this setup needs, then follow these steps.

Steps

Do these in order. Test on old data before it touches live work.

  1. 1Connect Linear with its own login, not yours. Grant read plus create in one triage team.
  2. 2Connect GitHub with its own login, not yours. Grant a fine-grained token, read code and write comments.
  3. 3Paste the prompt where your harness takes instructions. See the note under the Copy button.
  4. 4Do a dry run on old or test data first. Check every draft and every stop point by hand before you let it near live work.
  5. 5Read its log after the first real run. Only widen access once a week of runs looks clean.

Safeguards and trust score

The score describes this example setup’s access, approval boundaries, ability to undo changes, and scope.

Access24 / 30

Writes drafts and notes inside your tools, nothing leaves on its own.

Human approval30 / 30

Waits for a yes on: creating a branch, pushing files or opening a pull request, commenting on, moving or creating tickets, merging anything.

Undo and logs14 / 20

Proposes changes to live records, so the setup needs a change log and a way back.

Scope16 / 20

Runs on its own login across 3 tools. Fewer connections means a smaller blast radius.

How to raise it

  • Undo and logs: Stop it from editing live records. Have it write the change as a proposal you apply, and keep a log of every change with a way to roll it back +3
  • Scope: Cut it down from 3 connected tools to the 2 it needs most, each with its own limited login instead of your full account +2

Do all of these to reach 89, up from 84.

Want help getting there? Get an AI Trust Audit from Pixeldesigns

Reviewed by Trustcase (example setup). How scoring works

Embed badge

Show this trust score on your site or README. It links back here.

Trustcase trust score badge
Markdown
[![Trustcase trust score for Ticket to pull request with approval of every write](https://trustcase.dev/badge/ticket-to-pull-request-with-approval-of-every-write.svg)](https://trustcase.dev/use-cases/ticket-to-pull-request-with-approval-of-every-write)
HTML
<a href="https://trustcase.dev/use-cases/ticket-to-pull-request-with-approval-of-every-write"><img src="https://trustcase.dev/badge/ticket-to-pull-request-with-approval-of-every-write.svg" alt="Trustcase trust score for Ticket to pull request with approval of every write" height="20"></a>

More engineering workflows

  • Query and migration cost review before every push

    Before a branch is pushed, a reviewer looks at every changed database query and migration and asks what it does at production size. It measures plans on a local copy and writes a findings table into the pull request.

  • Code review thread replies checked against the branch

    Reads the open review threads on your pull request, checks each finding against the real code and drafts a short reply in your voice. You post, skip or rewrite each one, and only approved replies go up.

  • Weekly manager report from your commits

    Reads a week of your commits across your repos and writes a status report in the exact format your manager asked for. It asks about work git cannot show before you send it.

  • As built docs updated from change evidence

    Takes a diff, deploy result or test result and drafts matching updates to your architecture doc, config guide and change log. It never claims more than the evidence proves, and writes only the edits you approve.

Other workflows that use the same tools

  • Weekly delivery status report

    Operations. Pulls your team's work items once a week and builds a status report grouped by initiative. It puts at risk items first and flags anything with no update in two weeks.

  • User ticket sweep into scrubbed issues you approve

    Support. Sweeps new and reopened user tickets in your app, checks the facts in the codebase and drafts one thing per ticket: an issue, a question back to the sender or a close note. Drafts never quote the ticket or name the sender, and nothing is filed, asked or closed until you approve each one.

  • Bug report writer

    Support. Turns a messy customer complaint into a clean bug report.