yolo
Health Uyari
- License — License: MIT
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Low visibility — Only 9 GitHub stars
Code Basarisiz
- rm -rf — Recursive force deletion command in .claude/settings.json
- rm -rf — Recursive force deletion command in docs/validation/git-acceptance/run.sh
Permissions Gecti
- Permissions — No dangerous permissions requested
Bu listing icin henuz AI raporu yok.
YOLO — a reasoning-first, feature-aware workflow framework for Claude Code. Git is the source of truth; status is derived, never stored.
YOLO
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. Use whatever you already use
for that (plan mode, subagents, code review, your own habits). YOLO only answers two
questions reliably: what are we building, and where does each thing stand.
How it works
workspace/features/<slug>/brief.mdholds the goal and checkable success criteria.feature/<slug>is the branch the work happens on.yolo-verifychecks the branch against the criteria and commits the evidence with aYOLO-Verified: truetrailer.- Merging the branch is what lands it. Plain merges, GitHub PR merges and GitLab merges are
all detected from history, with or without the branch deleted.
Status, first match wins:
| Status | Meaning |
|---|---|
| landed | the branch was merged into base |
| verified | the branch tip passed yolo-verify and hasn't been merged yet |
| in-progress | the branch exists |
| planned | there's a brief but no branch yet |
| cancelled | the brief has cancelled: true |
Squash and fast-forward merges don't leave a merge commit naming the branch. If you merge
that way, put YOLO-Feature: <slug> as the last paragraph of the commit message.
The exact rules are in conventions.md.
Skills
| Skill | Use it to |
|---|---|
yolo-brief |
record a feature (goal + success criteria), or cancel one |
yolo-status |
see where every feature stands |
yolo-next |
get the top 3 things to work on next, with reasons |
yolo-verify |
check a branch against its brief and record the result |
yolo-init |
set up workspace/ in a repo |
Install
/plugin marketplace add CoriChui/yolo
/plugin install yolo@yolo
Then say "set up YOLO here" in the repo.
A feature, start to finish
you: (optional) design it first; save the approved spec as
workspace/features/csv-export/spec.md
you: track CSV export for the reports page as a feature
yolo: writes brief.md, criteria taken from the spec -> planned
prints the branch command and a ready /goal line
you: git switch -c feature/csv-export main -> in-progress
...plan and build however you like, or paste the /goal line
so the session keeps working until verification passes...
you: verify csv-export
yolo: runs tests, checks each criterion, commits evidence -> verified
you: merge the PR -> landed
A brief's refs field links its spec, plan or ticket. Keeping spec.md and plan.md
next to the brief keeps a feature's files together; YOLO itself only reads the brief.
Upgrading from 0.4
0.5 drops the workflow: the feature/plan/research/finish skills, the two gates, task
trailers, decisions, debug records, intake and the routing block. Old repos keep working.yolo/done/<slug> tags and YOLO-Feature trailers still count as landed, and leftoverplan.md, research.md and YOLO-Task trailers are simply ignored.
Tests
bash docs/validation/git-acceptance/run.sh
Builds throwaway repos and checks every status rule against real git, including the edge
cases that broke earlier versions.
License
MIT
Yorumlar (0)
Yorum birakmak icin giris yap.
Yorum birakSonuc bulunamadi