| name | spec-research |
| description | Write OpenSpec proposal.md artifacts (why + what). TRIGGER when: capturing requirements, scope, and impact for a spec-driven feature. SKIP: technical design (use spec-design); external documentation research (use research-methodology). |
OpenSpec Proposal Writing
Guide for creating proposal.md -- the WHY document that anchors the entire workflow.
Output Path
Write to: {specs_path}/proposal.md
Path Enforcement: The specs_path MUST be .scaffolding/conversations/{UUID}/specs/ where {UUID} is a valid UUID (format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). NEVER use descriptive folder names.
Required Sections
| Section | Purpose | Content |
|---|
| Why | Motivation | 1-2 sentences. What problem? Why now? |
| What Changes | Scope | Bullet list. New capabilities, modifications, removals. Mark BREAKING |
| Capabilities | Contract | New + modified capabilities (kebab-case names) |
| Impact | Blast radius | Affected code, APIs, dependencies, systems |
| Agent Assignment | Routing | Table of agents, roles, artifacts |
| Rollback Plan | Safety | Revert points, manual steps, affected systems |
Capabilities Section (Critical)
This section creates the contract between proposal and design phases.
New Capabilities
- Use kebab-case:
user-auth, data-export, api-rate-limiting
- Each becomes a requirement group in design.md
- Brief description of what the capability covers
Modified Capabilities
- Only list if spec-level REQUIREMENTS change (not just implementation)
- Check
.scaffolding/openspec/specs/ for existing names
- Leave empty if no requirement changes
Quality Checklist
Template Structure
## Why
[1-2 sentences: problem + urgency]
## What Changes
- [Specific change 1]
- [Specific change 2]
- **BREAKING**: [Breaking change, if any]
## Capabilities
### New Capabilities
- `capability-name`: Brief description
### Modified Capabilities
- `existing-name`: What requirement is changing
## Impact
[Affected code, APIs, dependencies, systems]
## Agent Assignment
| Agent | Role | Artifacts |
|-------|------|-----------|
| architect | Analyst + Coordinator | proposal.md, design.md, tasks.md |
| researcher | External Research (if needed) | ResearchPack |
| developer | Developer | Source code |
| reviewer | Reviewer | Review report |
## Rollback Plan
- [ ] Identify revert points
- [ ] Document manual rollback steps
- [ ] List affected systems
Anti-Patterns
| Avoid | Instead |
|---|
| Vague goals ("improve performance") | Measurable goals ("reduce p95 latency below 200ms") |
| Implementation details | Save for design.md |
| Missing rollback plan | Always include revert strategy |
| Skipping capabilities section | This is the design contract |