yolo-research

Stars9

Forks0

UpdatedJuly 7, 2026 at 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.

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

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