yolo-roadmap

النجوم٩

التفرعات٠

آخر تحديث٢ يوليو ٢٠٢٦ في ١٧:٢٨

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 عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·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.

المزيد من هذا المستودع

نفس المستودع

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.