Miguel Palhas
e627f53934
The never-merge rule only holds for GitHub. Gitea repos here are the user's own, so land squash-merges once CI is green, threads are resolved and the branch is current. A gitea PR with no reviewer ever requested counts as approved, otherwise it waits forever. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
61 lines
3.5 KiB
Markdown
61 lines
3.5 KiB
Markdown
---
|
|
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.
|