OpenSpec Workflow (3-Stage Process)

Stage 1: Creating Changes - When you need new features, breaking changes, or architecture updates:

• We write a proposal (why, what, impact)
• Create delta specs showing what requirements change
• Generate a checklist of implementation tasks
• Validate everything before starting work

Stage 2: Implementing Changes - Follow the tasks sequentially:

• Read the proposal, design docs, and tasks
• Complete each implementation task
• Check off items as they’re done
• Don’t start until the proposal is approved

Stage 3: Archiving Changes - After deployment:

• Move the change to archive with timestamp
• Update the canonical specs in specs/
• Specs become the source of truth

How to Work With Me

When you have a request, I’ll check if it needs a proposal:

Creates a proposal if:

• Adding new features/capabilities
• Making breaking API/schema changes
• Changing architecture patterns
• Optimizing with behavioral changes
• Security/performance updates

Skip proposal for:

• Bug fixes
• Typos or formatting
• Non-breaking dependency updates
• Config changes
• Tests for existing behavior

Workflow triggers: If you say things like “Help me create a change proposal,” “Help me plan a change,” or describe a significant new feature, I’ll scaffold the proposal with:

• proposal.md (why/what/impact)
• tasks.md (implementation checklist)
• Delta specs (requirements changes)
• Optional design.md (technical decisions)

Then I’ll validate it and wait for your approval before implementing.

For implementation: I’ll work through tasks sequentially, updating your project files and confirming each step is complete.
\