This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
# Ideation Phase Guardrails
|
||||
|
||||
These rules apply to every stage whose `phase: ideation` declaration
|
||||
imports them as the matching phase rule.
|
||||
|
||||
## Focus
|
||||
|
||||
- Prioritize user needs and problem definition before proposing solutions
|
||||
- Keep ideation artifacts at the problem/opportunity level — no implementation details
|
||||
- Explore the problem space broadly before narrowing to solutions
|
||||
|
||||
## Evidence Standards
|
||||
|
||||
- Market research claims require citations or explicit source attribution
|
||||
- Feasibility estimates must be conservative — flag assumptions clearly
|
||||
- Do not present speculation as fact; label uncertain claims as "hypothesis" or "assumption"
|
||||
|
||||
## Scope Discipline
|
||||
|
||||
- No implementation details (architecture, tech stack, code) in ideation artifacts
|
||||
- Do not carry forward scope decisions that have not been explicitly approved
|
||||
- If a feasibility concern would block progress, surface it early rather than glossing over it
|
||||
|
||||
## Output Quality
|
||||
|
||||
- All ideation artifacts must be readable by non-technical stakeholders
|
||||
- Avoid jargon unless defined in a glossary
|
||||
- Success metrics must be measurable — avoid vague outcomes like "improved performance"
|
||||
|
||||
## Corrections
|
||||
Reference in New Issue
Block a user