go

name	go
description	Plan, implement, and iteratively review a task end-to-end using Claude + Copilot reviewers in a linear flow.
argument-hint	<task description> [--skip-planner] [--skip-copilot] [--plan-file <path>]
model	sonnet

/go

End-to-end orchestrator: plan → implement → simplify → commit → open draft PR → Claude review loop → Copilot review loop → one final Claude review pass to catch anything Copilot's fixes introduced.

The expensive steps (review-fix-loop.sh, copilot-review-loop.sh) run each round in a fresh claude -p subprocess, so the main context only carries planning and the initial implementation.

Arguments

• <task description> — what to build/fix. Required unless the branch already has uncommitted/unpushed work (see Step 1) or --plan-file is given.
• --skip-planner — skip the implementation-planner sub-agent; implement directly from the description.
• --skip-copilot — skip the Copilot rounds and the final Claude pass. Useful when there's no PR yet or Copilot is unavailable.
• --plan-file <path> — use an already-approved plan file directly (e.g. one written by Plan Mode) instead of looking up or generating one. Implies skipping the planner.

Steps

Step 1: Parse arguments

Extract from $ARGUMENTS:

• SKIP_PLANNER — boolean, true if --skip-planner is present.
• SKIP_COPILOT — boolean, true if --skip-copilot is present.
• PLAN_FILE — the path following --plan-file, if present.
• TASK — everything else, joined with spaces.
• SLUG — short kebab-case identifier derived from TASK (e.g. "add dark mode toggle" → "add-dark-mode-toggle"). Used in commit messages and planner descriptions. If TASK is empty and PLAN_FILE is set, SLUG is derived in Step 2 from the plan file instead.

If PLAN_FILE is set and TASK is empty, skip the in-flight-work check below and go straight to Step 2 — the plan file is the entry point, not a task description.

If TASK is empty and PLAN_FILE is not set, check for in-flight work:

git status --porcelain
git log @{u}..HEAD --oneline 2>/dev/null || git log -5 --oneline

If the working tree is dirty or there are unpushed commits, set CONTINUING=true, derive SLUG from the most recent commit subject, and jump to Step 4. Otherwise stop and ask the user what to build.

Step 2: Plan

If PLAN_FILE was supplied via --plan-file, skip the planner and the existing-plan search below entirely: read the plan file with the Read tool, and derive SLUG from its first # heading (kebab-cased) if TASK wasn't otherwise provided — fall back to slugifying TASK or the current branch name if the plan has no clear heading. Still compute plan_dir using the snippet below, then copy the plan file to $plan_dir/$SLUG.md (creating the directory if needed) so it participates in the same archival convention as planner-authored plans and a later /go re-invocation on this branch still finds it — unless plan_dir comes back empty (unrecognized repo), in which case skip the copy and just proceed with the original PLAN_FILE path. Tell the user which plan you're using, then go to Step 3.

If SKIP_PLANNER is true, skip the planner but still write a brief: one paragraph covering goal, files in scope, definition of done, and out of scope. Without it, every subagent spawned later interprets the raw task description independently and they diverge. Use the brief as the spec wherever later steps reference the plan, then go to Step 3.

First, check whether a plan already exists for this work. Compute the plan directory based on ~/CLAUDE.md conventions:

repo=$(gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null || echo "")
branch=$(git branch --show-current)
case "$repo" in
  PostHog/*) plan_dir="$HOME/dev/haacked/notes/PostHog/repositories/${repo#PostHog/}/plans" ;;
  */*)       plan_dir="$HOME/dev/ai/plans/$repo" ;;
  *)         plan_dir="" ;;
esac

If $plan_dir is set, look for an existing plan in this preference order:

1. $plan_dir/$SLUG.md
2. $plan_dir/${branch##*/}.md (branch name minus any owner/ prefix)
3. If the directory contains exactly one .md file, use it

If a plan was found, read its first 100 lines with the Read tool (read specific later sections only when a step needs them), briefly tell the user which plan you're using, and skip to Step 3.

Otherwise spawn the planner as a sub-agent so its research stays out of the main context:

Agent tool with:
  subagent_type: implementation-planner
  description: "Plan: $SLUG"
  prompt: <TASK> plus any relevant context from this conversation

The planner writes a plan file per its own contract.

Step 3: Implement

First, dispatch the test writer in the background so tests are designed from the spec, not the implementation:

Agent tool with:
  subagent_type: unit-test-writer
  description: "Tests: $SLUG"
  run_in_background: true
  prompt: the plan file contents (or the Step 2 brief) — and nothing else.
    Instruct it to write tests for the behavior the spec defines, match
    existing test conventions, and report which tests fail. Failures are
    expected: the implementation doesn't exist yet.

Tests written with the implementation in view tend to mirror it instead of testing the spec, so do not include any implementation details in the prompt. Skip the dispatch if the task has no testable behavior (docs, config, a refactor already covered by existing tests).

Then implement the change in the current context. Follow the plan file if one exists, otherwise work directly from TASK. This step is conversational — check in with the user on judgment calls.

Preserve context aggressively. The review loops in Steps 6–8 run in fresh subprocesses, but Step 3 stays in main context through the rest of the run. Every file read and search compounds. Push expensive reads into subagents that return summaries instead of raw content:

• Codebase exploration (anything that would take more than ~3 greps/reads to answer): spawn Explore. Ask for the specific answer, not a file dump — e.g. "where is auth middleware registered and what's its call signature?" rather than "show me the auth code".
• Writing tests: already running in the background from the dispatch above. Only spawn another unit-test-writer for behavior discovered during implementation that the spec didn't cover. Don't read the test file into main context first — the subagent will.
• Stuck after two failed fix attempts: spawn bug-root-cause-analyzer rather than continuing to debug in main context.
• Reading large generated files, lockfiles, fixtures, or logs: spawn general-purpose with a narrow question. Never Read a file >500 lines into main context unless you actually need to edit it.

The edits themselves must happen in main context (so the user sees the diffs), but everything that informs the edits can be delegated. If you find yourself about to read a fourth file just to understand a pattern, stop and spawn a subagent instead.

When the implementation is done, collect the background test agent's results and reconcile. The tester worked from the spec alone, so fix any guessed names, signatures, or import paths to match the real implementation — keep the test intent. Then run the suite. A test that still fails points at an implementation gap: fix the implementation, not the test, unless the test misreads the spec.

Step 4: Simplify and commit

Invoke /simplify (bundled Claude slash command — not a skill). It applies its own fixes.

Then commit. Use a message that matches the situation:

• If Step 3 produced a fresh implementation: "Initial implementation: $SLUG"
• If CONTINUING=true from Step 1: "Continue work on $SLUG"

Skill("commit", args: "--force <message>")

If /simplify made no changes and there's nothing to commit, skip this step.

Step 5: Open a draft PR (if needed)

Check for an existing PR on the current branch:

gh pr list --head "$(git branch --show-current)" --json number --jq '.[0].number // empty'

If the output is non-empty, a PR already exists — leave it alone and move on. If the output is empty, open one as a draft:

Skill("create-pr", args: "--force")

Step 6: Claude review loop (until convergence)

Run the existing fresh-context review loop via the Bash tool:

~/.dotfiles/bin/review-fix-loop.sh

It iterates Claude review → fix → simplify → commit until a round comes back clean (or hits its own max-iterations). Exits 0 on clean, non-zero if findings remain.

Step 7: Copilot review loop (until convergence)

If SKIP_COPILOT is true, skip to Step 9.

Otherwise run the Copilot loop against the current branch's PR:

~/.dotfiles/bin/copilot-review-loop.sh

It auto-detects the PR from the current branch, fetches Copilot's review, fixes legit findings, replies to and resolves dismissed Copilot threads, pushes, and repeats until Copilot has no new comments. Replies to human reviewers are never auto-posted; the loop drafts them and prints them at the end for you to review and post.

Step 8: Final Claude pass

Rerun the Claude review loop once more to catch anything Copilot's fixes introduced:

~/.dotfiles/bin/review-fix-loop.sh

review-fix-cycle uses --append internally, so this pass only surfaces new findings. It typically exits clean on the first iteration.

Step 9: Report

Tell the user what happened:

• Commits added during the run (git log @{u}..HEAD --oneline or the range since the initial commit from Step 4)
• The PR URL (gh pr view --json url -q .url)
• Any outstanding findings — check .notes/review-skipped.md for Claude's deferred items and the Copilot state file under ~/.local/state/copilot-review-loop/ for low-confidence Copilot items flagged for human review.
• Any drafted replies to human reviewers the loop printed under "Human Reviewer Replies to Post" — these are not posted automatically; surface them so the user can review and post.

If any step exited non-zero, tell the user which one and where the logs are (.notes/ for Claude, ~/.local/state/copilot-review-loop/ for Copilot).