How to take a GitHub issue to a merged PR with Claude Code

FlowConversational

❯_

Do this with Claude CodeCopy a prompt that links the cckit docs so Claude learns the CLI, then follows these steps.

Copy as Markdown

Before you start

Install cckitQuickstart: your first lifecycle

This tutorial

Beginner6 min readNeedscckit installed & initializedan open issue

What you’ll do: take a single issue from the board all the way to a merged pull request — on its own isolated branch and worktree, with the change kept focused on that one issue. Each step is one cckit verb, correct by construction: the agent runs them in order and never improvises branch or PR plumbing.

Steps

1. Pick the next ready issue. Ask Claude to read the board and take the top unblocked issue all the way to merged.

   Prompt to paste

   Check the board and pick the next issue that's ready. Take it all the way to a merged PR —
   work it on its own isolated branch, keep the change focused, and open the pull request.
   When it's merged, clean up and tell me the PR link.

2. cckit runs the lifecycle. Each verb moves the board and the git state together:

   cckit next                       # find the next unblocked issue + its start command
   cckit start <issue>              # worktree + branch, board → In Progress
   # …agent makes the focused change in the new worktree…
   cckit pr <issue> "<summary>"     # commit, push, open the PR, board → In Review
   cckit close <issue> "<summary>"  # close the issue, board → Done
   cckit gc --prune --yes           # remove the merged branch + worktree

3. Confirm and clean up. When the PR merges, gc prunes the branch and worktree so nothing is left behind. cckit sync at any point shows the current board and what’s unblocked next.

How it works

The lifecycle is one source of truth: starting an issue creates an isolated worktree and branch, so the change can’t collide with anything else you’re running. The PR, the board columns, and the branch all reference the same issue number — you never wire them up by hand, which is what “correct by construction” means here.

One issue, one worktree

cckit start makes the branch and the worktree in one step. The change lives in its own copy of the repo until the PR merges — see Efforts, waves & worktrees.

Troubleshooting

A verb errored. cckit is quiet by design — it prints little and just does each step. So when a verb errors, take it seriously; it usually means something is genuinely off (a missing dependency, a dirty tree, an auth gap). Read the message before retrying.

The change touched more than the issue. Keep the worktree focused on the one issue. If scope grew, split it into an effort with sub-issues instead.

gc didn’t remove the branch. gc --prune only removes branches whose PR has merged. If the PR is still open, finish the merge first, then run cleanup.

Related tutorials

Set up cckit in a repo Get the board and config ready first.

Break a big feature into an effort When one issue is too big for a single PR.

Run issues in parallel with a wave Clear a whole wave of ready work at once.