yolo-status

스타9

포크0

업데이트2026년 7월 2일 17:28

Use when the user asks where things stand, what's in progress, or "where was I". Computes a derived view of every feature's status from git and the briefs — nothing is read from a stored status field.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

CoriChui

CoriChui/yolo

GitHub 저장소 열기 Creator 저장소 보기

다운로드

yolo-status

Report the state of all features by DERIVING it from git (.claude/yolo/conventions.md). There is no stored status field — do not look for one.

Procedure

Resolve base_branch (workspace/config.yaml project.base_branch, else the detection rule in .claude/yolo/conventions.md). Guard every ref with git rev-parse --verify -q before using it; if base_branch does not resolve, report a config error and stop. If workspace/config.yaml is absent, use the config-absent fallback from conventions.
Enumerate live branches once — git for-each-ref --format='%(refname:short)' refs/heads/feature/ — so a feature/<slug> with no brief is surfaced as an untracked-branch row, not silently dropped.
For each workspace/features/*/brief.md, take <slug> from the folder. A brief with front-matter cancelled: true is reported as cancelled and otherwise skipped. Else derive status exactly per .claude/yolo/conventions.md Deriving status, in order:
- done — ANY of (first match wins): tag yolo/done/<slug> exists, OR base history carries a YOLO-Feature: <slug> trailer (both durable — survive branch deletion/squash), OR (branch still present) its tip carries YOLO-Verified: true with a committed verification.md. This is what makes a shipped-and-deleted branch read as done, not planned. (git branch --merged is intentionally not used — it false-positives an empty freshly-cut branch.)
- in-progress — feature/<slug> exists and is not done. Completed tasks (advisory, deduped): git log <base>..feature/<slug> --format='%(trailers:key=YOLO-Task,valueonly)' | sed '/^$/d' | sort -u (count vs the task total in plan.md — progress only, never the done test).
- planned — brief exists, no done-evidence, and feature/<slug> does not exist.
Group rows by the brief's milestone: value when set. For planned/in-progress rows whose brief lists depends_on, flag any dependency not yet done as blocked-by: <slug>.
Print a compact table: slug · status · tasks(done/total, for in-progress) · milestone · blocked-by. Add a one-line resume hint from the most recent in-progress branch's last commit subject (e.g. "resume with yolo-feature ").

Constraints

Read-only. Compute, never store. This view cannot be stale because it is recomputed each call.

이 저장소의 다른 Skills

같은 저장소

yolo-feature

CoriChui/yolo

Use when the user wants to build, add, or implement a feature. Captures intent, drafts a brief, confirms, then composes research → plan → execute → verify → finish. In a YOLO-initialized repo this takes precedence over generic brainstorming for feature intent.

2026-07-079

yolo-decide

CoriChui/yolo

Use when facing a design or architecture decision that benefits from multiple perspectives before committing. Produces a decision record under workspace/decisions/. Triggers on "help me decide X vs Y", "which approach", "should we use A or B".

2026-07-079

yolo-init

CoriChui/yolo

Use when setting up YOLO in a project for the first time, or repairing the setup. Scaffolds workspace/config.yaml and the features/, decisions/, and debug/ dirs (plus docs/ for the docs engine), and installs the CLAUDE.md routing block. Triggers on "set up YOLO here", "init yolo", "yolo init".

2026-07-079

yolo-intake

CoriChui/yolo

Use when a feature should draw on the project's reference material for context. yolo-intake does NOT fetch, import, or copy anything — it points YOLO at a selected folder (default `docs/`) and READS from it to enrich a feature's context. Getting material INTO that folder (a Figma, a spec, a URL, a schema) is the docs engine's or another connector's job, done separately. Triggers on "use the docs as context", "reference the spec/schema in docs", "the feature should read our docs".

2026-07-079

yolo-research

CoriChui/yolo

Use before planning a YOLO change, to understand the codebase and any cited intake before a plan is written. Read-only exploration that produces context for yolo-plan. Triggers on "understand how X works", "explore the code before we change it", or as the research step of yolo-feature.

2026-07-079

yolo-debug

CoriChui/yolo

Use when a reported problem, failure, or bug needs a systematic root-cause investigation — reproduce → isolate → fix → verify — recorded as one durable artifact. Triggers on "fix the 500 on login", "X is broken", "why is Y failing?", "debug this", "track down this bug".

2026-07-029

yolo-status

Report the state of all features by DERIVING it from git (.claude/yolo/conventions.md). There is no stored status field — do not look for one.

Procedure

Resolve base_branch (workspace/config.yaml project.base_branch, else the detection rule in .claude/yolo/conventions.md). Guard every ref with git rev-parse --verify -q before using it; if base_branch does not resolve, report a config error and stop. If workspace/config.yaml is absent, use the config-absent fallback from conventions.

Enumerate live branches once — git for-each-ref --format='%(refname:short)' refs/heads/feature/ — so a feature/<slug> with no brief is surfaced as an untracked-branch row, not silently dropped.

For each workspace/features/*/brief.md, take <slug> from the folder. A brief with front-matter cancelled: true is reported as cancelled and otherwise skipped. Else derive status exactly per .claude/yolo/conventions.md Deriving status, in order:

done — ANY of (first match wins): tag yolo/done/<slug> exists, OR base history carries a YOLO-Feature: <slug> trailer (both durable — survive branch deletion/squash), OR (branch still present) its tip carries YOLO-Verified: true with a committed verification.md. This is what makes a shipped-and-deleted branch read as done, not planned. (git branch --merged is intentionally not used — it false-positives an empty freshly-cut branch.)
in-progress — feature/<slug> exists and is not done. Completed tasks (advisory, deduped): git log <base>..feature/<slug> --format='%(trailers:key=YOLO-Task,valueonly)' | sed '/^$/d' | sort -u (count vs the task total in plan.md — progress only, never the done test).
planned — brief exists, no done-evidence, and feature/<slug> does not exist.

Group rows by the brief's milestone: value when set. For planned/in-progress rows whose brief lists depends_on, flag any dependency not yet done as blocked-by: <slug>.

Print a compact table: slug · status · tasks(done/total, for in-progress) · milestone · blocked-by. Add a one-line resume hint from the most recent in-progress branch's last commit subject (e.g. "resume with yolo-feature ").

Constraints

Read-only. Compute, never store. This view cannot be stale because it is recomputed each call.

name	yolo-status
description	Use when the user asks where things stand, what's in progress, or "where was I". Computes a derived view of every feature's status from git and the briefs — nothing is read from a stored status field.