Spawn a teammate to challenge your design proposal using the decision-clarity skill's Socratic questioning methodology. Use when you have a design proposal, architecture decision, prompt design, or implementation plan that needs rigorous review before committing. Also use when the user says "review this design", "challenge my proposal", "poke holes in this", "is this the right approach", "let's discuss this with a teammate", or "team review".
Spawn a teammate who uses the decision-clarity skill to challenge your design proposals through structured Socratic questioning.
You (the lead) have a proposal. You spawn a teammate (the questioner).
The questioner invokes the /decision-clarity skill to load the
Clarify / Deconstruct / Simplify / Decide methodology, then uses it
to challenge your proposal across multiple rounds. You answer, revise,
and iterate until no gaps remain.
The questioner's questioning methodology comes entirely from the decision-clarity skill. This skill only teaches how to set up the team and run the review process.
Before spawning the team, write down:
TeamCreate: team_name="decision-review"
Agent:
name: "questioner"
team_name: "decision-review"
subagent_type: "general-purpose"
The questioner's prompt must include:
Example questioner prompt:
You are a Socratic questioner reviewing a design proposal.
PHASE 1: Read these files thoroughly before asking anything:
- [list specific file paths here]
PHASE 2: Invoke the decision-clarity skill (/decision-clarity).
Use its Clarify/Deconstruct/Simplify/Decide methodology to
structure your questions.
PHASE 3: Challenge the proposal through multiple rounds.
Rules:
- ONLY ask questions, never propose solutions.
- Each round: 2-3 focused questions.
- Reference specific code (file:line) when relevant.
- Track what's been answered. Never repeat a question.
- When no more gaps exist, say: "I have no further questions."
- Send all questions via SendMessage to "team-lead".
After reading all files, send: "Phase 1 complete. Ready for
proposal." Then wait.
After the review:
These failure modes were observed in real sessions:
Repeating answered questions -- questioner re-asks what was already addressed. The questioner must track answered questions.
Abstract questions without code references -- "Is this robust?" is useless. "Line 482 overwrites grader_items in the loop -- does this lose inner_0 data?" is useful.
Skipping Phase 1 (file reading) -- questioning without understanding the codebase produces surface-level questions. Phase 1 is mandatory.
Proposing solutions -- the questioner's job is to find gaps, not fill them. Redirect if it starts saying "you should..."
Endless inquiry -- each round should make progress. If a round reveals nothing new, the review is done.
Lead not conceding -- when a question reveals a real gap, acknowledge it and revise. Don't defend a flawed proposal.