Provides standard operating procedures for the /specify phase including feature classification (HAS_UI, IS_IMPROVEMENT, HAS_METRICS, HAS_DEPLOYMENT_IMPACT), research depth determination, clarification strategy (max 3, informed guesses for defaults), and roadmap integration. Use when executing /specify command, classifying features, generating structured specs, or determining research depth for planning phase. (project)
Install via CLI
Skills Directoryopenskills install marcusgoll/Spec-Flow---
name: specification-phase
description: Provides standard operating procedures for the /specify phase including feature classification (HAS_UI, IS_IMPROVEMENT, HAS_METRICS, HAS_DEPLOYMENT_IMPACT), research depth determination, clarification strategy (max 3, informed guesses for defaults), and roadmap integration. Use when executing /specify command, classifying features, generating structured specs, or determining research depth for planning phase. (project)
---
<objective>
Transform natural language feature requests into structured specifications that enable planning and implementation through systematic classification, informed guess strategy, and minimal clarification approach.
This skill orchestrates the /specify phase, producing spec.md with measurable success criteria, classification flags for downstream workflows, and maximum 3 clarifications using informed guess heuristics for technical defaults.
**Core responsibilities**:
- Parse and normalize feature input to slug format (kebab-case, no filler words)
- Check roadmap integration to reuse existing context
- Load project documentation context (docs/project/) to prevent hallucination
- Classify feature with 4 flags (HAS_UI, IS_IMPROVEMENT, HAS_METRICS, HAS_DEPLOYMENT_IMPACT)
- Determine research depth based on complexity (FLAG_COUNT: 0→minimal, 1→standard, ≥2→full)
- Apply informed guess strategy for non-critical technical decisions
- Generate ≤3 clarifications (only scope/security critical)
- Write measurable success criteria (quantifiable, user-facing)
Inputs: User's feature description, existing roadmap entries, project docs (if exists), codebase context
Outputs: specs/NNN-slug/spec.md, NOTES.md, state.yaml, updated roadmap (if FROM_ROADMAP=true)
Expected duration: 10-15 minutes
</objective>
<quick_start>
Execute /specify workflow in 9 steps:
1. **Parse and normalize input** - Generate slug (remove filler words: "add", "create", "we want to"), assign feature number (NNN)
2. **Check roadmap integration** - Search roadmap for slug match, reuse context if found (saves ~10 minutes)
3. **Load project documentation** - Extract tech stack, API patterns, existing entities from docs/project/ (prevents hallucination)
4. **Classify feature** - Set HAS_UI, IS_IMPROVEMENT, HAS_METRICS, HAS_DEPLOYMENT_IMPACT flags using decision tree
5. **Determine research depth** - FLAG_COUNT → minimal (0), standard (1), full (≥2)
6. **Apply informed guess strategy** - Use defaults for performance (<500ms), rate limits (100/min), auth (OAuth2), retention (90d logs)
7. **Generate clarifications** - Max 3 critical clarifications (scope > security > UX > technical priority matrix)
8. **Write success criteria** - Measurable, quantifiable, user-facing outcomes (not tech-specific)
9. **Generate artifacts and commit** - Create spec.md, NOTES.md, state.yaml, update roadmap
Key principle: Use informed guesses for non-critical decisions, document assumptions, limit clarifications to ≤3.
</quick_start>
<prerequisites>
<environment_checks>
Before executing /specify phase:
- [ ] Git working tree clean (no uncommitted changes)
- [ ] Not on main branch (create feature branch: `feature/NNN-slug`)
- [ ] Required templates exist in `.spec-flow/templates/`
- [ ] If project docs exist, docs/project/ directory accessible
</environment_checks>
<knowledge_requirements>
Required understanding before execution:
- **Classification decision tree**: UI keywords vs backend-only exclusions, improvement = baseline + target, metrics = user tracking, deployment = env vars/migrations/breaking changes
- **Informed guess heuristics**: Performance (<500ms), retention (90d logs, 365d analytics), rate limits (100/min), auth (OAuth2), error handling (user-friendly + error ID)
- **Clarification prioritization matrix**: Critical (scope, security, breaking changes) > High (UX) > Medium (performance SLA, tech stack) > Low (error messages, rate limits)
- **Slug generation rules**: Remove filler words, lowercase kebab-case, 50 char limit, fuzzy match roadmap
See [reference.md](reference.md) for complete decision trees and heuristics.
</knowledge_requirements>
<warnings>
- **Over-clarification**: >3 clarifications indicates missing informed guesses (check reference.md for defaults)
- **Wrong classification**: Backend workers/APIs with HAS_UI=true wastes time generating UI artifacts
- **Roadmap mismatch**: Filler words in slug prevent roadmap match ("add-student-dashboard" vs "student-dashboard")
- **Vague success criteria**: "Works correctly", "is fast", "looks good" are not measurable - use quantifiable metrics
</warnings>
</prerequisites>
<workflow>
<step number="1">
**Parse and Normalize Input**
Extract feature description and generate clean slug.
**Slug Generation Rules**:
```bash
# Remove filler words and normalize
echo "$ARGUMENTS" |
sed 's/\bwe want to\b//gi; s/\bI want to\b//gi' |
sed 's/\badd\b//gi; s/\bcreate\b//gi; s/\bimplement\b//gi' |
sed 's/\bget our\b//gi; s/\bto a\b//gi; s/\bwith\b//gi' |
tr '[:upper:]' '[:lower:]' |
sed 's/[^a-z0-9-]/-/g' | sed 's/--*/-/g' | sed 's/^-//;s/-$//' |
cut -c1-50
```
**Example**:
- Input: "We want to add student progress dashboard"
- Slug: `student-progress-dashboard` ✅
- Number: 042
- Directory: `specs/042-student-progress-dashboard/`
**Quality Check**: Slug is concise, descriptive, no filler words, matches roadmap format.
See [reference.md § Slug Generation Rules](reference.md#slug-generation-rules) for detailed normalization logic.
</step>
<step number="2">
**Check Roadmap Integration**
Search roadmap for existing entry to reuse context.
**Detection Logic**:
```bash
SLUG="student-progress-dashboard"
if grep -qi "^### ${SLUG}" .spec-flow/memory/roadmap.md; then
FROM_ROADMAP=true
# Extract requirements, area, role, impact/effort scores
# Move entry from "Backlog"/"Next" to "In Progress"
# Add branch and spec links
fi
```
**Benefits**:
- Saves ~10 minutes (requirements already documented)
- Automatic status tracking (roadmap updates)
- Context reuse (user already vetted scope)
**Quality Check**: If roadmap match found, extracted requirements appear in spec.md.
See [reference.md § Roadmap Integration](reference.md#roadmap-integration) for fuzzy matching logic.
</step>
<step number="3">
**Load Project Documentation Context**
Extract architecture constraints from `docs/project/` to prevent hallucination.
**Detection**:
```bash
if [ -d "docs/project" ]; then
HAS_PROJECT_DOCS=true
# Extract tech stack, API patterns, entities
else
echo "ℹ️ No project documentation (run /init-project recommended)"
HAS_PROJECT_DOCS=false
fi
```
**Extraction**:
```bash
# Extract constraints from project docs
FRONTEND=$(grep -A 1 "| Frontend" docs/project/tech-stack.md | tail -1)
DATABASE=$(grep -A 1 "| Database" docs/project/tech-stack.md | tail -1)
API_STYLE=$(grep -A 1 "## API Style" docs/project/api-strategy.md | tail -1)
ENTITIES=$(grep -oP '[A-Z_]+(?= \{)' docs/project/data-architecture.md)
```
**Document in NOTES.md**:
```markdown
## Project Documentation Context
**Tech Stack Constraints** (from tech-stack.md):
- Frontend: Next.js 14
- Database: PostgreSQL
**Spec Requirements**:
- ✅ MUST use documented tech stack
- ✅ MUST follow API patterns from api-strategy.md
- ✅ MUST check for duplicate entities before proposing new ones
- ❌ MUST NOT hallucinate MongoDB if PostgreSQL is documented
```
**Quality Check**: NOTES.md includes project context section with constraints.
**Skip if**: No docs/project/ directory exists (warn user but don't block).
</step>
<step number="4">
**Classify Feature**
Set classification flags using decision tree.
**Classification Logic**:
**HAS_UI** (user-facing screens/components):
```
UI keywords: screen, page, dashboard, form, modal, component, frontend, interface
→ BUT NOT backend-only: API, endpoint, service, worker, cron, job, migration, health check
→ HAS_UI = true
Example: "Add student dashboard" → HAS_UI = true ✅
Example: "Add background worker" → HAS_UI = false ✅ (backend-only)
```
**IS_IMPROVEMENT** (optimization with measurable baseline):
```
Improvement keywords: improve, optimize, enhance, speed up, reduce time
AND baseline: existing, current, slow, faster, better
→ IS_IMPROVEMENT = true
Example: "Improve search performance from 3.2s to <500ms" → IS_IMPROVEMENT = true ✅
Example: "Make search faster" → IS_IMPROVEMENT = false ❌ (no baseline)
```
**HAS_METRICS** (user behavior tracking):
```
Metrics keywords: track user, measure user, engagement, retention, conversion, analytics, A/B test
→ HAS_METRICS = true
Example: "Track dashboard engagement" → HAS_METRICS = true ✅
```
**HAS_DEPLOYMENT_IMPACT** (env vars, migrations, breaking changes):
```
Deployment keywords: migration, schema change, env variable, breaking change, docker, platform change
→ HAS_DEPLOYMENT_IMPACT = true
Example: "OAuth authentication (needs env vars)" → HAS_DEPLOYMENT_IMPACT = true ✅
```
**Quality Check**: Classification matches feature intent. No UI artifacts for backend workers.
See [reference.md § Classification Decision Tree](reference.md#classification-decision-tree) for complete logic.
</step>
<step number="5">
**Determine Research Depth**
Select research depth based on complexity (FLAG_COUNT).
**Research Depth Guidelines**:
| FLAG_COUNT | Depth | Tools | Use Cases |
| ---------- | -------- | ----- | ----------------------------------------------- |
| 0 | Minimal | 1-2 | Simple backend endpoint, config change |
| 1 | Standard | 3-5 | Single-aspect feature (UI-only or backend-only) |
| ≥2 | Full | 5-8 | Complex multi-aspect feature |
**Minimal Research** (FLAG_COUNT = 0):
1. Constitution check (alignment with mission/values)
2. Grep for similar patterns
**Standard Research** (FLAG_COUNT = 1):
1-2. Minimal research 3. UI inventory scan (if HAS_UI=true) 4. Performance budgets check 5. Similar spec search
**Full Research** (FLAG_COUNT ≥ 2):
1-5. Standard research 6. Design inspirations (if HAS_UI=true) 7. Web search for novel patterns 8. Integration points analysis
**Quality Check**: Research depth matches complexity. Don't over-research simple features.
See [reference.md § Research Depth Guidelines](reference.md#research-depth-guidelines) for tool selection logic.
</step>
<step number="6">
**Apply Informed Guess Strategy**
Use defaults for non-critical technical decisions.
**Use Informed Guesses For** (do NOT clarify):
- **Performance targets**: API <500ms (95th percentile), Frontend FCP <1.5s, TTI <3.0s
- **Data retention**: User data indefinite (with deletion option), Logs 90 days, Analytics 365 days
- **Error handling**: User-friendly messages + error ID (ERR-XXXX), logging to error-log.md
- **Rate limiting**: 100 requests/minute per user, 1000/minute per IP
- **Authentication**: OAuth2 for users, JWT for APIs, MFA optional (users), required (admins)
- **Integration patterns**: RESTful API (unless GraphQL needed), JSON format, offset/limit pagination
**Document Assumptions in spec.md**:
```markdown
## Performance Targets (Assumed)
- API endpoints: <500ms (95th percentile)
- Frontend FCP: <1.5s, TTI: <3.0s
- Lighthouse: Performance ≥85, Accessibility ≥95
_Assumption: Standard web application performance expectations applied._
```
**Do NOT Use Informed Guesses For**:
- Scope-defining decisions (feature boundary, user roles)
- Security/privacy critical choices (encryption, PII handling)
- Breaking changes (API response format changes)
- No reasonable default exists (business logic decisions)
**Quality Check**: No clarifications for decisions with industry-standard defaults.
See [reference.md § Informed Guess Heuristics](reference.md#informed-guess-heuristics) for complete defaults catalog.
</step>
<step number="7">
**Generate Clarifications (Max 3)**
Identify ambiguities that cannot be reasonably assumed.
**Clarification Prioritization Matrix**:
| Category | Priority | Ask? | Example |
| ---------------- | -------- | ---------------- | --------------------------------------------------------- |
| Scope boundary | Critical | ✅ Always | "Does this include admin features or only user features?" |
| Security/Privacy | Critical | ✅ Always | "Should PII be encrypted at rest?" |
| Breaking changes | Critical | ✅ Always | "Is it okay to change the API response format?" |
| User experience | High | ✅ If ambiguous | "Should this be a modal or new page?" |
| Performance SLA | Medium | ❌ Use defaults | "What's the target response time?" → Assume <500ms |
| Technical stack | Medium | ❌ Defer to plan | "Which database?" → Planning-phase decision |
| Error messages | Low | ❌ Use standard | "What error message?" → Standard pattern |
| Rate limits | Low | ❌ Use defaults | "How many requests?" → 100/min default |
**Limit: Maximum 3 clarifications total**
**Process**:
1. Identify all ambiguities
2. Rank by category priority
3. Keep top 3 most critical
4. Make informed guesses for remaining
5. Document assumptions clearly
**Good Clarifications**:
```markdown
[NEEDS CLARIFICATION: Should dashboard show all students or only assigned classes?]
[NEEDS CLARIFICATION: Should parents have access to this dashboard?]
```
**Bad Clarifications** (have defaults):
```markdown
❌ [NEEDS CLARIFICATION: What's the target response time?] → Use 500ms default
❌ [NEEDS CLARIFICATION: Which database to use?] → Planning-phase decision
❌ [NEEDS CLARIFICATION: What error message format?] → Use standard pattern
```
**Quality Check**: ≤3 clarifications total, all are scope/security/UX critical.
See [reference.md § Clarification Prioritization Matrix](reference.md#clarification-prioritization-matrix) for complete ranking system.
</step>
<step number="8">
**Write Success Criteria**
Define measurable, quantifiable, user-facing outcomes.
**Good Criteria Format**:
```markdown
## Success Criteria
- User can complete registration in <3 minutes (measured via PostHog funnel)
- API response time <500ms for 95th percentile (measured via Datadog APM)
- Lighthouse accessibility score ≥95 (measured via CI Lighthouse check)
- 95% of user searches return results in <1 second
```
**Criteria Requirements**:
- **Measurable**: Can be validated objectively
- **Quantifiable**: Has specific numeric target
- **User-facing**: Focuses on outcomes, not implementation
- **Measurement method**: Specifies how to validate (tool, metric)
**Bad Criteria to Avoid**:
```markdown
❌ System works correctly (not measurable)
❌ API is fast (not quantifiable)
❌ UI looks good (subjective)
❌ React components render efficiently (technology-specific, not outcome-focused)
```
**Quality Check**: Every criterion is measurable, quantifiable, and outcome-focused.
</step>
<step number="9">
**Generate Artifacts and Commit**
Create specification artifacts and commit to git.
**Artifacts**:
1. `specs/NNN-slug/spec.md` - Structured specification with classification flags, requirements, assumptions, clarifications (≤3), success criteria
2. `specs/NNN-slug/NOTES.md` - Implementation decisions and project context
3. `specs/NNN-slug/visuals/README.md` - Visual artifacts directory (if HAS_UI=true)
4. `specs/NNN-slug/state.yaml` - Phase state tracking (currentPhase: specification, status: completed)
5. Updated roadmap (if FROM_ROADMAP=true) - Move entry to "In Progress", add branch/spec links
**Validation Checks**:
- [ ] Requirements checklist complete (if exists)
- [ ] Clarifications ≤3
- [ ] Classification flags match feature description
- [ ] Success criteria are measurable
- [ ] Roadmap updated (if FROM_ROADMAP=true)
**Commit Message**:
```bash
git add specs/NNN-slug/
git commit -m "feat: add spec for <feature-name>
Generated specification with classification:
- HAS_UI: <true/false>
- IS_IMPROVEMENT: <true/false>
- HAS_METRICS: <true/false>
- HAS_DEPLOYMENT_IMPACT: <true/false>
Clarifications: N
Research depth: <minimal/standard/full>"
```
**Quality Check**: All artifacts created, spec committed, roadmap updated, state.yaml initialized.
</step>
</workflow>
<validation>
<phase_checklist>
**Pre-phase checks**:
- [ ] Git working tree clean
- [ ] Not on main branch
- [ ] Required templates exist
**During phase**:
- [ ] Slug normalized (no filler words, lowercase kebab-case)
- [ ] Roadmap checked for existing entry
- [ ] Project docs loaded (if exist)
- [ ] Classification flags validated (no conflicting keywords)
- [ ] Research depth appropriate for complexity (FLAG_COUNT-based)
- [ ] Clarifications ≤3 (use informed guesses for rest)
- [ ] Success criteria measurable and quantifiable
- [ ] Assumptions documented clearly
**Post-phase validation**:
- [ ] spec.md committed with proper message
- [ ] NOTES.md initialized
- [ ] Roadmap updated (if FROM_ROADMAP=true)
- [ ] visuals/ created (if HAS_UI=true)
- [ ] state.yaml initialized
</phase_checklist>
<quality_standards>
**Specification quality targets**:
- Clarifications: ≤3 per spec
- Classification accuracy: ≥90%
- Success criteria: 100% measurable
- Time to spec: ≤15 minutes
- Rework rate: <5%
**What makes a good spec**:
- Clear scope boundaries (what's in, what's out)
- Measurable success criteria (with measurement methods)
- Reasonable assumptions documented
- Minimal clarifications (only critical scope/security)
- Correct classification (matches feature intent)
- Context reuse (from roadmap when available)
**What makes a bad spec**:
- > 5 clarifications (over-clarifying technical defaults)
- Vague success criteria ("works correctly", "is fast")
- Technology-specific criteria (couples to implementation)
- Wrong classification (UI flag for backend-only)
- Missing roadmap integration (duplicates planning work)
</quality_standards>
</validation>
<anti_patterns>
<pitfall name="over_clarification">
**Impact**: Delays planning phase, frustrates users
**Scenario**:
```
Spec with 7 clarifications (limit: 3):
- [NEEDS CLARIFICATION: What format? CSV or JSON?] → Use JSON default
- [NEEDS CLARIFICATION: Rate limiting strategy?] → Use 100/min default
- [NEEDS CLARIFICATION: Maximum file size?] → Use 50MB default
```
**Prevention**:
- Use industry-standard defaults (see reference.md § Informed Guess Heuristics)
- Only mark critical scope/security decisions as NEEDS CLARIFICATION
- Document assumptions in spec.md "Assumptions" section
- Prioritize by impact: scope > security > UX > technical
**If encountered**: Reduce to 3 most critical, convert others to documented assumptions.
</pitfall>
<pitfall name="wrong_classification">
**Impact**: Creates unnecessary UI artifacts, wastes time
**Scenario**:
```
Feature: "Add background worker to process uploads"
Classified: HAS_UI=true (WRONG - no user-facing UI)
Result: Generated screens.yaml for backend-only feature
```
**Root cause**: Keyword "process" triggered false positive without checking for backend-only keywords
**Prevention**:
1. Check for backend-only keywords: worker, cron, job, migration, health check, API, endpoint, service
2. Require BOTH UI keyword AND absence of backend-only keywords
3. Use classification decision tree (see reference.md § Classification Decision Tree)
</pitfall>
<pitfall name="roadmap_slug_mismatch">
**Impact**: Misses context reuse opportunity, duplicates planning work
**Scenario**:
```
User input: "We want to add Student Progress Dashboard"
Generated slug: "add-student-progress-dashboard" (BAD - includes "add")
Roadmap entry: "### student-progress-dashboard" (slug without "add")
Result: No match found, created fresh spec instead of reusing roadmap context
```
**Prevention**:
1. Remove filler words during slug generation: "add", "create", "we want to"
2. Normalize to lowercase kebab-case consistently
3. Offer fuzzy matches if exact match not found
</pitfall>
<pitfall name="too_many_research_tools">
**Impact**: Wastes time, exceeds token budget
**Scenario**:
```bash
# 15 research tools for simple backend endpoint (WRONG)
Glob *.py, Glob *.ts, Glob *.tsx, Grep "database", Grep "model"...
```
**Prevention**:
- Use research depth guidelines: FLAG_COUNT = 0 → 1-2 tools only
- For simple features: Constitution check + pattern search is sufficient
- Reserve full research (5-8 tools) for complex multi-aspect features
**Correct approach**:
```bash
# 2 research tools for simple backend endpoint (CORRECT)
grep "similar endpoint" specs/*/spec.md
grep "BaseModel" api/app/models/*.py
```
</pitfall>
<pitfall name="vague_success_criteria">
**Impact**: Cannot validate implementation, leads to scope creep
**Bad examples**:
```markdown
❌ System works correctly (not measurable)
❌ API is fast (not quantifiable)
❌ UI looks good (subjective)
```
**Good examples**:
```markdown
✅ User can complete registration in <3 minutes (measured via PostHog funnel)
✅ API response time <500ms for 95th percentile (measured via Datadog APM)
✅ Lighthouse accessibility score ≥95 (measured via CI Lighthouse check)
```
**Prevention**: Every criterion must answer: "How do we measure this objectively?"
</pitfall>
<pitfall name="technology_specific_criteria">
**Impact**: Couples spec to implementation details, reduces flexibility
**Bad examples**:
```markdown
❌ React components render efficiently
❌ Redis cache hit rate >80%
❌ PostgreSQL queries use proper indexes
```
**Good examples** (outcome-focused):
```markdown
✅ Page load time <1.5s (First Contentful Paint)
✅ 95% of user searches return results in <1 second
✅ Database queries complete in <100ms average
```
**Prevention**: Focus on user-facing outcomes, not implementation mechanisms.
</pitfall>
</anti_patterns>
<best_practices>
<informed_guess_strategy>
**When to use**:
- Non-critical technical decisions
- Industry standards exist
- Default won't impact scope or security
**When NOT to use**:
- Scope-defining decisions
- Security/privacy critical choices
- No reasonable default exists
**Approach**:
1. Check if decision has reasonable default (see reference.md § Informed Guess Heuristics)
2. Document assumption clearly in spec
3. Note that user can override if needed
**Example**:
```markdown
## Performance Targets (Assumed)
- API response time: <500ms (95th percentile)
- Frontend FCP: <1.5s
- Database queries: <100ms
**Assumptions**:
- Standard web app performance expectations applied
- If requirements differ, specify in "Performance Requirements" section
```
**Result**: Reduces clarifications from 5-7 to 0-2, saves ~10 minutes
</informed_guess_strategy>
<roadmap_integration>
**When to use**:
- Feature name matches roadmap entry
- Roadmap uses consistent slug format
**Approach**:
1. Normalize user input to slug format
2. Search roadmap for exact match
3. If found: Extract requirements, area, role, impact/effort
4. Move to "In Progress" section automatically
5. Add branch and spec links
**Result**: Saves ~10 minutes, requirements already vetted, automatic status tracking
</roadmap_integration>
<classification_decision_tree>
**Best practice**: Follow decision tree systematically (see reference.md § Classification Decision Tree)
**Process**:
1. Check UI keywords → Set HAS_UI (but verify no backend-only exclusions)
2. Check improvement keywords + baseline → Set IS_IMPROVEMENT
3. Check metrics keywords → Set HAS_METRICS
4. Check deployment keywords → Set HAS_DEPLOYMENT_IMPACT
**Result**: 90%+ classification accuracy, correct artifacts generated
</classification_decision_tree>
</best_practices>
<success_criteria>
Specification phase complete when:
- [ ] All pre-phase checks passed
- [ ] All 9 execution steps completed
- [ ] All post-phase validations passed
- [ ] Spec committed to git
- [ ] state.yaml shows `currentPhase: specification` and `status: completed`
Ready to proceed when:
- If clarifications >0 → Run `/clarify`
- If clarifications = 0 → Run `/plan`
</success_criteria>
<troubleshooting>
**Issue**: Too many clarifications (>3)
**Solution**: Review reference.md § Informed Guess Heuristics for defaults, convert non-critical questions to assumptions
**Issue**: Classification seems wrong
**Solution**: Re-check decision tree, verify no backend-only keywords for HAS_UI=true
**Issue**: Roadmap entry exists but wasn't matched
**Solution**: Check slug normalization, offer fuzzy matches, update roadmap slug format
**Issue**: Success criteria are vague
**Solution**: Add quantifiable metrics and measurement methods, focus on user-facing outcomes
**Issue**: Research depth excessive for simple feature
**Solution**: Follow FLAG_COUNT guidelines (0→minimal, 1→standard, ≥2→full)
**Issue**: Project context missing/incomplete
**Solution**: Run /init-project to generate docs/project/, or manually create tech-stack.md and api-strategy.md
</troubleshooting>
<reference_guides>
For detailed documentation:
**Classification & Defaults**: [reference.md](reference.md)
- Classification decision tree (HAS_UI, IS_IMPROVEMENT, HAS_METRICS, HAS_DEPLOYMENT_IMPACT)
- Informed guess heuristics (performance, retention, auth, rate limits)
- Clarification prioritization matrix (scope > security > UX > technical)
- Slug generation rules (normalization, filler word removal)
**Real-World Examples**: [examples.md](examples.md)
- Good specs (0-2 clarifications) vs bad specs (>5 clarifications)
- Side-by-side comparisons with analysis
- Progressive learning patterns (features 1-5, 6-15, 16+)
- Classification accuracy examples
**Execution Details**: reference.md § Research Depth Guidelines, Common Mistakes to Avoid
Next phase after /specify:
- If clarifications >0 → `/clarify` (reduces ambiguity via targeted questions)
- If clarifications = 0 → `/plan` (generates design artifacts from spec)
</reference_guides>
No comments yet. Be the first to comment!
