القائمة
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".
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | yolo-decide |
| description | 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". |
Reach a defensible decision via multi-perspective analysis, and record it.
agents.decide tier. Confirm the decision framing before launching it — the plan-gate analogue for a decision (.claude/yolo/conventions.md The two gates). STOP and wait for the human here (state the framing, then pause) — do not state the framing and slide into the analysis in the same turn. Skip only if the user pre-consented.workspace/decisions/<slug>.md with: decision, rationale, approach, alternatives_considered, dissents, revisit_triggers, confidence. Confirm before overwriting an existing slug.yolo: decision <slug>).bakeoff insteadyolo-decide is a single-pass, multi-lens analysis — right for most X-vs-Y calls. For a high-stakes,
hard-to-reverse decision with several defensible options (architecture, migration, tool selection), the
bakeoff skill runs a heavier judged tournament: it generates
diverse candidate solutions, auto-derives a rubric for the problem, scores each with independent judges,
and adversarially refutes the leader. If bakeoff is installed, offer it for those cases, then record its
verdict as the decision here (workspace/decisions/<slug>.md) so the trail stays in one place.
agents.decide tier from workspace/config.yaml.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.
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".
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".
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.
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".
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.