Openspec Proposal Creation
Scaffold OpenSpec change proposals with implementation tasks and formal spec deltas before your agent starts coding.
Overview
OpenSpec Proposal Creation is an agent skill most often used in Validate (also Build PM and Ship review prep) that drafts proposal.md, tasks.md, and EARS-style spec deltas for approved, spec-driven changes.
Install
npx skills add https://github.com/forztf/open-skilled-sdd --skill openspec-proposal-creationWhat is this skill?
- Produces three linked artifacts: proposal.md (why/what/impact), tasks.md (numbered checklist), and spec-delta.md (ADDED/
- Eight-step tracked workflow from reviewing existing specs through validation and user approval.
- Generates unique change IDs and scaffolds directory structure for spec-driven development.
- Writes requirement deltas in EARS format for formal specification changes.
- Explicit Step 8 gate: present proposal for user approval before implementation proceeds.
- 8-step proposal progress checklist
- 3 core outputs: proposal.md, tasks.md, spec-delta.md
Adoption & trust: 810 installs on skills.sh; 9 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what you want to build but lack a structured proposal, task list, and formal spec delta your agent can follow without scope drift.
Who is it for?
Solo builders introducing features, breaking changes, or architecture updates under OpenSpec or similar spec-first workflows.
Skip if: One-line bugfixes with no spec surface, or situations where the spec is already approved and you only need coding—skip straight to implementation skills.
When should I use this skill?
User asks for openspec proposal, create proposal, plan change, spec feature, new capability, add feature planning, or design spec.
What do I get? / Deliverables
You get a validated change package with impact summary, numbered implementation tasks, and spec deltas ready for approval—then hand off to implementation or writing-plans style execution.
- proposal.md with why/what/impact
- tasks.md numbered implementation checklist
- spec-delta.md with ADDED/MODIFIED/REMOVED EARS requirements
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the skill’s job is to plan and spec a change—with approval gates—before implementation commits. Scope subphase matches feature planning, breaking-change design, and architecture updates that narrow what will be built.
Where it fits
Draft proposal.md and spec deltas when scoping a paid-tier feature before any repo changes.
Refresh tasks.md and MODIFIED requirements when splitting a monolith module mid-build.
Attach spec-delta.md to a change so reviewers see formal requirement impact, not only a diff.
How it compares
Use instead of ad-hoc “write a PRD in chat” when you need formal spec deltas and a checklist, not a loose feature brainstorm alone.
Common Questions / FAQ
Who is openspec-proposal-creation for?
Indie and solo developers using AI coding agents who want OpenSpec-style change proposals with tasks and requirement deltas before code lands.
When should I use openspec-proposal-creation?
During Validate when scoping a new capability or breaking change; during Build when packaging PM-style spec updates; and before Ship when you need an auditable spec diff for review—all triggered by phrases like openspec proposal, plan change, or spec feature.
Is openspec-proposal-creation safe to install?
It is primarily documentation and file scaffolding; review the Security Audits panel on this Prism page and inspect the skill repo before granting broad filesystem access to your agent.
SKILL.md
READMESKILL.md - Openspec Proposal Creation
# Specification Proposal Creation Creates comprehensive change proposals following spec-driven development methodology. ## Quick Start Creating a spec proposal involves three main outputs: 1. **proposal.md** - Why, what, and impact summary 2. **tasks.md** - Numbered implementation checklist 3. **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: ```bash # 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-authentication` - `fix-payment-validation` - `update-api-rate-limits` - `remove-legacy-endpoints` **Validation**: Check for conflicts: ```bash ls spec/changes/ | grep -i "<proposed-id>" ``` ### Step 3: Scaffold directory structure Create the change folder with standard structure: ```bash # Replace {change-id} with actual ID mkdir -p spec/changes/{change-id}/specs/{capability-name} ``` **Example**: ```bash mkdir -p spec/changes/add-user-auth/specs/authentication ``` ### Step 4: Draft proposal.md Use the template at [templates/proposal.md](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](templates/tasks.md). **Format**: ```markdown # 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](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**: ```markdown ## 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@