yolo

Files (1)

• SKILL.md

SKILL.md (first lines)

# yolo — commit, push, PR, watch CI, merge, verify in production

Run the full ship pipeline autonomously. **Done means running in production**,
not merged: where merging triggers a deploy, the run is not finished until the
new build is confirmed serving (step 7). The point of `yolo` is that the user
has opted into NOT being asked at each step — proceed through all stages without
pausing for confirmation, stopping ONLY on a hard failure (merge conflict, red
CI that isn't a known flake, a protected-branch rejection).

## Preconditions (check fast, fail loud)

1. Confirm you are in a git repo and NOT on the default branch (`main`/`master`).
   - If on the default branch, create one first:
     `git switch -c <short-kebab-feature-name>` derived from the change.
   - If a worktree/session branch already exists, use it.
2. `gh auth status` must be usable. If `gh` is missing/unauthed, stop and tell
   the user to auth (`gh auth login`) — do not fall back to raw API.

## Pipeline

### 0. Commit FIRST, then review

Commit before review, not after. Review agents run in this same working tree,
and a dirty tree is shared mutable state between you and them.

This is not hypothetical. On a real run a review agent tried to clean up its own
scratch files, hit a permission denial on `rm`, fell back to
`git clean -f internal/store/`, and destroyed five untracked files — two of them
the main thread's in-progress tests, unrecoverable because they were never
committed. A second agent reverted an uncommitted edit that was mid-write.

Committing first makes agent scratch visibly untracked, makes `git clean`
survivable, and means the review reads a stable snapshot rather than a tree
changing underneath it.

- `git add -A` (stage everything) unless the user scoped specific paths.
- Write a real Conventional Commits message (`type(scope): subject`, imperative,
  ≤50-char subject; body only when the "why" isn't obvious). Never a placeholder.
- If nothing to commit AND the branch is already pushed, skip to step 2.

### 1. Review — mandatory, never skipped

Review is the reason to run yolo, not a preamble to it. This is the only review
the change is guaranteed to get — no required status check gates merges in this
repo, and other repos may have none either. Never assume GitHub will catch what
you skip.

- Run `/pr-review-toolkit:review-pr` (all aspects) against the committed diff
  (`git diff origin/<default-branch>...HEAD`).
- **Tell the agents they may read and report only.** They must not delete, move,
  or modify any file, and must not run `git clean`, `git checkout --`,
  `git stash`, or `git restore`. Scratch files they create are to be left in
  place and named in their report so the main thread can remove them. An agent
  that "tidies up" is editing a tree someone else is working in.
- Run it for **every** diff. Do not skip because the change looks small, is
  docs-only, is prose, or "obviously" has no executable code — that judgment is
  not yours to make here, and the cost of a needless review is far lower than the
  cost of an unreviewed change reaching `main` unchecked.
- **State the stakes in the prompt.** Findings track what the agents are told to
  look for: "review this diff" surfaces style, while naming what the change can
  destroy ("this migration runs against a live database holding 318
  irreplaceable rows") surfaces data loss. Say what is irreversible, what is
  production, and what cannot be regenerated.
- Apply what it recommends: fix Critical + Important issues directly. Suggestions
  are optional — apply if cheap/obvious, skip otherwise. Amend or add commits as
  you go; the branch is already committed, so fixes are ordinary commits.
- Don't stop to ask before applying fixes — that's the point of yolo. Only stop
  if a finding is ambiguous enough that guessing the fix risks breaking behavior.
- Re-run is not required after fixes; proceed straight to push.
- If the review cannot run, or does not return findings you can act on (including
  a `max_turns` timeout or a half-completed pass), treat it as not having run:
  say so plainly and STOP. Never merge something that was never reviewed while
  implying it was.

### 1b. Schema migrations — run it against real data before shipping

If the diff touches `migrations/` (or otherwise changes a schema), reading it is
not enough. Both of the worst bugs found on a real run were invisible in the
diff and only appeared when the migration was executed:

- **A cascade nobody mentioned.** Foreign keys were on, so `DROP TABLE videos`
  during a table rebuild fired `ON DELETE CASCADE` and silently emptied
  `video_index_notes` — a table the diff never names, joined by every search.
  No error, and the scanner that could have rebuilt it was deleted in the same
  change.
- **A plausible value that aborts the deploy.** One teacher name appearing twice
  made a name-join fan one row into two, failing on
  `UNIQUE constraint failed: videos_new.id` — naming neither the table at fault
  nor the duplicate.

So:

- Copy the production database and run the migration against the copy. **Copy
  the `-wal` and `-shm` files too** for SQLite — a copy of the `.db` alone reads
  stale committed state and will show you a migration that "did not run".
- Assert **row conservation on every table**, not just the one being altered.
  Count before, count after, compare. That single check catches both bugs above:
  a cascade is a count that dropped, a fan-out is a count that grew.
- Check the invariants the new schema claims. If a column caches something
  derived, verify no row disagrees with the function that derives it.
- Report the before/after table in the PR body. It is the evidence the migration
  is safe, and the reviewer cannot reproduce it.

Add a regression test that seeds the tables the migration does *not* mention.
A test that only seeds what the diff touches will pass while a neighbouring
table is being emptied.

### 2. Push
- `git push -u origin HEAD`.

### 3. PR
- If a PR for this branch already exists (`gh pr view --json number,url,state`),
  reuse it. Otherwise `gh pr create --fill` (or a written title/body summarizing
  what and why). Base = the repo default branch unless told otherwise.
- Capture the PR number + URL; report the URL to the user.

### 4. Watch CI
- First check whether there is anything to watch: `gh pr checks <num>`. Checks can
  take a few seconds to register after a push, so if it reports none, wait ~15s and

From bonzofenix/skills, MIT.

More from bonzofenix/skills