yolo-research

Estrellas9

Forks0

Actualizado7 de julio de 2026 a las 06:10

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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

CoriChui

CoriChui/yolo

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	yolo-research
description	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.

yolo-research

Read-only exploration. You gather the context a plan needs; you change nothing.

Inputs

A brief (workspace/features/<slug>/brief.md) — read goal, success_criteria, intake_refs. Or, when invoked standalone, a plain question.

Procedure

Identify the relevant surface: Glob/Grep for the entities, modules, and routes named in the goal.
Read the key files. Capture concrete file:line references — never vague summaries.
If the brief lists intake_refs, read those files from the intake folder (intake.folder, default docs/) — search the docs engine first. Do not fetch live sources for intake; if referenced context is missing from the folder, surface the gap (a docs-engine / connector step must add it first).
Note: existing patterns/conventions to follow, integration points, risks, and any open questions that would block planning.

Output

Write a concise note to workspace/features/<slug>/research.md (or return it inline when standalone) and commit it (yolo: research <slug>). Sections: Findings (with file:line), Patterns, Integration points, Risks, Open questions. Keep it tight — this feeds yolo-plan, not a human report.

Constraints

Read-only: never edit code, never run mutating commands.
No status files. You do not set or read any feature "status" — that is derived from git (.claude/yolo/conventions.md).
Cite file:line; do not invent APIs.

Más de este repositorio

mismo repositorio

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-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-finish

CoriChui/yolo

Use when a feature is implemented and verified, to land it. Default path is PR + CI check, with the ship gate confirming before the irreversible merge; fast-local is the escape hatch. Includes the risk classifier whose hard triggers always stop for a human. Triggers on "ship it", "land this", "open a PR", or as the finish step of yolo-feature.

2026-07-029

name	yolo-research
description	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.

yolo-research

Read-only exploration. You gather the context a plan needs; you change nothing.

Inputs

A brief (workspace/features/<slug>/brief.md) — read goal, success_criteria, intake_refs. Or, when invoked standalone, a plain question.

Procedure

Identify the relevant surface: Glob/Grep for the entities, modules, and routes named in the goal.
Read the key files. Capture concrete file:line references — never vague summaries.
If the brief lists intake_refs, read those files from the intake folder (intake.folder, default docs/) — search the docs engine first. Do not fetch live sources for intake; if referenced context is missing from the folder, surface the gap (a docs-engine / connector step must add it first).
Note: existing patterns/conventions to follow, integration points, risks, and any open questions that would block planning.

Output

Constraints

Read-only: never edit code, never run mutating commands.
No status files. You do not set or read any feature "status" — that is derived from git (.claude/yolo/conventions.md).
Cite file:line; do not invent APIs.