Use when adding features, changing behavior, or modifying architecture. Creates change proposal with specs and tasks. ALWAYS ask for approval before proceeding to implementation...
Create change proposals for new features or behavioral changes.
Announce: "I'm using openspec-propose to create a change proposal for approval."
NO IMPLEMENTATION WITHOUT APPROVED PROPOSAL
Do NOT write implementation code during this phase. Only create:
proposal.mdtasks.mddesign.md (if complex)openspec/project.md for conventionsopenspec list --specs to see current capabilitiesopenspec list to check for conflictsrg [keyword]Format: verb-noun in kebab-case
Examples:
add-leaderboardupdate-scoring-algorithmrefactor-game-stateVerify uniqueness against openspec list.
Create openspec/changes/[id]/proposal.md:
# Change: [Brief description]
## Why
[1-2 sentences: What problem does this solve?]
## What Changes
- [Change 1]
- [Change 2]
- **BREAKING**: [If any breaking changes]
## Impact
- Affected specs: [list]
- Affected code: [key files/directories]
For each affected capability, create openspec/changes/[id]/specs/[capability]/spec.md:
## ADDED Requirements
### Requirement: [Name]
The system SHALL [behavior].
#### Scenario: [Name]
- **WHEN** [condition]
- **THEN** [expected result]
## MODIFIED Requirements
### Requirement: [Existing Name]
[Complete updated requirement text - not just the diff]
#### Scenario: [Name]
- **WHEN** [condition]
- **THEN** [expected result]
Every requirement MUST have at least one scenario.
Create openspec/changes/[id]/tasks.md:
## 1. [Category]
- [ ] 1.1 [Specific task - 2-5 minutes]
- [ ] 1.2 [Specific task - 2-5 minutes]
## 2. [Category]
- [ ] 2.1 [Specific task - 2-5 minutes]
openspec validate [id] --strict
Fix ALL issues before presenting to user.
Present summary to user:
## Proposal: [id]
**Goal:** [One sentence]
**Changes:**
- [Key change 1]
- [Key change 2]
**Tasks:** [X] items
**Ready for your review.** Run `openspec show [id]` for full details.
Do you approve this proposal?
WAIT for explicit approval before proceeding.
After approval:
→ Load task-planning skill if tasks need more detail
→ Load openspec-apply skill to begin implementation
If you catch yourself:
STOP. This phase is planning only.
| Excuse | Reality |
|---|---|
| "This is small, skip the proposal" | Small changes compound. Spec it anyway. |
| "I'll document after implementing" | After-the-fact docs miss the reasoning. |
| "User seems impatient" | Wrong implementation wastes more time. |
| "Tasks are obvious, I'll figure it out" | Vague tasks lead to scope creep. |