Development
Skill
/yolo-status
Use when the user asks where things stand, what's in progress, what's landed, or "where was I" in a YOLO repo. Derives every feature's status from git and the briefs; nothing is read from a stored status field.
Claude Code
$ npx -y skills add CoriChui/yolo --skill yolo-status --agent claude-code
Codex
$ npx skills add CoriChui/yolo --skill yolo-status -a codex -y
Cursor
$ npx skills add CoriChui/yolo --skill yolo-status -a cursor -y
Gemini CLI
$ npx skills add CoriChui/yolo --skill yolo-status -a gemini-cli -y
GitHub Copilot
$ npx skills add CoriChui/yolo --skill yolo-status -a github-copilot -y
OpenCode
$ npx skills add CoriChui/yolo --skill yolo-status -a opencode -y
Windsurf
$ npx skills add CoriChui/yolo --skill yolo-status -a windsurf -y
SKILL.md
yolo-status.SKILL.mdname: yolo-status
description: Use when the user asks where things stand, what's in progress, what's landed, or "where was I" in a YOLO repo. Derives every feature's status from git and the briefs; nothing is read from a stored status field.
yolo-status
Report every feature's state by deriving it from git, exactly per `../../yolo/conventions.md` *Deriving status*. There is no stored status. Don't look for one.
Procedure
1. Resolve `base_branch` (config, else the detection rule). Guard refs with `git rev-parse --verify -q`; if base doesn't resolve, report a config error and stop. 2. Collect evidence once, not per feature:
- subjects of merges made on base: `git log --first-parent <base> --merges --format=%s`
- first-parent line of base: `git rev-list --first-parent <base>`
- `YOLO-Feature` trailers on base, and `yolo/done/*` tags
- live branches: `git for-each-ref --format='%(refname:short)' refs/heads/feature/`
3. For each `workspace/features/*/brief.md` (slug = folder name), classify in order: cancelled → landed → verified → in-progress → planned. Use the slug-boundary match for merge subjects so `csv` never matches `csv-export`. 4. Add an **untracked-branch** row for every `feature/<slug>` with no brief. 5. For `planned`/`in-progress` rows whose brief has `depends_on`, mark any dependency that hasn't landed as `blocked-by: <slug>`. 6. Print a compact table: slug · status · milestone · blocked-by · last commit date on the branch (in-progress only). Group by `milestone` when set. End with one line naming the most recently touched in-progress branch.
Constraints
- Read-only. Compute, never store.
Read more
name: yolo-status description: Use when the user asks where things stand, what's in progress, what's landed, or "where was I" in a YOLO repo. Derives every feature's status from git and the briefs; nothing is read from a stored status field.
yolo-status
Report every feature's state by deriving it from git, exactly per `../../yolo/conventions.md` *Deriving status*. There is no stored status. Don't look for one.
Procedure
1. Resolve `base_branch` (config, else the detection rule). Guard refs with `git rev-parse --verify -q`; if base doesn't resolve, report a config error and stop. 2. Collect evidence once, not per feature:
- subjects of merges made on base: `git log --first-parent <base> --merges --format=%s`
- first-parent line of base: `git rev-list --first-parent <base>`
- `YOLO-Feature` trailers on base, and `yolo/done/*` tags
- live branches: `git for-each-ref --format='%(refname:short)' refs/heads/feature/`
3. For each `workspace/features/*/brief.md` (slug = folder name), classify in order: cancelled → landed → verified → in-progress → planned. Use the slug-boundary match for merge subjects so `csv` never matches `csv-export`. 4. Add an **untracked-branch** row for every `feature/<slug>` with no brief. 5. For `planned`/`in-progress` rows whose brief has `depends_on`, mark any dependency that hasn't landed as `blocked-by: <slug>`. 6. Print a compact table: slug · status · milestone · blocked-by · last commit date on the branch (in-progress only). Group by `milestone` when set. End with one line naming the most recently touched in-progress branch.
Constraints
- Read-only. Compute, never store.
Ships withyolo
A thin state layer for agent-driven feature work. A feature is a short brief plus a git branch, and its status is derived from git every time you ask. Nothing is stored, so nothing drifts. YOLO doesn't tell your agent how to plan, build or review.
95 skills
Stars on GitHub
Momentum
- stars in total
- 9
Other skills on yolo.
More skills from other plugins.
Auto-invoked
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
@obraInstall Skillask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
@mattpocockInstall SkillAuto-invoked
Questions about yolo-status.
- Which coding agents can use yolo-status?
- yolo-status installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.