yolo-roadmap

스타9

포크0

업데이트2026년 7월 2일 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".

설치

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

출처

CoriChui

CoriChui/yolo

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

다운로드

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.

이 저장소의 다른 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

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.