drive

What this skill does

# Drive

Complete drive session skill covering the `/drive` command workflow, ticket navigation and prioritization, per-ticket implementation, approval, reporting, archiving, and frontmatter updates.

## Agent Compatibility

This skill works on any Agent-Skills-compatible agent. The two Claude-Code mechanisms used below are **enhancements, not requirements**:

- **Parallel fan-out** — where a step spawns a `general-purpose` subagent (e.g. the ticket prioritizer), that is the Claude Code optimization. On other agents, perform that work **inline/sequentially** in the same session; the inputs and outputs are identical.
- **User interaction** — where a step uses `AskUserQuestion` (order confirmation, per-ticket approval, icebox/abandon choices), use the agent's native way of presenting a multiple-choice question (or ask in plain chat). The decision points are mandatory; only the prompt mechanism varies.

## Command Workflow

End-to-end orchestration for `/drive`. The thin `/drive` command preloads this skill and follows this section.

### Pre-check: Dependencies

```bash
bash ${CLAUDE_PLUGIN_ROOT}/skills/check-deps/scripts/check.sh
```

If `ok` is `false`, display the `message` to the user and stop.

### Phase 0: Worktree Guard

Check if trip worktrees exist before proceeding:

```bash
bash ${CLAUDE_PLUGIN_ROOT}/skills/branching/scripts/check-worktrees.sh
```

If `has_worktrees` is `true`, present the user with a choice using `AskUserQuestion` with selectable options:
- **"Continue here"** - Proceed with drive on the current branch
- **"Switch to worktree"** - Run `bash ${CLAUDE_PLUGIN_ROOT}/skills/branching/scripts/list-all-worktrees.sh`, display the worktree list, and inform the user to navigate to the selected worktree to run `/drive` there

If `has_worktrees` is `false`, proceed silently to Phase 1.

**Rationale**: Prevents accidental development on a drive branch when trip worktrees with in-progress work may be the intended target.

**Trip branch compatibility**: The drive workflow operates on any non-main topic branch, including `trip/*` branches. When running on a trip branch after a trip session completes, tickets are read from `.workaholic/tickets/todo/` and archived normally. Use `/ticket` to add refinement tickets, then `/drive` to implement them.

### Phase 1: Navigate Tickets

The command (main agent) runs the **Navigator** section below. Navigation splits into non-interactive prioritization (delegated to a leaf subagent) and user confirmation (issued by the command), because subagents cannot call AskUserQuestion.

Determine mode from `$ARGUMENT`:
- If `$ARGUMENT` contains "icebox": mode = "icebox"
- Otherwise: mode = "normal"

**Normal mode:**

1. Run `bash ${CLAUDE_PLUGIN_ROOT}/skills/drive/scripts/list-todo.sh`. If it prints nothing, follow the Navigator section's empty-queue handling (offer icebox/stop via `AskUserQuestion`).
2. If todo tickets exist, spawn a `subagent_type: "general-purpose"` subagent (`model: "opus"`) whose prompt instructs it to preload `core:drive`, run the Navigator section's **list / analyze / prioritize** logic (read frontmatter, dependency topo-sort, severity ranking, context grouping), and return the proposed ordered ticket list with tier grouping as JSON. This subagent does NOT call AskUserQuestion.
3. The command presents the prioritized list and confirms the order with the user via `AskUserQuestion` (Navigator section, "Confirm Order with User"), then proceeds to Phase 2 with the resolved order.

**Icebox mode:** the command runs the Navigator section's Icebox Mode steps directly (list via script, select via `AskUserQuestion`, promote via script).

Outcomes:
- No tickets in todo or icebox - Inform user: "No tickets in queue or icebox."
- User chooses to stop - End the drive session
- User chooses icebox - Run icebox mode
- Order confirmed - Proceed to Phase 2 with the ordered ticket list

### Phase 2: Implement Tickets

For each ticket in the ordered list:

#### Step 2.1: Implement Ticket

Follow the **Workflow** section below. Implementation context is preserved in the main conversation, providing full visibility of changes made. Apply the policies, practices, and standards from the relevant preloaded leading skill(s) — see the Lead Lens table in the `create-ticket` skill for the layer-to-lead mapping.

#### Step 2.2: Request Approval

Follow the **Approval** section below to present the approval dialog. **CRITICAL**: You MUST use the `title` and `overview` fields from the Step 2.1 workflow result to populate the approval prompt header and question. If these fields are unavailable, re-read the ticket file to obtain them. Never present an approval prompt without the ticket title and summary.

**CRITICAL**: Use `AskUserQuestion` with selectable `options`. NEVER proceed without explicit user approval.

#### Step 2.3: Handle User Response

**"Approve" or "Approve and stop"**:
1. Follow the **Final Report** section below to update ticket effort and append the Final Report section
2. **Verify update succeeded**: If Edit tool fails, halt and report the error to user. DO NOT proceed to archive.
3. Archive and commit by calling the archive script directly:
   ```bash
   bash ${CLAUDE_PLUGIN_ROOT}/skills/drive/scripts/archive.sh \
     <ticket-path> "<title>" <repo-url> "<description>" "<changes>" "<test-plan>" "<release-prep>"
   ```
   Where `<ticket-path>` is the current ticket file path in `todo/`, `<title>` is the commit title,
   and `<repo-url>` comes from the gather skill's `git-context.sh` output.
   **NEVER manually move tickets** with `mv` + `git add` -- always use the archive script.
4. If "Approve and stop": break loop, skip Phase 3, go directly to Phase 4
5. Otherwise: continue to next ticket

**Free-form feedback** (user selects "Other" and provides text):

> **CRITICAL**: Update the ticket file FIRST. Do NOT re-implement until the ticket reflects the user's feedback.

1. Follow the **Approval** section below (Handle Feedback) — this updates the ticket
2. **Verify** the ticket file was updated (re-read it)
3. Re-implement changes based on the updated ticket
4. Return to Step 2.2

**"Abandon"**:
1. Follow the **Approval** section below (Handle Abandonment)
2. Break loop, skip Phase 3, go directly to Phase 4 (same as "Approve and stop")

### Phase 3: Re-check and Continue

After all tickets from the navigator's list are processed:

1. **Re-check todo directory**:
   ```bash
   bash ${CLAUDE_PLUGIN_ROOT}/skills/drive/scripts/list-todo.sh
   ```

2. **If new tickets found**:
   - Inform user: "Found N new ticket(s) added during this session."
   - Re-run Phase 1 navigation (mode = "normal")
   - Continue to Phase 2 with the new ticket list

3. **If no new tickets**:
   - Check icebox (existing behavior from navigator)
   - If user declines icebox or icebox empty, proceed to Phase 4

### Phase 4: Completion

After todo is truly empty (and user declines icebox):
- Summarize what was done across all batches
- List all commits created during the session

**Session-wide tracking**: Maintain counters across multiple navigator batches:
- Total tickets implemented
- Total commits created
- List of all commit hashes

### Critical Rules

**NEVER autonomously move tickets to icebox.** Moving tickets is a developer decision, not an AI decision.

If a ticket cannot be implemented (out of scope, too complex, blocked, or any other reason):

1. **Stop and ask the developer** using `AskUserQuestion` with selectable `options`
2. Explain why implementation cannot proceed
3. Use selectable options (NEVER open-ended text questions):
   - "Move to icebox" - Move ticket to `.workaholic/tickets/icebox/` and continue to next
   - "Skip for now" - Leave ticket in queue, move to next ticket
   - "Abort drive" - Stop the drive session entirely

**Never commit ticket moves without explicit developer approval.**

## Navigator

Navigate tickets for the `/drive` command: list, analyze, prioritize, and confirm execution order. Responsib