complete-issue
Take a GitHub issue end-to-end: implement, review, e2e verify, merge. Issue number in -> merged PR out. Trigger on 'complete issue #N', 'finish this issue end-to-end', '/complete-issue', or when user wants a fully autonomous issue-to-merged-PR run.
What this skill does
# Complete Issue
Autonomous end-to-end pipeline: **issue number in → merged PR out.**
Chains: `/start-issue` → codex review → `/e2e-verify fix-and-ship`
## Parse Arguments
```bash
ISSUE_NUM=""
FLAGS=""
SKIP_NEXT=false
for arg in $ARGUMENTS; do
if [ "$SKIP_NEXT" = "true" ]; then
FLAGS="$FLAGS $arg"
SKIP_NEXT=false
elif [ "$arg" = "--coverage-threshold" ]; then
FLAGS="$FLAGS $arg"
SKIP_NEXT=true
elif echo "$arg" | grep -qE '^--'; then
FLAGS="$FLAGS $arg"
elif [ -z "$ISSUE_NUM" ] && echo "$arg" | grep -qE '^[0-9]+$'; then
ISSUE_NUM="$arg"
else
FLAGS="$FLAGS $arg"
fi
done
if [ -z "$ISSUE_NUM" ]; then
echo "Error: Issue number is required."
echo "Usage: /complete-issue <issue-number> [--skip-coverage] [--coverage-threshold <n>] [--no-agents]"
exit 1
fi
echo "Issue: $ISSUE_NUM | Flags: $FLAGS"
```
## Loop Initialization & Re-entry
Read `loop-state.md` and run the **bootstrap block** + **re-entry check**. If `PHASE` is set, recover state and skip to the corresponding phase below; otherwise continue to Phase 1.
Phase → step routing:
- `implementing` → Phase 1
- `reviewing` → Phase 2
- `verifying` → Phase 3
---
## Phase 1: Implement (`/start-issue`)
```bash
set_loop_phase "$STATE_FILE" "implementing"
```
Invoke `/go-workflow:start-issue $ISSUE_NUM $FLAGS`. Read `phases.md` for the full sub-step list (fetch issue, create worktree, detect type, explore, design, TDD, verify, coverage, security review, commit/push/PR, watch CI).
After `/start-issue` completes, detect the PR number and worktree context, reassign `STATE_FILE` to an absolute path (because CWD may have changed if a worktree was created), and persist:
```bash
PR_NUM=$(gh pr view --json number --jq '.number' 2>/dev/null)
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 [ "$GIT_DIR_ABS" != "$GIT_COMMON_ABS" ]; then
WORKTREE_PATH=$(pwd)
echo "Running in worktree: $WORKTREE_PATH"
fi
STATE_FILE="$(pwd)/.local/state/complete-issue-${ISSUE_NUM}.loop.local.json"
mkdir -p "$(dirname "$STATE_FILE")"
TMP="$STATE_FILE.tmp"
jq --arg pr_number "$PR_NUM" --arg worktree_path "${WORKTREE_PATH:-}" \
'.pr_number = $pr_number | .worktree_path = $worktree_path' \
"$STATE_FILE" > "$TMP" && mv "$TMP" "$STATE_FILE"
echo "PR #$PR_NUM created"
```
> **Worktree-CWD invariant (decision-time, must stay in trunk):** If a worktree was created, all subsequent phases MUST operate from `$WORKTREE_PATH`. Prefix every Bash command with `cd "$WORKTREE_PATH" &&` and use `$WORKTREE_PATH` as the base for all Read/Edit/Write file paths. The pre-tool-use hook will block tool calls targeting the wrong directory. The `STATE_FILE` reassignment above ensures `set_loop_phase` calls resolve correctly regardless of CWD.
---
## Phase 2: Self-Review (Codex)
```bash
set_loop_phase "$STATE_FILE" "reviewing"
```
Run an LLM review to catch issues before E2E verification. **CRITICAL: Never silently fall back** — always present the user with options if codex fails.
Detect codex availability:
```bash
CODEX_AVAILABLE=false
if command -v codex &>/dev/null; then
CODEX_CMD="codex"
CODEX_AVAILABLE=true
elif npx -y codex --version &>/dev/null 2>&1; then
CODEX_CMD="npx -y codex"
CODEX_AVAILABLE=true
fi
```
- **If codex is NOT available** OR **if codex exec fails at runtime** → Read `codex-fallback.md` and follow the `AskUserQuestion` flow for the matching scenario. Do NOT silently fall back.
- **If codex IS available** → run codex review on the PR diff with an adaptive timeout, address findings, and commit fixes. See `phases.md` for the full bash (diff sizing, timeout calculation, large-diff warning).
Address findings: for each valid finding, make the fix. Skip false positives or cosmetic-only items. Commit fixes if any changes were made:
```bash
git add -A
git commit -m "fix: address codex review findings"
git push
```
---
## Phase 3: E2E Verify and Ship
```bash
set_loop_phase "$STATE_FILE" "verifying"
```
Invoke `/go-workflow:e2e-verify $PR_NUM fix-and-ship`. This runs the full e2e-verify workflow in `fix-and-ship` mode (rebase, build, address review, E2E browser tests, post results, add `run-full-ci` label, watch CI, invoke `/go-workflow:ship`).
---
## Completion Criteria
Output `<done>COMPLETE</done>` when ALL of these are true:
1. Issue implemented with tests
2. PR created and pushed
3. Codex review completed and findings addressed
4. E2E verification completed
5. Results posted to PR
6. CI passes
7. PR merged (via `/ship`)
**When ALL criteria are met, output exactly:** `<done>COMPLETE</done>`
**Safety:** If 15+ iterations without success, document blockers and ask user.
## Further Reading
- `phases.md` — full sub-step lists for Phase 1 (`/start-issue`) and the codex run for Phase 2
- `loop-state.md` — bootstrap, re-entry, and persist blocks
- `codex-fallback.md` — `AskUserQuestion` flows for codex unavailable / runtime failure / timeout
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.