openspec-proposal-creation
Enhancing AI coding assistants through open Spec-driven development (Spec-driven development for AI coding assistants), adopting the Claude Code Skills approach, compatible with various CLI and IDE AI coding assistants that support AGENTS.md.
npx skills add https://github.com/forztf/open-skilled-sdd --skill openspec-proposal-creationSKILL.md
Specification Proposal Creation
Creates comprehensive change proposals following spec-driven development methodology.
Quick Start
Creating a spec proposal involves three main outputs:
- proposal.md - Why, what, and impact summary
- tasks.md - Numbered implementation checklist
- spec-delta.md - Formal requirement changes (ADDED/MODIFIED/REMOVED)
Basic workflow: Generate change ID → scaffold directories → draft proposal → create spec deltas → validate structure
Workflow
Copy this checklist and track progress:
Proposal Progress:
- [ ] Step 1: Review existing specifications
- [ ] Step 2: Generate unique change ID
- [ ] Step 3: Scaffold directory structure
- [ ] Step 4: Draft proposal.md (Why/What/Impact)
- [ ] Step 5: Create tasks.md implementation checklist
- [ ] Step 6: Write spec deltas with EARS format
- [ ] Step 7: Validate proposal structure
- [ ] Step 8: Present for user approval
Step 1: Review existing specifications
Before creating a proposal, understand the current state:
# List all existing specs
find spec/specs -name "spec.md" -type f
# List active changes to avoid conflicts
find spec/changes -maxdepth 1 -type d -not -path "*/archive"
# Search for related requirements
grep -r "### Requirement:" spec/specs/
Step 2: Generate unique change ID
Choose a descriptive, URL-safe identifier:
Format: add-<feature>, fix-<issue>, update-<component>, remove-<feature>
Examples:
add-user-authenticationfix-payment-validationupdate-api-rate-limitsremove-legacy-endpoints
Validation: Check for conflicts:
ls spec/changes/ | grep -i "<proposed-id>"
Step 3: Scaffold directory structure
Create the change folder with standard structure:
# Replace {change-id} with actual ID
mkdir -p spec/changes/{change-id}/specs/{capability-name}
Example:
mkdir -p spec/changes/add-user-auth/specs/authentication
Step 4: Draft proposal.md
Use the template at templates/proposal.md as starting point.
Required sections:
- Why: Problem or opportunity driving this change
- What Changes: Bullet list of modifications
- Impact: Affected specs, code, APIs, users
Tone: Clear, concise, decision-focused. Avoid unnecessary background.
Step 5: Create tasks.md implementation checklist
Break implementation into concrete, testable tasks. Use the template at templates/tasks.md.
Format:
# Implementation Tasks
1. [First concrete task]
2. [Second concrete task]
3. [Test task]
4. [Documentation task]
Best practices:
- Each task is independently completable
- Include testing and validation tasks
- Order by dependencies (database before API, etc.)
- 5-15 tasks is typical; split if more needed
Step 6: Write spec deltas with EARS format
This is the most critical step. Spec deltas use EARS format (Easy Approach to Requirements Syntax).
For complete EARS guidelines, see reference/EARS_FORMAT.md
Delta operations:
## ADDED Requirements- New capabilities## MODIFIED Requirements- Changed behavior (include full updated text)## REMOVED Requirements- Deprecated features
Basic requirement structure:
## ADDED Requirements
### Requirement: User Login
WHEN a user submits valid credentials,
the system SHALL authenticate the user and create a session.
#### Scenario: Successful Login
GIVEN a user with email "user@example.com" and password "correct123"
WHEN the user submits the login form
THEN the system creates an authenticated session
AND redirects to the dashboard
For validation patterns, see reference/VALIDATION_PATTERNS.md
Step 7: Validate proposal structure
Run these checks before presenting to user:
Structure Checklist:
- [ ] Directory exists: `spec/changes/{change-id}/`
- [ ] proposal.md has Why/What/Impact sections
- [ ] tasks.md has numbered task list (5-15 items)
- [ ] Spec deltas have operation headers (ADDED/MODIFIED/REMOVED)
- [ ] Requirements follow `### Requirement: <name>` format
- [ ] Scenarios use `#### Scenario:` format (4 hashtags)
Automated checks:
# Count delta operations (should be > 0)
grep -c "## ADDED\|MODIFIED\|REMOVED" spec/changes/{change-id}/specs/**/*.md
# Verify scenario format (should show line numbers)
grep -n "#### Scenario:" spec/changes/{change-id}/specs/**/*.md
# Check requirement headers
grep -n "### Requirement:" spec/changes/{change-id}/specs/**/*.md
Step 8: Present for user approval
Summarize the proposal clearly:
## Proposal Summary
**Change ID**: {change-id}
**Scope**: {brief description}
**Files created**:
- spec/changes/{change-id}/proposal.md
- spec/changes/{change-id}/tasks.md
- spec/changes/{change-id}/specs/{capability}/spec-delta.md
**Next steps**:
Review the proposal. If approved,
...