GitHub issues to pull requests

In this guide, adding the label jimothy to a GitHub issue starts a run of the Bug fix (fast lane) pipeline: the Claude API triages the bug, Claude Code writes a failing regression test and fixes it, your tests run (looping back to the fix on failure), and a pull request opens automatically with Closes #<number> so merging it closes the issue. Jimothy labels the issue jimothy:done or jimothy:failed.

Prerequisites

• Claude Code installed and signed in; an Anthropic API key for the Claude API triage step (or switch that step to Claude Code).
• A local clone of the repository, and gh signed in with push access (see Linear guide → step 2).

1. Create a GitHub token and sign in

1. Open https://github.com/settings/personal-access-tokens/new.
2. Repository access → Only select repositories → your repository.
3. Repository permissions → Issues: Read and write.
4. Generate and copy the token.
5. In Jimothy: Accounts → GitHub, paste it into Token, Sign in.

This token is used only to read issues and write comments and labels. Opening the PR uses gh’s own credentials.

2. Set up the pipeline

1. Pipelines → New pipeline → Bug fix (fast lane).

2. Pipeline settings → Workspace: Git worktree, Local repository = your clone, Base branch main. The branch template is fix/{{issue.key | slug}}, so issue web-app#42 gets branch fix/web-app-42.

3. Variables: set testCommand.

4. The Triage step uses Claude API with claude-opus-5. Add your key on Harnesses → Claude API → API key (or set ANTHROPIC_API_KEY), or switch the step’s harness to Claude Code.

5. Select Open pull request and change the command so the PR closes the issue:

   git push -u origin HEAD && gh pr create --base {{run.baseBranch}} --head {{run.branch}} --title "$FACTORY_ISSUE_TITLE" --body "Closes #{{issue.raw.number | raw}}. Automated by Jimothy run #$FACTORY_RUN_NUMBER."

   | raw inserts the issue number without shell quoting, which is safe because it’s always a number. Without it the body would contain literal quote characters (Closes #'42').

6. Save.

No human gate

The Bug fix template opens PRs without an approval step. That’s fine for PRs (they still need review to merge), but add an Approval step before Open pull request if you want to check each change first.

3. Add the GitHub trigger

1. Triggers → Add trigger → GitHub Issues.

2. Runs pipeline: Bug fix (fast lane). GitHub account: from step 1.

3. Owner acme, Repository web-app.

4. Labels (all of): jimothy (add bug too if both should be required).

5. Assignee: empty (or a login to only pick up issues assigned to someone).

6. Write back to the issue:

   • Run starts: Comment on, transition jimothy:running
   • Succeeds: Comment on, transition jimothy:done
   • Fails: Comment on, transition jimothy:failed

   On GitHub the transition box adds a label (or closed / open changes the state).

7. Preview matching issues, then Save trigger.

4. Run it

Add the jimothy label to an open issue. On the next poll (or Check now), a run starts and the issue gets a comment and the jimothy:running label. When the run finishes, the issue gets the run summary with the PR link, and jimothy:done.

Labels are only added, never removed, so a finished issue carries both jimothy:running and jimothy:done. Dedup keeps it from running again even though it still has jimothy.

Optional: instant starts

Add a repository webhook so runs start seconds after labelling:

1. Enable Settings → Webhook server and start a tunnel, e.g. ngrok http 7717.
2. In the trigger editor, set a Webhook secret and copy the URL from Instant webhook; replace http://127.0.0.1:7717 with your tunnel URL.
3. Repository Settings → Webhooks → Add webhook: that URL, content type application/json, the same secret, event Issues.

For webhook events, labels match if any listed label is present, so keep a single hand-off label. See GitHub → Webhooks.

Variations

• Features instead of bugs: use the Feature: Plan → Build → Review → PR template with a feature label, and a second trigger for bugs.
• Cross-repo: one GitHub account can feed triggers on many repositories; each trigger points at one repository and one pipeline (whose workspace must be a clone of that repository).
• Issue forms: GitHub issue forms produce Markdown sections in the body. They arrive intact in {{issue.description}}.