| name | one-shot |
| description | Small-scope plan+implement in one session. Assess the prompt, optionally one bundled round of questions, maintain a lightweight yolo plan while implementing, verify, quick code review, commit. Use when the user invokes /one-shot, or asks to "just build/fix/add" something small without the full create-plan → implement-plan pipeline. Small means ≤ ~3 phases inside one subsystem — anything bigger escalates to /desplega:create-plan. |
One-Shot
Plan and implement a small task in a single session. This is the lightweight sibling of the create-plan → implement-plan pipeline: same discipline (written plan, verification, code review), a fraction of the ceremony.
Scope gate (HARD rule)
One-shot is for small work only: at most ~3 phases, one subsystem. Check this at every stage — assessment, planning, and mid-implementation. The moment the work reveals more phases or a second subsystem, STOP:
- Tell the user what grew and why.
- Hand off to
/desplega:create-plan, passing the yolo plan (whatever exists of it) as input context.
Grinding on past the gate is how one-shots turn into unreviewable mega-diffs. Escalating is success, not failure.
Step 1: Assess ceremony
Read the prompt and decide dynamically:
- Clear enough (goal unambiguous, approach obvious, no real trade-offs) → GO. No questions.
- Not clear → one lowkey grill: a single bundled
AskUserQuestion call with 2–3 decisions max, every question shipping a recommended answer (per desplega:ask-user conventions). Facts-vs-decisions rule applies (as in desplega:brainstorming): look up facts yourself — via quick background sub-agents routed per desplega:delegate-work — and only bring genuine decisions to the user. One round only; if the answers reveal a swamp, that's the scope gate firing.
Step 2: Yolo plan — written as you go
Create thoughts/<username|shared>/plans-yolo/YYYY-MM-DD-<slug>.md (user's name when known, else shared) before implementing, then keep it current while you work — it is a running log, not an upfront artifact:
---
date: YYYY-MM-DDTHH:MM:SSZ
topic: "<Task>"
status: in-progress # in-progress | done | escalated
---
# <Task>
## Goal
One paragraph: what exists when this is done.
## Decisions
- <decision> — <one-line reason> (asked | assumed)
## Todo
- [ ] <step>
- [ ] <step>
## Verification
- `<runnable command>` (typecheck, tests, lint — whatever proves it works)
Check off todos as you complete them; append decisions the moment you make them. If the session dies, the file is the handoff.
Design docs: if a design doc exists for the touched system (thoughts/*/design-docs/<system-slug>.md), read it and abide — don't violate its Invariants or Boundaries; flag conflicts to the user instead of coding around them (see desplega:design-docs).
Step 3: Implement
Work the todo list. Route any spawned sub-agents per desplega:delegate-work; hold code to the desplega:engineering-standards bar. Keep the plan file in sync as you go.
Step 4: Verify
Run every command in the Verification section. All must pass. Fix and re-run — never report done with a failing check.
Step 5: Quick code review
Run desplega:code-reviewing on the diff. Spec sources: the yolo plan plus any design doc for the touched system — pass both to the Spec agent; the doc's Invariants bind even when the yolo plan doesn't restate them. Fix Critical and Important findings, note Minor ones in the plan file.
Step 6: Commit
Commit with a concise message referencing the change (only if the user hasn't said they handle commits themselves). Then report: what shipped, verification results, review outcome, path to the yolo plan.
