OneShot

Implement $ARGUMENTS at maximum speed. Ship fast, iterate later.

Workflow

0. Resolve input

If the input looks like a GitHub issue reference (#N, owner/repo#N, or a GitHub URL like https://github.com/.../issues/N):

1. Fetch the issue:
   • #N → gh issue view <N> --json title,body,labels (current repo).
   • owner/repo#N or full URL → gh issue view <N> --repo owner/repo --json title,body,labels.
2. Use the issue title + body as the task description.
3. If the issue body has task lists or acceptance criteria, use them as the implementation checklist.

Then proceed to EXPLORE with the resolved description.

1. Explore (minimal)

Gather the minimum context needed to identify the edit target. Direct tools first — no subagent overhead on the happy path:

• Glob for 2-3 files by pattern.
• Grep for specific symbols or strings.
• Quick WebSearch only if library-specific API knowledge is missing.

When to spawn an Explore subagent instead: if one or two direct searches don't locate the edit target, stop searching and spawn a single Explore subagent with a specific question ("find the file that handles {X}"). Reason: multiple rounds of Glob/Grep pollute the main context with file contents you'll never edit — a subagent returns just the answer. This is an exception path, not the default.

No exploration tours. As soon as the edit target is identified, move on.

1b. Complexity check (circuit breaker)

After exploring, assess whether this task actually fits oneshot. Flag if any of these signals appear:

• > 5 files need modification
• > 2 distinct systems/domains involved (auth + billing + notifications, etc.)
• Cross-cutting concerns (database migrations, API changes with client updates, etc.)
• Unclear requirements — the task seemed simple but the codebase reveals hidden complexity

If triggered: stop and warn the user before coding.

This task is more complex than it looks:
- {specific reason: e.g., "touches 8 files across 3 modules"}
- {specific reason}

Recommendations:
- /apex {task}        — structured implementation with analysis and planning
- /spec -s {task}     — plan and decompose into workstreams first

Continue with /oneshot anyway? (results may be incomplete)

Wait for user confirmation. Their call — if they continue, proceed. If not, stop.

If not triggered: proceed directly to CODE. No delay on the happy path.

2. Code

Execute the changes immediately:

• Follow existing codebase patterns exactly.
• Clear variable and method names over comments.
• Stay strictly in scope — change only what the task requires.

3. Test

Run the project's lint and typecheck commands — discover them from project instructions (CLAUDE.md, AGENTS.md, or equivalent), package.json scripts for JS/TS, pyproject.toml / Cargo.toml / go.mod for other ecosystems.

• If they fail, fix only what you broke and re-run.
• No full test suite unless the user explicitly asks.

Output

On success

## Done

**Task:** {what was implemented}
**Files changed:** {list}
**Validation:** ✓ lint ✓ typecheck

On blocker (stuck after 2 attempts, or circuit breaker declined)

## Blocked

**Task:** {what was attempted}
**Attempts:** {N}
**Blocker:** {specific failure or unknown}
**Recommendation:** /apex {task}   ← restart with structured analysis

Constraints

• One task only — no tangential improvements, no "while I'm here" additions.
• No comments unless the logic is genuinely non-obvious.
• No refactoring outside the immediate scope.
• No documentation files unless the user asks.
• Stuck after 2 attempts — report the blocker and stop. Don't thrash.