quick

<objective>
Execute quick implementations for small changes (bug fixes, refactors, minor enhancements) bypassing the full spec/plan/tasks workflow. Uses Task() isolation for implementation with full Q&A support.

**CRITICAL ARCHITECTURE** (v2.0 - Task() Orchestrator Pattern):

This orchestrator is **lightweight**. You MUST:
1. Parse arguments and validate scope (inline)
2. Create branch (inline)
3. Spawn isolated quick-worker agent via **Task tool**
4. Handle Q&A when agent returns `---NEEDS_INPUT---`
5. Display summary from agent result

**Benefits**: Implementation is isolated, Q&A flows naturally, consistent with /feature and /epic patterns.
</objective>

<context>
Current git status:
!`git status --short`

Current branch:
!`git branch --show-current`

Recent commits (last 3):
!`git log -3 --oneline`

Studio context (multi-agent isolation):
!`bash .spec-flow/scripts/bash/worktree-context.sh studio-detect 2>/dev/null || echo ""`

Worktree context:
!`bash .spec-flow/scripts/bash/worktree-context.sh info 2>/dev/null || echo '{"is_worktree": false}'`
</context>

<when_to_use>

## Good Candidates (Use /quick)

- **Bug fixes**: UI glitches, logic errors, null checks
- **Small refactors**: Rename variables, extract functions, simplify logic
- **Internal improvements**: Logging, error messages, constants
- **Documentation**: README updates, code comments, docstrings
- **Style/formatting**: Whitespace, naming conventions, linting fixes
- **Config tweaks**: Environment variables, build settings, tool configs

**Characteristics**: <100 LOC, <5 files, single concern, no breaking changes, can implement in one sitting

## Do NOT Use (Use /feature Instead)

- **New features with UI components** - Needs design review and mockup approval
- **Database schema changes** - Requires migration planning and zero-downtime strategy
- **API contract changes** - Breaking changes need stakeholder review
- **Security-sensitive code** - Auth, permissions, crypto need thorough review
- **Changes affecting >5 files** - Coordination across modules needs planning
- **Multi-step features** - Complex workflows need task breakdown

**Rule of thumb**: If you need to pause and think about architecture, use `/feature`.
</when_to_use>

<planning_depth>
## Deep Mode for Quick Changes (--deep)

**When to use --deep with /quick**:
- Complex refactor that touches architectural patterns
- Bug fix that reveals deeper design issues
- Quick change that might benefit from assumption questioning

**What --deep does for /quick**:
1. Loads ultrathink skill before implementation
2. Applies simplified craftsman checklist:
   - What assumptions am I making about this "quick" fix?
   - Is there a simpler solution?
   - Does this align with codebase patterns?
3. Does NOT generate full craftsman-decision.md (overkill for quick)

**Typical /quick stays fast**:
- No --deep flag → Standard implementation
- Skips assumption inventory
- Skips codebase soul analysis
- Just implements the change

**Example**:
```bash
/quick "fix null check in UserService"           # Standard quick fix
/quick "refactor auth validation" --deep         # Deep thinking for complex refactor
```
</planning_depth>

<studio_mode>
## Studio Mode (Multi-Agent Isolation) (v11.8)

When running in a studio worktree (`worktrees/studio/agent-N/`), the quick workflow automatically:

1. **Detects studio context** - Auto-detected from working directory
2. **Namespaces branches** - `studio/agent-N/quick/fix-button` instead of `quick/fix-button`
3. **Creates PRs for merging** - Studio agents create PRs (like a real dev team)
4. **Prevents git conflicts** - Each agent has isolated branches

**Detection (automatic, no user action needed):**
```bash
STUDIO_AGENT=$(bash .spec-flow/scripts/bash/worktree-context.sh studio-detect 2>/dev/null || echo "")
IS_STUDIO_MODE=$([[ -n "$STUDIO_AGENT" ]] && echo "true" || echo "false")
```

**Branch naming in studio mode:**
```bash
# Get namespaced branch (handles studio detection automatically)
BRANCH=$(bash .spec-flow/scripts/bash/worktree-context.sh studio-branch "quick" "$SLUG" 2>/dev/null)
# Returns: "studio/agent-1/quick/fix-button" in studio mode
# Returns: "quick/fix-button" in normal mode
```
</studio_mode>

<process>

## PHASE 0.5: Worktree Safety Check (v11.8)

**Before any work, verify we're in a safe location.**

Quick changes follow a simpler safety model:
- If in a worktree → proceed (working in isolated space)
- If in root with active worktrees → warn but allow (quick changes are low-risk)
- Quick changes get their own lightweight branches, not full worktrees

```bash
SAFETY_CHECK=$(bash .spec-flow/scripts/bash/worktree-context.sh check-safety 2>/dev/null || echo '{"safe": true}')
IS_SAFE=$(echo "$SAFETY_CHECK" | jq -r '.safe')
IN_WORKTREE=$(echo "$SAFETY_CHECK" | jq -r '.in_worktree')
ACTIVE_COUNT=$(echo "$SAFETY_CHECK" | jq -r '.active_worktrees | length // 0')
```

**If IN_WORKTREE is true:**
- Proceed normally (isolated environment)

**If IN_WORKTREE is false AND ACTIVE_COUNT > 0:**
- Output warning:
```
⚠️  Note: Active worktrees detected. Quick changes from root will be on a separate branch.
    Active worktrees: ${ACTIVE_COUNT}
    Proceeding with quick change...
```
- Proceed with quick change (creates its own branch)

**If IS_SAFE is true:**
- Proceed normally

---

## PHASE 1: Parse Arguments and Validate Scope (INLINE)

**User Input:**
```text
$ARGUMENTS
```

### Step 1.1: Get Description

**If $ARGUMENTS is empty:**

Use AskUserQuestion to request:
```
Question: "What change would you like to implement?"
Header: "Quick Change"
Options:
  - label: "Bug fix"
    description: "Fix an existing bug or issue"
  - label: "Refactor"
    description: "Improve code structure without changing behavior"
  - label: "Documentation"
    description: "Update README, comments, or docstrings"
  - label: "Config change"
    description: "Update environment variables or settings"
```

**Store the description in DESCRIPTION variable.**

### Ste