Pre-spec Socratic ideation skill that surfaces constraints, risks, and trade-offs through structured dialogue before committing to a direction.
From workflow-orchestrationnpx claudepluginhub mikecubed/agent-orchestration --plugin workflow-orchestrationThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Use this skill when a developer has a rough idea but is not yet ready for formal specification. This is pre-spec ideation — it sits before sdd.specify in the workflow and is distinct from planning-orchestration:
brainstorm-ideation: surfaces constraints, trade-offs, and risks BEFORE the developer knows what to build.planning-orchestration: structures work for something already decided.sdd.specify: formalizes requirements for something ready to spec.The skill drives a Socratic dialogue to help the developer clarify intent, discover hidden constraints, weigh competing approaches, and converge on a direction — then hands off to sdd.specify with a durable ideation brief.
Persistent team, squad, or fleet-style long-lived orchestration is out of scope for this skill. Use a separate orchestration layer if persistent coordination is needed.
Activate when the developer asks for things like:
Use this skill when:
sdd.specify — to clarify what they actually want to build;Do not use this skill when:
sdd.specify directly;planning-orchestration or parallel-implementation-loop;Before you start, identify:
sdd-workflow is available in the current runtime;Use separate roles for:
All roles receive the discovery output as a factual context brief — file lists, domain boundaries, validation commands, and known dependencies. Do not pass one role's conclusions or assessments to another; the reviewer must form an independent judgment from the ideation brief artifact itself.
Resolve the active model for each role using this priority chain:
.copilot/models.yaml.claude/models.yamlimplementer: <model-name>
reviewer: <model-name>
scout: <model-name>
See docs/models-config-template.md for ready-to-copy runtime templates.
| Runtime | Role | Default model |
|---|---|---|
| Copilot CLI | Implementer | claude-opus-4.6 |
| Copilot CLI | Reviewer | gpt-5.4 |
| Copilot CLI | Scout | claude-haiku-4.5 |
| Claude Code | Implementer | claude-opus-4.6 |
| Claude Code | Reviewer | claude-opus-4.6 |
| Claude Code | Scout | claude-haiku-4.5 |
Before starting the Socratic dialogue, run one lightweight discovery pass using the scout model.
The scout MUST produce a short factual brief covering:
Use the discovery brief template from docs/workflow-artifact-templates.md.
Skip condition: Skip discovery only when the developer provides enough context directly. If skipped, record the skip reason.
Drive a structured Socratic dialogue with the developer. Each round asks ≤5 questions — never more. Batch related questions together.
Ask open questions to capture the core intent. Focus on what problem the developer is trying to solve and who the users or consumers are. Limit to 1–3 questions in this round.
Probe for constraints the developer may not have articulated:
Present 2–3 competing approaches with explicit trade-offs for each. Structure each approach as:
Surface the top 3 risks the developer may not have considered. For each risk:
Summarize the ideation dialogue into a convergence summary:
Ask the developer: "Are you ready to hand off to sdd.specify?"
If yes → produce the durable ideation brief and recommend invoking sdd.specify.
If no → return to the relevant Socratic step for further exploration.
At the end of the dialogue, produce a durable ideation brief artifact containing:
/sdd-workflow:sdd.specify with this brief as context.The brief MUST use a repository-appropriate durable sink — for example, a committed document, PR description, issue comment, or task tracker entry.
Before writing SESSION.md and handing off, have the reviewer role inspect the
produced ideation brief independently. Pass the reviewer only the brief artifact — do not
pass the dialogue history or the implementer's working notes.
The reviewer checks:
If the reviewer finds a gap: return the brief to the implementer with the specific issue. The implementer revises and the reviewer re-inspects. Allow at most 1 resend attempt. If the gap is still unresolved after one resend, escalate to the developer and continue.
Once the reviewer approves (or escalation is accepted), proceed to the SESSION.md write.
At this gate (after the ideation brief is reviewed), write .agent/SESSION.md with the
current session state using the canonical schema (docs/session-md-schema.md). Record:
current-task: the overall ideation topiccurrent-phase: "ideation-complete"next-action: "invoke sdd.specify with ideation brief" (or as decided with the developer)workspace: the active branch or PR referencelast-updated: current ISO-8601 datetime## Decisions: key decisions made during ideation (approach chosen, constraints confirmed)## Files Touched: files read during discovery## Open Questions: unresolved questions for the developer## Blockers: active blockers (empty if none)## Failed Hypotheses: approaches considered and rejected, with reasonsIf the write fails (permission error, no .agent/ directory): log a warning and continue.
The write must not block the skill's primary workflow.
When the ideation brief is complete, recommend the next workflow explicitly:
/sdd-workflow:sdd.specify — the most common next step;/workflow-orchestration:planning-orchestration — if the developer wants to plan before specifying;An ideation session is not complete until:
Before marking the ideation session complete, confirm ALL of the following.
If any item is FAIL: surface the gap and return to the relevant Socratic step. Do not mark the ideation as accepted.
sdd.specify directly;Before stopping because a dialogue stalled, always attempt rescue first: narrow the scope of exploration, reduce the number of open questions, or focus on the single most promising approach. Produce a partial durable ideation brief summary capturing whatever was learned, even if incomplete.
Core intent:
Add real-time collaboration to the document editor so multiple users can
edit the same document simultaneously without conflicts.
Key constraints:
- Must work with existing REST API (no full rewrite)
- Target latency < 200ms for cursor sync
- Team of 2 engineers, 3-week timeline
- Must not break offline editing support
Approaches considered:
1. OT (Operational Transform)
Pros: battle-tested, well-documented
Cons: complex server logic, hard to debug
Risk: implementation complexity exceeds timeline
2. CRDT (Conflict-free Replicated Data Types)
Pros: simpler merge semantics, offline-friendly
Cons: larger payloads, fewer production references
Risk: performance at scale is unproven for this use case
3. Lock-based editing with live cursors
Pros: simplest to implement, low risk
Cons: poor UX for true simultaneous editing
Risk: users reject the experience
Top risks:
1. Timeline risk — OT/CRDT may exceed 3-week budget (high)
Mitigation: prototype the hardest merge case in week 1
2. Compatibility risk — offline editing may conflict with sync model (medium)
Mitigation: map offline editing flows before choosing approach
3. Performance risk — cursor sync latency target is aggressive (medium)
Mitigation: benchmark WebSocket round-trip in staging environment
Recommended next step:
Invoke /sdd-workflow:sdd.specify with this brief as context, focusing on
the CRDT approach with a week-1 prototype gate.
Unresolved questions:
- Is WebSocket infrastructure already available in production?
- What is the maximum concurrent editor count to support?