agent-skills/skills/yolo/SKILL.md

name, description, user-invocable, args

name	description	user-invocable	args
yolo	Pick or create a task in GitHub, Gitea, or Linear, implement it in a worktree, and push directly with minimal ceremony	true	name description required input A GitHub or Gitea issue number, a Linear issue ID, an ad-hoc task description, or omit to auto-pick the next unblocked task 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.