---
name: yolo
description: "Pick or create a task in GitHub, Gitea, or Linear, implement it in a worktree, and push directly with minimal ceremony"
user-invocable: true
args:
  - name: input
    description: "A GitHub or Gitea issue number, a Linear issue ID, an ad-hoc task description, or omit to auto-pick the next unblocked task"
    required: false
---

# Yolo - Quick Ship Flow

Fast autonomous workflow: tracking issue -> worktree -> implementation -> push -> done. No PRs, no reviews. GitHub and Gitea are the primary tracker backends; Linear remains supported. Select one with `tracker` in `.claude/tracker.json`.

**First:** Read `tracker-common/COMMON.md` (sibling skill, same skills root) for shared setup instructions.

## Workflow

### 1. Setup (from COMMON.md)
- Load project config
- Select task (from `$ARGUMENTS`)
- Set up worktree
- Gather context

### 2. Implement

Follow the implementation guidelines from COMMON.md. Move fast — this is yolo mode.

- Skip formal planning. Read the issue, understand it, start coding.
- Still write tests if the project has them, but don't block on edge cases.
- While coding, check **only what you touched** — the module's own tests, typecheck, lint. Not the whole suite.
- Once, before pushing, run the configured `buildCommand` through the gate (see "Local verification budget" in COMMON.md):
  ```
  <skills-root>/tracker-common/scripts/gate.sh -- <buildCommand>
  ```
  If it fails, fix it. If a failure is minor and unrelated to your change, warn the user but keep going. **Exit 75** means the machine was busy and it never ran — push anyway, note it in the commit body, and arm the CI watcher below. **Exit 137** is the memory cap, not a bug.

### 3. Ship

1. Push the branch: `git push -u origin <branch>`
2. If the work is complete and self-contained, merge to the default branch:
   ```
   git checkout <defaultBranch>
   git merge <branch> --no-edit
   git push
   git checkout <branch>
   ```
   Only do this if the change is clearly ready. If unsure, just push the branch and let the user decide.
3. Mark the tracking issue done:
   - **linear**: move the issue to "Done".
   - **gitea**: close it — `curl -sS -X PATCH -H "Authorization: token $GITEA_TOKEN" -H "Content-Type: application/json" "$BASE/api/v1/repos/$REPO/issues/$N" -d '{"state":"closed"}'` (or put `Closes #N` in the final commit merged to the default branch).
4. That's it. No PR, no review loop.

**CI confirm (no loop).** If the repo runs CI on push/merge, arm ONE background watcher that wakes you only if CI fails, then stop. Don't sit polling. **Mandatory when the local gate returned 75** — that push is the only verification the change has had.
- GitHub: `gh pr checks <N> --watch --fail-fast` (if a PR exists) or `gh run watch <run-id> --exit-status` via Bash `run_in_background: true`. Non-zero exit → report the failing job to the user.
- Gitea: one-shot Monitor on `"$BASE/api/v1/repos/$REPO/commits/<sha>/statuses"` that exits on `success|failure|error` (same snippet as `/land`'s Gitea CI watcher). Report only on `failure`/`error`.

This stays true to yolo: fire-and-forget, model idle, surfaces only a broken build.

**If a PR does exist and you want it driven to green + ready-to-merge** (CI waited on, review comments resolved, iterated until done; it merges on gitea, and on GitHub the merge click stays with the user) — don't hand-roll it here. Hand off to **`/land <N>`** (the `land` skill), the same loop `/work` uses. That's the escape hatch when a "yolo" task turns out to need real review follow-through.