메뉴
Start implementation of a GitHub issue: fetch context, prepare worktree flow, implement with TDD, verify, and submit PR. Use for 'start issue #N', issue URLs, or requests to begin issue work. SKIP fully autonomous issue-to-merge requests; use complete-issue.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Address pull request review feedback from humans or bots. Use when existing comments, requested changes, unresolved review threads, or CodeRabbit/codex review findings need code fixes, verification, push updates, and thread resolution. SKIP fresh code-review requests with no existing feedback; use review-deep.
Take a GitHub issue from implementation to merged PR. Use for 'complete issue #N', 'finish this issue end-to-end', or fully autonomous issue-to-merge requests. SKIP issue startup without merge intent; use start-issue.
Run end-to-end PR verification with browser testing. Use before merge or in fix-and-ship mode when the user asks to verify a PR, run E2E, browser-test, or visually check UI changes. SKIP backend-only checks with no browser/UI path; use review-deep or ship as appropriate.
Start issue work in a new tmux window with its own worktree. Use when the user has tmux running and wants issue startup to continue outside the current session. SKIP when not inside a tmux session ($TMUX unset) or when the user wants to work in the current session; use start-issue directly.
Ship a PR end-to-end: verify locally, push, create/update the PR, watch CI, handle review feedback, and merge without admin override. Use for 'ship', 'ship it', or 'push and merge'. SKIP if the user only wants a PR opened; use `create-pr`.
Deep-review a PR or branch with issue and repo context, then fix actionable findings. Use for 'review my changes', 'check this PR', or post-implementation quality/spec review requests. SKIP existing human/bot review comments that need replies/thread resolution; use address-review.
| name | start-issue |
| description | Start implementation of a GitHub issue: fetch context, prepare worktree flow, implement with TDD, verify, and submit PR. Use for 'start issue #N', issue URLs, or requests to begin issue work. SKIP fully autonomous issue-to-merge requests; use complete-issue. |
| argument-hint | <issue-number> [--skip-coverage] [--coverage-threshold <n>] [--no-agents] |
| allowed-tools | ["Bash","Read","Glob","Grep","Edit","Write","AskUserQuestion","EnterPlanMode","Agent"] |
| disable-model-invocation | true |
If $ARGUMENTS is empty or not provided, explain:
This skill starts work on a GitHub issue, automatically detecting whether it's a bug fix or new feature and following the appropriate workflow.
Claude Code:
/go-workflow:start-issue <issue-number> [--skip-coverage] [--coverage-threshold <n>]Codex:
$start-issue <issue-number> [--skip-coverage] [--coverage-threshold <n>]Example:
/go-workflow:start-issue 123or$start-issue 123 --coverage-threshold 80Options:
--skip-coverage: Skip coverage verification after implementation--coverage-threshold <n>: Override default 60% coverage threshold--no-agents: Use single-session workflow instead of subagent dispatch (for small/simple issues)Workflow:
- Fetch issue details, labels, and comments
- Optionally create a git worktree for isolated work
- Auto-detect issue type (bug vs feature)
- Create
fix/orfeat/branch (or use worktree branch)- For bugs: Check duplicates → TDD red-green → verify → coverage check → security review
- For features: Plan approach → TDD red-green → verify → coverage check → security review
- Commit, push, and create PR
Ask the user: "What issue number would you like to work on?"
Default orchestrated mode uses model frontmatter from ${CLAUDE_PLUGIN_ROOT}/agents/*.md:
| Agent | Model policy |
|---|---|
| Explore | haiku |
| Implementer | inherit |
| Spec Review | sonnet |
| Quality Review | sonnet |
Set CLAUDE_CODE_SUBAGENT_MODEL=<model> before invoking $start-issue to
override all subagent models for a run. Use --no-agents to run the
single-session workflow without subagent dispatch.
Any artifact this skill produces — commit messages, PR titles and bodies, GitHub issue comments — describes modules, contracts, and observable behavior, not file paths, line numbers, or current internal layout. Acceptance criteria are stated as behaviors a reviewer can verify, not as file diffs. The artifact must remain interpretable after a future refactor.
Clear any leftover worktree state from a prior session. This prevents the
pre-tool-use hook from blocking commands in a fresh $start-issue invocation:
"${CLAUDE_PLUGIN_ROOT}/scripts/worktree-state.sh" clear 2>/dev/null || true
Strip optional flags and extract the issue number:
ISSUE_NUM=$(echo "$ARGUMENTS" | sed 's/--skip-coverage//g; s/--coverage-threshold *[0-9]*//g; s/--no-agents//g' | tr -d ' ')
HAS_SKIP=$(echo "$ARGUMENTS" | grep -q '\-\-skip-coverage' && echo "true" || echo "false")
COV_THRESH=$(echo "$ARGUMENTS" | grep -oE '\-\-coverage-threshold [0-9]+' | awk '{print $2}')
NO_AGENTS=$(echo "$ARGUMENTS" | grep -q '\-\-no-agents' && echo "true" || echo "false")
if ! echo "$ISSUE_NUM" | grep -qE '^[0-9]+$'; then
echo "Error: Issue number must be numeric."
echo "Claude Code: /go-workflow:start-issue <number> [--skip-coverage] [--coverage-threshold <n>] [--no-agents]"
echo "Codex: \$start-issue <number> [--skip-coverage] [--coverage-threshold <n>] [--no-agents]"
exit 1
fi
echo "Issue: $ISSUE_NUM | skip-coverage: $HAS_SKIP | coverage-threshold: ${COV_THRESH:-60} | no-agents: $NO_AGENTS"
The output above shows the parsed issue number and flag values.
CRITICAL: From this point forward, use $ISSUE_NUM (the numeric issue number
shown above) everywhere you would use $ARGUMENTS. The raw $ARGUMENTS may
contain flags and MUST NOT be passed to gh issue view, branch names, worktree
names, or state file paths.
Store the parsed flags:
SKIP_COVERAGE: true if --skip-coverage was passed, false otherwiseCOVERAGE_THRESHOLD: the value after --coverage-threshold, or 60 if not specifiedNO_AGENTS: true if --no-agents was passed, false otherwiseif [ ! -x "${CLAUDE_PLUGIN_ROOT}/scripts/setup-loop.sh" ]; then
echo "ERROR: Plugin cache stale. Run /gopher-ai-refresh (or refresh-plugins.sh) and restart Claude Code."
exit 1
else
ISSUE_NUM=$(echo "$ARGUMENTS" | sed 's/--skip-coverage//g; s/--coverage-threshold *[0-9]*//g; s/--no-agents//g' | tr -d ' ')
"${CLAUDE_PLUGIN_ROOT}/scripts/setup-loop.sh" "start-issue-$ISSUE_NUM" "COMPLETE" "" "" '{}'
fi
Gather context before worktree or plan decisions:
gh issue view "$ISSUE_NUM" --json title,state,body,labels,comments --jq '.'
git branch --show-current
git remote show origin 2>/dev/null | grep 'HEAD branch' | sed 's/.*: //' || echo "main"
basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown"
git worktree list
First, check if already running inside a git worktree:
IN_WORKTREE=false
GIT_DIR_ABS=$(cd "$(git rev-parse --git-dir 2>/dev/null)" && pwd)
GIT_COMMON_ABS=$(cd "$(git rev-parse --git-common-dir 2>/dev/null)" && pwd)
if [ -n "$GIT_DIR_ABS" ] && [ -n "$GIT_COMMON_ABS" ] && [ "$GIT_DIR_ABS" != "$GIT_COMMON_ABS" ]; then
IN_WORKTREE=true
fi
This resolves both --git-dir and --git-common-dir to absolute paths via
cd ... && pwd, then compares them. In the main repo (even from a subdirectory)
both resolve to the same absolute .git path. In a linked worktree, --git-dir
resolves to .git/worktrees/<name> while --git-common-dir resolves to .git.
If IN_WORKTREE=true: Skip the worktree question entirely. Proceed directly
to "Plan Mode Check" (the "No, work in current directory" path). Display:
Already running in a worktree — skipping worktree creation.
If IN_WORKTREE=false: You MUST use AskUserQuestion NOW before doing
anything else — including EnterPlanMode.
Do not:
Use AskUserQuestion with this exact configuration:
WAIT for the user's response. Do not proceed until they answer.
→ Read ${CLAUDE_PLUGIN_ROOT}/lib/start-issue/worktree-create.md and follow the
full procedure: capture SOURCE_DIR, derive WORKTREE_NAME/BRANCH_NAME from
issue title, fetch and create the worktree, search for env files
(.env/.env.local/.envrc) and offer to copy with directory structure
preserved, capture WORKTREE_ABS_PATH, register the worktree state file
(enables hook-based path enforcement), and confirm to the user.
After the worktree is established, continue to Plan Mode Check below.
Continue to Step 1: Detect Issue Type below. You will create a branch in the appropriate workflow step.
Now call EnterPlanMode to create a plan for the implementation (if not
already in plan mode).
Now call EnterPlanMode to create a plan for the implementation.
If you are NOT currently in plan mode (no "Plan mode is active" in your system
context), call the EnterPlanMode tool now.
CRITICAL: When writing your plan, include these facts at the top of the plan file:
If a worktree was created:
## Working Directory
All work MUST happen in: <the concrete WORKTREE_ABS_PATH value>
Original repo (DO NOT USE): <the SOURCE_DIR value>
The pre-tool-use hook will BLOCK any tool call targeting the original repo.
If no worktree:
## Working Directory
Working in current directory. A feature branch will be created.
If you ARE already in plan mode, continue with the workflow below.
Your shell CWD does NOT persist between Bash calls. Claude Code resets it
every time. You CANNOT just cd once — it will be forgotten. You must
actively use the worktree path in EVERY tool call.
| Tool | How to use the worktree path |
|---|---|
| Bash | Prefix EVERY command: cd "$WORKTREE_ABS_PATH" && <your command> |
| Read | Use $WORKTREE_ABS_PATH/path/to/file as the file_path |
| Edit | Use $WORKTREE_ABS_PATH/path/to/file as the file_path |
| Write | Use $WORKTREE_ABS_PATH/path/to/file as the file_path |
| Glob | Set path parameter to $WORKTREE_ABS_PATH |
| Grep | Set path parameter to $WORKTREE_ABS_PATH |
If you forget to use the worktree path, the pre-tool-use hook will BLOCK the tool call and tell you the correct path to use. This is your safety net.
Self-check before EVERY file operation: "Does this path start with
$WORKTREE_ABS_PATH?" If not, STOP and fix it.
Note: When using a worktree, the branch is already
issue-<num>-<title>. Skip the "Create Branch" step in the workflows below.
Continue to Step 1: Detect Issue Type below.
CRITICAL: Before starting any work, verify you will NOT commit to main/master.
This workflow creates feature branches (fix/ or feat/). If you are
currently on main, master, or the default branch:
issue-<num>-<title> branchNEVER commit directly to main/master. Always ensure a feature branch exists before making any code changes.
Analyze the issue to determine if it's a bug fix or new feature.
Check labels first (most reliable):
bug, fix, defect, error, regression, crashenhancement, feature, feat, new, improvement, requestIf no clear labels, analyze title and body:
If still uncertain, ask the user via AskUserQuestion: "I couldn't
determine if this is a bug fix or new feature. Which workflow should I follow?"
with options Bug Fix / New Feature.
NO_AGENTS=false)→ Read ${CLAUDE_PLUGIN_ROOT}/lib/start-issue/orchestrated-workflow.md for the
full 12-step procedure: duplicate check (bugs only), branch creation, Explore
subagent dispatch, design approach (features only), task decomposition +
parallel-dispatch decision, Implementer subagent dispatch (parallel or
sequential), spec-compliance review (sonnet), quality review (sonnet), verify
(build/test/lint), Step 9.5 coverage gate, security review, submit (PR template
detection + creation), watch CI.
--no-agents fallback)→ Read ${CLAUDE_PLUGIN_ROOT}/lib/start-issue/manual-workflow.md for the
single-session bug and feature flows. Both follow the same shape: explore/design
→ TDD red (IRON LAW: no implementation code before failing tests) → green →
verify → coverage → security → submit → watch CI.
Before outputting <done>COMPLETE</done>, every claim MUST have FRESH evidence
from THIS session — actual command output, not narrative:
go test output with "ok" lines, zero failuresgo build ./... exit 0golangci-lint run output (skip if not installed)gh pr checks with all checks greenRed-flag language check — if you are about to write "should work" / "should be fine" / "probably" / "likely" / "I believe this fixes…" / "I think this resolves…" / "Done!" / "Complete!" without preceding command output proving it, STOP and run verification instead.
Do NOT commit, push, or create a PR without fresh verification evidence.
DO NOT output <done>COMPLETE</done> until ALL of these are TRUE:
go test ./... or equivalent) — with output shown above--skip-coverage flag)golangci-lint run or equivalent, if installed) — with output shown abovegh pr checks shows all green) — with output shown aboveWhen ALL criteria are met, output exactly:
<done>COMPLETE</done>
This signals the loop to exit. If you output this prematurely, the issue will not be properly resolved.
Safety note: If you've iterated 15+ times without success, document what's blocking and ask the user.
Use extended thinking for complex analysis.
${CLAUDE_PLUGIN_ROOT}/lib/start-issue/worktree-create.md — full worktree creation procedure (env-file copy, state-file registration)${CLAUDE_PLUGIN_ROOT}/lib/start-issue/orchestrated-workflow.md — 12-step subagent-orchestrated flow (Explore → Implementer → spec/quality review → verify → coverage → security → submit → CI)${CLAUDE_PLUGIN_ROOT}/lib/start-issue/manual-workflow.md — single-session bug + feature flows for --no-agents