---
name: workflow-ideation
description: Evaluate whether an idea is worth implementing by asking structured questions about outcomes, alignment, and opportunity cost. Stage 1 of the development workflow.
argument-hint: "[idea description]"
user-invocable: true
---
Evaluate whether to proceed with implementing: $ARGUMENTS
## Purpose
You are executing Stage 1 (Ideation) of the development workflow. Your job is to determine whether this idea is worth the engineering investment by asking four structured questions. You do NOT write code, specs, or ADRs — you produce a decision.
## Process
### Step 1: Gather Context
Before asking the questions, gather existing context that might already contain answers:
1. **Check accepted ADRs** for prior decisions in this domain:
```bash
ls .adr/accepted/ 2>/dev/null
```
Read any ADRs that relate to the idea's domain. Note whether their reasoning still holds.
2. **Check compound learnings** for prior experience:
Search for relevant learnings in knowledge stores, agent memory, and previous reflections.
Present a brief summary of what you found before proceeding to the questions.
### Step 2: Ask the Four Questions
Work through these questions with the user. For each question, present your analysis based on the context gathered, then ask the user to confirm, revise, or expand.
#### Q1: Desired Outcomes
> What outcomes are we striving to achieve by implementing this idea? What outcome is this idea "proposed instrumentation" for achieving?
Present your understanding of what the user hopes to accomplish. Be specific — "improve performance" is not an outcome; "reduce API response time from 2s to 200ms for the /search endpoint" is.
#### Q2: Realistic Outcomes
> What outcomes can we reasonably determine we will ACTUALLY get if we implement this? From reading the code, design docs, and any research: what can we say with 90-95% confidence WILL happen?
This is where you do actual investigation. Read relevant code, check dependencies, look at existing implementations. Present what you can say with high confidence about what will actually happen.
#### Q3: Alignment Check
Compare Q1 answers against Q2 answers, then work through these sub-questions:
**3a. Goal Alignment**: Is the realistic outcome aligned with our goals? If not, the idea is solving the wrong problem.
**3b. Simpler Alternative**: Is there a simpler or existing way to achieve the goal-aligned outcome? Check whether something already exists that does what we need, or whether a configuration change would suffice.
**3c. Revision Impact**: If we proceed, what existing work will need to be edited, revised, or reconsidered? List specific files, specs, ADRs, and systems that would be affected.
**3d. Opportunity Cost**: Considering the revision impact from 3c, is executing this process more valuable than anything else we could be doing with that time?
### Step 3: Decision
If the answer to 3d is a **confident "no"**: Recommend turning attention to whatever IS the most valuable use of time. Record this recommendation in the workflow state.
If the answer is **anything else** (yes, uncertain, qualified yes): Recommend proceeding to Dev-Time Docs (Stage 2).
### Step 4: Record and Handoff
If the user confirms proceeding:
1. **Update workflow state** (`.workflow/state.json`):
- Set `stages.ideation.status` to `"completed"`
- Set `stages.ideation.completedAt` to current ISO timestamp
- Set `stages.ideation.notes` to a 1-2 sentence summary of the decision rationale
- Set `currentStage` to `"dev-docs"`
- Update `updatedAt`
2. **Present the handoff**:
```
IDEATION COMPLETE
=================
Decision: PROCEED / DO NOT PROCEED
Rationale: [1-2 sentences]
Desired outcomes:
- [bullet list from Q1]
Realistic outcomes:
- [bullet list from Q2]
Revision impact:
- [files/systems from 3c]
Next: Stage 2 - Dev-Time Docs (/hdd)
The conductor will dispatch /hdd to create the spec and ADR.
```
If the user decides NOT to proceed:
1. Update workflow state with status `"completed"` and notes explaining why
2. The workflow ends here
## Prior Art Check
When checking accepted ADRs and compound learnings, apply these specific checks:
- Does a prior ADR already address this domain? If so, does its reasoning still hold?
- Was this idea (or something similar) previously rejected? If so, what changed?
- Are there learnings that suggest this approach has been tried and failed?
If prior art exists, present it to the user with the question: "This relates to [prior work]. Has anything changed that makes this worth revisiting?"
## Anti-Patterns
- Do NOT skip straight to "yes, let's build it" — the questions exist to prevent wasted effort
- Do NOT fabricate realistic outcomes (Q2) — investigate the actual code and constraints
- Do NOT treat 3d as rhetorical — genuinely consider what else could be done with the time
- Do NOT write specs or ADRs — that's Stage 2's job