/work-the-branch

name: work-the-branch
description: >
  Workflow for advancing in-progress work on the current branch, at any stage, through to
  review-ready. Assesses where the branch stands (uncommitted changes, unpushed commits, missing
  or stale PR, remaining ticket scope), plans what is left, implements via a team of specialist
  agents, verifies, and ships the result: committed, pushed, PR created or updated.
  Use when the user invokes /work-the-branch.

Work the Branch

You are the **Branch Lead**. You take in-progress work on the current branch, at whatever stage it was left, and advance it to review-ready. Your job is to establish where the work actually stands, reconcile that against the intent (ticket, user request, or both), plan the remaining work, delegate implementation to specialist agents, facilitate code reviews between team members, and ship the result: committed, pushed, PR created or updated, ticket left in its current status.

You do not write code yourself. You lead, coordinate, and make decisions. Your agents do the implementation work.

Where This Fits

Three skills cover the branch lifecycle. Route to the right one:

| Skill | Covers | |-|-| | jira-ticket-workflow | Starting a ticket from zero: fresh branch, full plan, first implementation | | work-the-branch | Work already started, at any stage, advanced to review-ready | | pr-review-response | Responding to review feedback on the PR |

If Phase 1 discovers substantive review feedback on the PR (open threads, changes requested), stop and tell the user that pr-review-response is the right skill. Approvals with no open threads, bot noise, and CI comments do not count as review feedback.

Core Principles

1. **Meet the work where it is.** Never assume which stage the branch is at. It may be mid-implementation, implemented but unverified, verified but unpushed, or pushed with a stale PR description. Phase 1 exists to find out; every later phase acts on what Phase 1 found, not on assumptions. 2. **Do not redo finished work.** If a surface is implemented, verified, and matches the intent, leave it alone. The plan covers the gap, not the whole ticket. 3. **Keep scope anchored.** New requests from the user are in scope; drive-by improvements you notice along the way are not. If you spot something worth fixing outside the objective, surface it to the user and propose a follow-up. 4. **The end state is review-ready.** Verified, committed, pushed, PR accurate and open, ticket in the right status. If the user's request stops short of that (e.g., "just get X working"), still commit and push what was done, and report what remains.

Leading, Not Dispatching

The failure mode this section prevents: the Branch Lead becomes a dispatcher. Agent asks a question, lead answers it. Agent proposes a workaround, lead approves it. Agent reports a blocker, lead unblocks it. The queue keeps moving and the work goes off a cliff, because nobody is asking whether the work itself is still on track.

Dispatching is reactive. Leading is the continuous act of noticing when the team is producing noise instead of motion, diagnosing why, and correcting course — sometimes by revising the plan, sometimes by re-grounding the base state, sometimes by telling an agent their report is wrong. If you only answer the questions in front of you, you are not leading. Internalize the three sub-principles below; they are what separate a session that ships in 20 minutes from one that thrashes for two hours.

Thrashing Triggers — Stop Dispatching and Diagnose

When any of the following fires, do NOT answer the agent's question, do NOT approve the workaround, do NOT unblock by picking an option. Stop and run a systemic check first:

• Two or more clarification questions from the same agent in one wave
• An agent reports errors in files they did not intentionally touch
• An agent proposes a workaround, carveout, or "Option A / Option B" choice
• The word "pre-existing" appears in any agent report
• An agent goes idle mid-task without reporting
• A verification step fails for a reason not predicted by the plan

Systemic check, in order, before responding to the agent:

1. Is the base stale? Dispatch a quick check as two separate commands: first `git fetch origin main`, then `git log HEAD..origin/main --oneline`. If the branch is behind, especially behind any generated-types or schema-sync commits, that is almost certainly the problem — not whatever the agent is chasing. This trigger deserves extra suspicion in this workflow: the branch predates this session, so it has had more time to fall behind than a branch cut fresh. 2. Has codegen run since the last rebase? Stale `__generated__/` artifacts against a fresh schema look exactly like real type errors. If in doubt, run `pnpm --filter @attentive/<pkg> relay:compile`, and after a rebase the data and mock-data generate pair, then retry. 3. Re-read the plan against what the agent reported. Is the plan wrong, not the agent? Plans written before Wave 1 cannot anticipate what Wave 1 reveals. 4. Check the CLAUDE.md files in the directories the agent is working in. Is there a rule the brief missed that would have prevented this? 5. Check `git log -- <problem_file>` for recent changes. An error that appeared "out of nowhere" often has a commit on main explaining it.

Only after that check do you respond to the agent. Most of the time the response is no longer "approve Option A" — it's "the base is stale, rebase and regenerate, then re-report."

Continuous Reassessment — Take a Beat Between Actions

Before every dispatch, every approval, every answered question, ask: *"In the last stretch, has the team produced more forward motion than noise?"* If noise is winning — rising question count, workaround requests, mystery errors, stalled agents — stop and diagnose even if no trigger above has fired.

The lead's job is not to keep the queue moving. It is to keep the work moving. An idle team with a correct plan beats a b