yolo-roadmap

Stars9

Forks0

UpdatedJuly 2, 2026 at 17:28

Use when the user has a large or fuzzy goal that should be decomposed into several features. Produces N feature briefs (optionally sharing a milestone label) — a one-time act that returns briefs, not a container. Triggers on "break this epic into features", "plan a milestone", "decompose this".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

CoriChui

CoriChui/yolo

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	yolo-roadmap
description	Use when the user has a large or fuzzy goal that should be decomposed into several features. Produces N feature briefs (optionally sharing a milestone label) — a one-time act that returns briefs, not a container. Triggers on "break this epic into features", "plan a milestone", "decompose this".

yolo-roadmap

Turn one big goal into several atomic feature briefs. There is no "release" container — just briefs, optionally tagged with a shared milestone.

Procedure

Clarify the big goal and its boundary (what's out of scope). Optionally invoke yolo-research for codebase context.
Decompose into independent features, each shippable on its own. Note any cross-feature depends_on (honored by the model; there is no DAG machine).
For each feature, draft workspace/features/<slug>/brief.md from .claude/yolo/templates/brief.md — set goal, success_criteria, and a shared milestone: value if they ship as a set.
Present the proposed feature list for approval BEFORE creating the briefs — the plan-gate analogue for a roadmap; no billed code work happens here (.claude/yolo/conventions.md The two gates). Skip only if the user pre-consented.
On approval, write and commit each brief (yolo: brief <slug>). Each is later picked up by yolo-feature.

Constraints

You only create briefs (status "planned"). You do not branch, plan, or execute — that is yolo-feature, per feature.
No container, no lifecycle, no status field. Grouping is the milestone: label only.
Run decomposition/analysis at the agents.roadmap tier from workspace/config.yaml.

More from this repository

same repository

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

name	yolo-roadmap
description	Use when the user has a large or fuzzy goal that should be decomposed into several features. Produces N feature briefs (optionally sharing a milestone label) — a one-time act that returns briefs, not a container. Triggers on "break this epic into features", "plan a milestone", "decompose this".

yolo-roadmap

Turn one big goal into several atomic feature briefs. There is no "release" container — just briefs, optionally tagged with a shared milestone.

Procedure

Clarify the big goal and its boundary (what's out of scope). Optionally invoke yolo-research for codebase context.
Decompose into independent features, each shippable on its own. Note any cross-feature depends_on (honored by the model; there is no DAG machine).
For each feature, draft workspace/features/<slug>/brief.md from .claude/yolo/templates/brief.md — set goal, success_criteria, and a shared milestone: value if they ship as a set.
Present the proposed feature list for approval BEFORE creating the briefs — the plan-gate analogue for a roadmap; no billed code work happens here (.claude/yolo/conventions.md The two gates). Skip only if the user pre-consented.
On approval, write and commit each brief (yolo: brief <slug>). Each is later picked up by yolo-feature.

Constraints

You only create briefs (status "planned"). You do not branch, plan, or execute — that is yolo-feature, per feature.
No container, no lifecycle, no status field. Grouping is the milestone: label only.
Run decomposition/analysis at the agents.roadmap tier from workspace/config.yaml.