Two Claude Skills and a Worktree Rule
gh-issue-push, gh-issue-pop, and an isolated branch — the minimum guardrails for seeing what Claude intends before it starts, and where it's been when it's done
While you can read about what Claude did in a commit message, you can’t review what it’s about to do before it starts. Two commands and one branch rule create the checkpoints — before work begins and before it reaches main. The human monitors them.
A 2025 METR study measured the productivity effect of AI coding tools on experienced open-source developers. Developers using AI tools took 19% longer to complete tasks than those working without them [1]. Before the study, those same developers predicted AI would make them 24% faster. After completing it, they still believed it had.
The researchers identified cognitive overhead as a likely cause — reconstructing context, correcting scope drift, managing what the AI did versus what you asked it to do. The symptom I kept running into was a session that drifted — Claude would find something interesting adjacent to the task, I’d follow it, and an hour later there were changes across four files with nothing recording how they connected to what I’d started. The workflow below is about one specific piece of that: having a single place to see what Claude is planning before it starts, and where to look afterward to understand what it touched.
The Single Source of Truth Problem
Beads was the first thing I tried. It tracks work in progress before any commit exists — the right gap to fill. At one point it spawned over a thousand processes on my machine and took down my wifi. That was the end of beads.
Git records intent after the fact. A commit message can tell you what Claude did and why, but it’s written once the code is already there. If something looked wrong during the session, you’re catching it on review, not before Claude started. In theory, Beads solves the timing problem but fights anything more sophisticated: worktrees, parallel branches, isolated checkouts. The workflow conflicts are constant.
GitHub issues don’t have that problem. An issue exists independently of branches, worktrees, and commits. It persists across sessions. It lives next to pull requests, code review, and the rest of the project record. And because it exists before work starts, it can be reviewed before Claude touches anything. There were real friction costs getting here — API timeouts and rate limits that took some engineering to work around — but it’s the right layer because everything else already lives there.
/gh-issue-push: Making Intent Visible
When Claude finishes a task and surfaces something it didn’t handle — an edge case, an architecture concern, something it flagged — I run /gh-issue-push. It creates a GitHub issue with the context and assigns it to the repo. The same thing happens when I notice something mid-session that isn’t the current task. I push an issue and come back to it later with full attention rather than breaking the thread I’m in.
After I updated the scripts to make this explicit, Claude started suggesting it on its own. Mid-session it would say “I noticed the validation logic doesn’t cover this case — should I push an issue?” Usually yes. It pushes, we continue.
There’s also /make-work — a skill that analyzes the project state and proposes new issues when there’s nothing obvious to work on next. Between /gh-issue-push for things that surface during a session and /make-work for deliberate planning, the issue list stays current without having to maintain it by hand.
The issues are the record. If something Claude does doesn’t land there, it effectively didn’t happen as far as future sessions are concerned. The Qodo 2025 State of AI Code Quality report found that 65% of developers report AI missing relevant context during refactoring, with similar rates in testing and code review [2]. The GitHub issue is what the next session reads instead of reconstructing everything from scratch.
/gh-issue-pop: The Pre-Work Checkpoint
When I want to work on something, I run /gh-issue-show first — that lists the open issues without leaving the session. I pick the GitHub issue number, then run /gh-issue-pop <number>. Claude fetches the issue, reads the context, and starts already oriented. The issue contains the specification — no warm-up needed.
Picking the number is where I’m actually making the decision about scope. By the time Claude starts, I’ve already reviewed what it’s being asked to do. Without that step, sessions tend to drift — Claude finds something interesting, I follow it, and an hour later there are changes in a part of the codebase I didn’t plan to touch.
Vague issues work fine. “Add pre-cycle analyze step to the generation workflow” has no implementation shape, but on pop Claude reads the architecture, understands the existing structure, and produces a design — what it plans to build, how, and what it would break into sub-issues. I review that before it starts. Sometimes it’s missed the point of what I wanted, and I re-orient it there rather than after it’s written code. The decomposition happens with full context, and the correction happens before anything is irreversible.
The Worktree Rule
Claude doesn’t work on main. When it slips, the cleanup costs more than whatever time was saved.
When gh-issue-pop starts a session, Claude creates a worktree — an isolated checkout on a new branch — and all work happens there [3]. When it’s done, it opens a pull request. The PR merges automatically; the worktree is cleaned up.
I don’t review every PR as they come in. Claude generates enough churn across a feature that reviewing each one isn’t worth the time — the code is still moving. I do a code review and other checks when all the issues for a milestone are closed and the churn has settled.
The worktree matters for AI work specifically because it gives Claude a stable snapshot of the code. Branch switches, rebases, parallel work on main don’t affect what Claude sees mid-session, which avoids a class of error where it generates code against a version of the codebase that no longer exists by the time it commits [4].
The most critical operations — commits and issue tracking — are implemented in Go rather than as Claude skill instructions. Moving them out of natural language and into code reduced errors on the parts of the workflow where a mistake is hardest to reverse.
Claude still slips on the worktree rule occasionally. I catch those cases, revert the work, and close the gap in the scripts.
What This Gives You
At the end of a week: open issues for everything noticed, closed issues and merged PRs for everything completed, and a main branch that only has reviewed changes on it. The record is in one place rather than spread across session histories that nobody goes back to read.
The human checkpoint is at the front: the issue reviewed before work starts, Claude’s design reviewed before it writes code. The PR merges automatically. Code review happens once — when the milestone is done and the churn has stopped.
The cobbler-scaffold scripts that implement this are open source at petar-djukic/cobbler-scaffold. The do-work skill that runs within the worktree is part of the same set.
This builds on Three Commands to a Crude Orchestrator, which introduced the bootstrap/make-work/do-work pattern. The issue tracker extends that pattern across sessions and keeps the record in one place. The worktree rule is a guardrail that keeps the workflow from drifting into a mess. The two gh commands are the checkpoints — one before work starts, one before it lands on main. The human monitors both.
REFERENCES
[1] METR. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[2] Qodo. (2025). State of AI Code Quality in 2025. https://www.qodo.ai/reports/state-of-ai-code-quality/
[3] Nx Blog. (2025). Git Worktrees for AI Agents. https://nx.dev/blog/git-worktrees-ai-agents
[4] Upsun Developer Center. (2025). Git Worktrees for Parallel AI Coding Agents. https://devcenter.upsun.com/posts/git-worktrees-for-parallel-ai-coding-agents/
[5] GitHub. (2025). IssueOps: Automate CI/CD (and more!) with GitHub Issues and Actions. GitHub Engineering Blog. https://github.blog/engineering/issueops-automate-ci-cd-and-more-with-github-issues-and-actions/
[6] Wiggins, A. (2011). The Twelve-Factor App, Factor VI: Processes. https://12factor.net/processes