From yolo
Unified discussion protocol for phase discovery and context gathering. Handles calibration, gray area generation, conversational exploration, and structured capture.
How this skill is triggered — by the user, by Claude, or both
Slash command
/yolo:discussion-engineThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
One engine. Three entry points. Claude thinks, not pattern-matches.
One engine. Three entry points. Claude thinks, not pattern-matches.
Replaces the three competing discussion subsystems (Bootstrap Discovery, Phase Discovery, Phase Discussion) with a single unified protocol. The user is the visionary. Claude is the builder. The engine's job is to surface decisions that downstream agents (researcher, planner, executor) need to act without asking the user again.
All resolve to this protocol:
/yolo:vibe — auto-detects discussion need from state/yolo:vibe --discuss [N] — explicit flag, targets phase N/yolo:discuss [N] — standalone commandRead conversation signals to determine user sophistication. This is NOT a question — it is inference from:
/yolo:discuss vs /yolo:vibeTwo modes, silently selected:
| Mode | Signals | Question style | Depth |
|---|---|---|---|
| Builder | Plain language, vibe keywords, prototype/yolo profile | Scenario-based, no jargon, cause-and-effect | Concrete situations |
| Architect | Technical terms, specific requirements, production profile | Direct, uses domain terms, trade-off framing | Design decisions |
Same gray area, two modes:
Builder: "When someone's internet drops while they're writing a post, what should happen?"
Architect: "Offline write strategy for post creation?"
Read the phase goal from ROADMAP.md and think about what gray areas exist. No keyword matching. No predefined templates. Pure analysis.
The engine asks itself:
"What decisions about this phase could go multiple ways and would change what gets built?"
Generate phase-specific gray areas. These must be concrete, not categorical.
Bad (generic): "UI decisions", "Data handling", "Error states" Good (phase-specific): For "Recipe recommendation engine": "How recommendations are surfaced (feed vs search vs suggestions)", "Cold-start behavior (new user with no history)", "Dietary restriction handling (strict filter vs soft preference)"
For bootstrap context (no phases yet): generate gray areas from the project description and domain research (if available).
Profile depth controls gray area count:
| Profile | Gray Areas |
|---|---|
| prototype | 2-3 |
| default | 3-5 |
| production | 4-6 |
Present gray areas as a multi-select using AskUserQuestion: "Which areas should we discuss?" No "skip all" option — if the user ran discuss, give them real choices.
For each selected area, have a natural conversation. Not a form. Not a fixed number of questions.
The rhythm:
Scope awareness (simple, not a subsystem): If the user mentions something outside the phase boundary:
"[Feature] sounds like its own phase. I'll note it. Back to [current area]..." One line. Captured in Deferred Ideas. No feature extraction pipeline.
Vague answer handling (natural, not mechanical): If the user says something vague like "I want it to be fast", just ask a follow-up:
"Fast in what way — page loads, search results, or handling lots of users at once?" No disambiguation subsystem. Just good conversation.
Write {phase}-CONTEXT.md to the phase directory:
# Phase N: Name — Context
Gathered: YYYY-MM-DD
Calibration: builder | architect
## Phase Boundary
[What this phase delivers — scope anchor from ROADMAP.md]
## Decisions
### [Gray Area 1]
- [Decision or preference]
- [Follow-up detail if captured]
### [Gray Area 2]
- [Decision or preference]
### Open (Claude's discretion)
[Areas where user said "you decide" or was indifferent]
## Deferred Ideas
[Out-of-scope ideas captured during discussion. Empty if none.]
Also append to discovery.json using this schema:
{
"answered": [
{
"question": "How should recommendations be surfaced?",
"answer": "Inline suggestions in the feed, not a separate page",
"area": "recommendation-surfacing",
"phase": "bootstrap | 03",
"date": "YYYY-MM-DD"
}
],
"inferred": [
{
"id": "REQ-01",
"text": "Recommendations appear inline in the main feed",
"priority": "Must-have",
"source": "Discussion: recommendation surfacing"
}
],
"deferred": [
{
"idea": "Social sharing of recommendations",
"mentioned_during": "Phase 3 discussion",
"date": "YYYY-MM-DD"
}
]
}
| Config | Effect |
|---|---|
active_profile=yolo | Skip discussion entirely |
active_profile=prototype | 2-3 gray areas, quick explore |
active_profile=default | 3-5 gray areas, standard depth |
active_profile=production | 4-6 gray areas, thorough explore |
discovery_questions=false | Skip discussion entirely |
npx claudepluginhub slavpetroff/yolo --plugin yoloDiscusses planning phases to identify ambiguities, capture decisions in CONTEXT.md, and lock them before plan generation. Supports phase numbers or --project mode.
Identifies gray areas in tasks (UI layouts, API formats, CLI flags), collects user decisions via multiple-choice questions, generates CONTEXT.md for downstream agents.
Leads Socratic discussions to clarify ideas, challenge assumptions, and surface blind spots before implementation. Activates on '/discuss' or phrases like 'discuss this'.