yolo

name	yolo
description	Use when the user wants to go from a feature description to an open PR in one uninterrupted flow, asks to yolo a change, says do it all, or requests a single-shot create-implement-PR workflow.
argument-hint	[feature description]

Yolo — Single-Shot Feature Delivery

Overview

Run the full feature delivery chain — Linear issue creation, implementation, and PR raising — in one invocation. Each phase runs the corresponding skill workflow in full. All quality gates from implementing-linear-issue are preserved. The flow stops after the PR is raised; it does not merge or close the issue.

When to Use

• User says "yolo this", "single shot", "do it all", "full flow", or any equivalent shorthand for the uninterrupted create-implement-PR chain.
• User explicitly asks to go from a feature description to an open PR without manual skill hand-offs.

Do not use when:

• The issue already exists — start from implementing-linear-issue directly.
• Implementation is already done — use raising-linear-pr directly.
• The user only wants a ticket — use creating-linear-issue.

Quick Reference

Phase	Skill workflow	Done when
1 — Create Issue	creating-linear-issue	Issue created and confirmed
2 — Implement	implementing-linear-issue	Final commit, clean worktree
3 — Raise PR	raising-linear-pr	PR open, issue In Review

Implementation

Phase 1 — Create Issue

Run the full creating-linear-issue workflow exactly as specified in that skill.

Classify, dedupe, resolve all four critical fields, confirm with the user, enter plan mode, and create the issue after approval. All rules from creating-linear-issue apply without exception.

On success emit: ✅ Issue created (AD-N) — proceeding to implementation.

On failure: Report the exact failure. Nothing has been created; no recovery action is needed. Do not proceed to Phase 2.

---

Phase 2 — Implement

Run the full implementing-linear-issue workflow exactly as specified in that skill, using the issue created in Phase 1.

Create the branch and worktree, plan the implementation, implement in reviewable slices with checkpoint commits, run all required quality gates (code review, simplification review, test coverage review, AC review), update Linear, and create the final implementation commit. All rules from implementing-linear-issue apply without exception. Do not push. Do not create a PR.

On success emit: ✅ Implementation complete — proceeding to PR.

On failure after Phase 1 succeeded: Surface the exact failure and provide this recovery instruction:

Resume with /engineering-skills:implementing-linear-issue <issue-id>

Do not proceed to Phase 3.

---

Phase 3 — Raise PR

Run the full raising-linear-pr workflow exactly as specified in that skill.

Rebase onto the default branch, run post-rebase quality gates, push, create the PR with issue-linking, and move the issue to In Review. All rules from raising-linear-pr apply without exception.

On success emit: ✅ PR raised — awaiting review.

On failure after Phase 2 succeeded: Surface the exact failure and provide this recovery instruction:

Resume with /engineering-skills:raising-linear-pr

---

Stop Condition

Stop after Phase 3. Do not merge. Do not close the issue. Do not run closing-linear-issue.

The next step is human: review and approve the PR, then run /engineering-skills:closing-linear-issue after merge.