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:

# 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:

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, say "openspec implement" or "apply the change" to begin implementation.

Advanced Topics

EARS format details: See reference/EARS_FORMAT.md Validation patterns: See reference/VALIDATION_PATTERNS.md Complete examples: See reference/EXAMPLES.md

Common Patterns

Pattern 1: New feature proposal

When adding net-new capability:

• Use ADDED Requirements delta
• Include positive scenarios AND error handling
• Consider edge cases in scenarios

Pattern 2: Breaking change proposal

When changing existing behavior:

• Use MODIFIED Requirements delta
• Include complete updated requirement text
• Document what changes and why in proposal.md
• Consider migration tasks in tasks.md

Pattern 3: Deprecation proposal

When removing features:

• Use REMOVED Requirements delta
• Document removal rationale in proposal.md
• Include cleanup tasks in tasks.md
• Consider user migration in impact section

Anti-Patterns to Avoid

Don't:

• Skip validation checks (always run grep patterns)
• Create proposals without reviewing existing specs first
• Use vague task descriptions ("Fix the thing")
• Write requirements without scenarios
• Forget error handling scenarios
• Mix multiple unrelated changes in one proposal

Do:

• Check for conflicts before creating change ID
• Write concrete, testable tasks
• Include positive AND negative scenarios
• Keep one concern per proposal
• Validate structure before presenting

File Templates

All templates are in the templates/ directory:

• proposal.md - Proposal structure
• tasks.md - Task checklist format
• spec-delta.md - Spec delta template

Reference Materials

• EARS_FORMAT.md - Complete EARS syntax guide
• VALIDATION_PATTERNS.md - Grep/bash validation
• EXAMPLES.md - Real-world proposal examples

---

Token budget: This SKILL.md is approximately 450 lines, under the 500-line recommended limit. Reference files load only when needed for progressive disclosure.

EARS Format Guide

EARS (Easy Approach to Requirements Syntax) provides a structured format for writing clear, testable requirements.

Contents

• Requirement structure and keywords
• Scenario format (Given/When/Then)
• Requirement types and patterns
• Examples and anti-patterns

Requirement Structure

Basic Format

### Requirement: {Descriptive Name}
{TRIGGER clause},
the system SHALL {action and outcome}.

Trigger Types

WHEN (Event-driven):

### Requirement: Save User Profile
WHEN a user clicks the "Save" button,
the system SHALL persist profile changes to the database.

IF (State-driven):

### Requirement: Free Shipping
IF the cart total exceeds $50,
the system SHALL waive shipping fees.

WHERE (Feature-specific):

### Requirement: Admin Access
WHERE the user has admin privileges,
the system SHALL display the administration panel.

WHILE (Continuous):

### Requirement: Real-time Sync
WHILE a document is open,
the system SHALL synchronize changes every 5 seconds.

SHALL vs SHOULD vs MAY

• SHALL: Binding requirement (must be implemented)
• SHOULD: Recommended but not mandatory
• MAY: Optional capability

Prefer SHALL for all production requirements. Use SHOULD/MAY sparingly.

Scenario Format

Every requirement MUST have scenarios showing expected behavior.

Structure

#### Scenario: {Descriptive Name}
GIVEN {preconditions}
AND {additional preconditions}
WHEN {action or trigger}
THEN {expected outcome}
AND {additional outcome}

Example: Complete Requirement with Scenarios

### Requirement: User Login
WHEN a user submits valid credentials,
the system SHALL authenticate the user and create a session.

#### Scenario: Successful Login
GIVEN a registered user with email "user@example.com"
AND the user has correct password "SecurePass123"
WHEN the user submits the login form
THEN the system creates an authenticated session
AND redirects the user to the dashboard
AND sets a session cookie expiring in 24 hours

#### Scenario: Invalid Password
GIVEN a registered user with email "user@example.com"
AND the user provides incorrect password "WrongPass"
WHEN the user submits the login form
THEN the system rejects the login attempt
AND displays error message "Invalid email or password"
AND does not create a session

#### Scenario: Account Locked
GIVEN a user account that is locked due to failed attempts
WHEN the user submits any credentials
THEN the system rejects the login attempt
AND displays error message "Account locked. Contact support."

Requirement Patterns

Pattern 1: Data Validation

### Requirement: Email Validation
WHEN a user enters an email address,
the system SHALL validate the format matches RFC 5322 standard.

#### Scenario: Valid Email
GIVEN a user entering email "test@example.com"
WHEN the form is submitted
THEN the system accepts the email

#### Scenario: Invalid Format
GIVEN a user entering email "not-an-email"
WHEN the form is submitted
THEN the system displays error "Invalid email format"

Pattern 2: Authorization

### Requirement: Delete Permission
WHERE a user attempts to delete a resource,
the system SHALL verify the user owns the resource OR has admin privileges.

#### Scenario: Owner Deletes
GIVEN a user owns document ID 123
WHEN the user requests deletion of document 123
THEN the system deletes the document

#### Scenario: Non-owner Blocked
GIVEN a user does not own document ID 456
AND the user lacks admin privileges
WHEN the user requests deletion of document 456
THEN the system returns HTTP 403 Forbidden

Pattern 3: State Transitions

### Requirement: Order Processing
WHEN an order is placed,
the system SHALL transition through states: pending → processing → shipped → delivered.

#### Scenario: Standard Flow
GIVEN a new order in "pending" state
WHEN payment is confirmed
THEN the system transitions to "processing"
WHEN items are shipped
THEN the system transitions to "shipped"
WHEN delivery is confirmed
THEN the system transitions to "delivered"

Anti-Patterns to Avoid

❌ Vague Requirements

Bad:

### Requirement: Fast Performance
The system should be fast.

Good:

### Requirement: API Response Time
WHEN an API request is made,
the system SHALL respond within 200 milliseconds for 95% of requests.

#### Scenario: Normal Load
GIVEN the system is under normal load (< 100 requests/second)
WHEN an API request is made
THEN the response time is less than 200ms

❌ Missing Scenarios

Bad:

### Requirement: File Upload
WHEN a user uploads a file,
the system SHALL store it.

Good:

### Requirement: File Upload
WHEN a user uploads a file under 10MB,
the system SHALL store it in S3 and return a URL.

#### Scenario: Successful Upload
GIVEN a user selects a 5MB PDF file
WHEN the upload completes
THEN the system stores the file in S3
AND returns a signed URL valid for 1 hour

#### Scenario: File Too Large
GIVEN a user selects a 15MB video file
WHEN the upload is attempted
THEN the system rejects the file
AND displays error "File size exceeds 10MB limit"

❌ Implementation Details in Requirements

Bad:

### Requirement: Password Storage
The system SHALL use bcrypt with work factor 12 and store hashes in the users table.

Good:

### Requirement: Secure Password Storage
WHEN a user sets a password,
the system SHALL hash the password using industry-standard one-way hashing before storage.

#### Scenario: Password Creation
GIVEN a user sets password "SecurePass123"
WHEN the system processes the password
THEN the system stores only a cryptographic hash
AND discards the plaintext password
AND uses a unique salt per user

(Implementation choice of bcrypt/work factor goes in design docs, not requirements)

Complete Example: User Registration

## ADDED Requirements

### Requirement: Account Creation
WHEN a user submits a registration form with valid data,
the system SHALL create a new account and send a verification email.

#### Scenario: Successful Registration
GIVEN a user provides email "new@example.com"
AND provides password "SecurePass123"
AND provides name "John Doe"
AND the email is not already registered
WHEN the user submits the registration form
THEN the system creates a new user account
AND sends a verification email to "new@example.com"
AND displays message "Check your email to verify your account"
AND redirects to the login page

#### Scenario: Duplicate Email
GIVEN a user provides email "existing@example.com"
AND that email is already registered
WHEN the user submits the registration form
THEN the system rejects the registration
AND displays error "This email is already registered"
AND does not send an email

#### Scenario: Weak Password
GIVEN a user provides password "123"
WHEN the user submits the registration form
THEN the system rejects the registration
AND displays error "Password must be at least 8 characters"

### Requirement: Email Verification
WHEN a user clicks a verification link,
the system SHALL activate the account if the token is valid and not expired.

#### Scenario: Valid Token
GIVEN a user received a verification email
AND the verification token is less than 24 hours old
WHEN the user clicks the verification link
THEN the system activates the account
AND displays message "Account verified successfully"
AND redirects to the login page

#### Scenario: Expired Token
GIVEN a verification token is more than 24 hours old
WHEN the user clicks the verification link
THEN the system rejects the verification
AND displays message "Verification link expired. Request a new one."

Summary Checklist

When writing requirements:

• [ ] Use SHALL for binding requirements
• [ ] Include trigger clause (WHEN/IF/WHERE/WHILE)
• [ ] Write clear action and outcome
• [ ] Include at least one positive scenario
• [ ] Include error/edge case scenarios
• [ ] Use Given/When/Then format for scenarios
• [ ] Avoid implementation details
• [ ] Make requirements testable

Validation Patterns

Grep and bash patterns to validate proposal structure without external CLI tools.

Contents

• Directory structure validation
• Proposal file validation
• Spec delta validation
• Requirement format validation
• Common validation workflows

Directory Structure Validation

Check Change Directory Exists

# Verify change directory was created
test -d spec/changes/{change-id} && echo "✓ Directory exists" || echo "✗ Directory missing"

List All Changes

# Show all active changes
ls -1 spec/changes/ | grep -v "archive"

Check for Conflicts

# Search for similar change IDs
ls spec/changes/ | grep -i "{search-term}"

Proposal File Validation

Check Required Sections

# Verify proposal.md has required sections
grep -c "## Why" spec/changes/{change-id}/proposal.md
grep -c "## What Changes" spec/changes/{change-id}/proposal.md
grep -c "## Impact" spec/changes/{change-id}/proposal.md

Expected: Each grep returns 1 (or more if subsections exist)

Validate Tasks File

# Count numbered tasks
grep -c "^[0-9]\+\." spec/changes/{change-id}/tasks.md

# Show task list
grep "^[0-9]\+\." spec/changes/{change-id}/tasks.md

Expected: 5-15 tasks typically

Spec Delta Validation

Check Delta Operations Exist

# Count delta operation headers
grep -c "## ADDED\|MODIFIED\|REMOVED" spec/changes/{change-id}/specs/**/*.md

Expected: At least 1 match

List Delta Operations

# Show all delta operations with line numbers
grep -n "## ADDED\|MODIFIED\|REMOVED" spec/changes/{change-id}/specs/**/*.md

Example output:

spec/changes/add-auth/specs/authentication/spec-delta.md:3:## ADDED Requirements
spec/changes/add-auth/specs/authentication/spec-delta.md:45:## MODIFIED Requirements

Verify Each Section Has Content

# Check if ADDED section has requirements
awk '/## ADDED/,/^## [A-Z]/ {if (/### Requirement:/) count++} END {print count}' \
    spec/changes/{change-id}/specs/**/*.md

Requirement Format Validation

Check Requirement Headers

# List all requirement headers
grep -n "### Requirement:" spec/changes/{change-id}/specs/**/*.md

Expected format: ### Requirement: Descriptive Name

Validate Scenario Format

# Check for scenarios (must be 4 hashtags)
grep -n "#### Scenario:" spec/changes/{change-id}/specs/**/*.md

Expected format: #### Scenario: Descriptive Name

Count Requirements vs Scenarios

# Count requirements
REQS=$(grep -c "### Requirement:" spec/changes/{change-id}/specs/**/*.md)

# Count scenarios
SCENARIOS=$(grep -c "#### Scenario:" spec/changes/{change-id}/specs/**/*.md)

echo "Requirements: $REQS"
echo "Scenarios: $SCENARIOS"
echo "Ratio: $(echo "scale=1; $SCENARIOS/$REQS" | bc)"

Expected: Ratio >= 2.0 (at least 2 scenarios per requirement)

Check for SHALL Keyword

# Verify requirements use SHALL (binding requirement indicator)
grep -c "SHALL" spec/changes/{change-id}/specs/**/*.md

Expected: At least as many SHALL as requirements

Complete Validation Workflow

Pre-Submit Validation Script

#!/bin/bash
# Validate change proposal structure

CHANGE_ID="$1"
BASE_PATH="spec/changes/$CHANGE_ID"

echo "Validating proposal: $CHANGE_ID"
echo "================================"

# 1. Directory exists
if [ ! -d "$BASE_PATH" ]; then
    echo "✗ Change directory not found"
    exit 1
fi
echo "✓ Change directory exists"

# 2. Required files exist
for file in proposal.md tasks.md; do
    if [ ! -f "$BASE_PATH/$file" ]; then
        echo "✗ Missing $file"
        exit 1
    fi
    echo "✓ Found $file"
done

# 3. Proposal has required sections
for section in "## Why" "## What Changes" "## Impact"; do
    if ! grep -q "$section" "$BASE_PATH/proposal.md"; then
        echo "✗ proposal.md missing section: $section"
        exit 1
    fi
done
echo "✓ Proposal has required sections"

# 4. Tasks file has numbered tasks
TASK_COUNT=$(grep -c "^[0-9]\+\." "$BASE_PATH/tasks.md" || echo "0")
if [ "$TASK_COUNT" -lt 3 ]; then
    echo "✗ tasks.md has insufficient tasks ($TASK_COUNT)"
    exit 1
fi
echo "✓ Found $TASK_COUNT tasks"

# 5. Spec deltas exist
DELTA_COUNT=$(find "$BASE_PATH/specs" -name "*.md" 2>/dev/null | wc -l)
if [ "$DELTA_COUNT" -eq 0 ]; then
    echo "✗ No spec delta files found"
    exit 1
fi
echo "✓ Found $DELTA_COUNT spec delta file(s)"

# 6. Delta operations exist
OPERATIONS=$(grep -h "## ADDED\|MODIFIED\|REMOVED" "$BASE_PATH/specs"/**/*.md 2>/dev/null | wc -l)
if [ "$OPERATIONS" -eq 0 ]; then
    echo "✗ No delta operations found"
    exit 1
fi
echo "✓ Found $OPERATIONS delta operation(s)"

# 7. Requirements have scenarios
REQ_COUNT=$(grep -h "### Requirement:" "$BASE_PATH/specs"/**/*.md 2>/dev/null | wc -l)
SCENARIO_COUNT=$(grep -h "#### Scenario:" "$BASE_PATH/specs"/**/*.md 2>/dev/null | wc -l)

if [ "$REQ_COUNT" -eq 0 ]; then
    echo "✗ No requirements found"
    exit 1
fi

if [ "$SCENARIO_COUNT" -lt "$REQ_COUNT" ]; then
    echo "⚠ Warning: Fewer scenarios ($SCENARIO_COUNT) than requirements ($REQ_COUNT)"
    echo "  Recommendation: At least 2 scenarios per requirement"
else
    echo "✓ Found $REQ_COUNT requirement(s) with $SCENARIO_COUNT scenario(s)"
fi

echo "================================"
echo "✓ Validation passed"

Usage:

bash validate-proposal.sh add-user-auth

Common Issues and Fixes

Issue: Missing Scenarios

Detection:

# Find requirements without scenarios
awk '/### Requirement:/ {req=$0; getline; if ($0 !~ /#### Scenario:/) print req}' \
    spec/changes/{change-id}/specs/**/*.md

Fix: Add scenarios for each requirement

Issue: Wrong Scenario Level

Detection:

# Find scenarios with wrong hashtag count (not exactly 4)
grep -n "^###\? Scenario:\|^#####+ Scenario:" spec/changes/{change-id}/specs/**/*.md

Fix: Scenarios must use exactly 4 hashtags: #### Scenario:

Issue: Missing Delta Operations

Detection:

# Check if file has requirements but no delta header
for file in spec/changes/{change-id}/specs/**/*.md; do
    if grep -q "### Requirement:" "$file" && \
       ! grep -q "## ADDED\|MODIFIED\|REMOVED" "$file"; then
        echo "Missing delta operation in: $file"
    fi
done

Fix: Add appropriate delta operation header (ADDED/MODIFIED/REMOVED)

Quick Validation Commands

One-Liner: Full Structure Check

# Quick validation of change structure
CHANGE_ID="add-user-auth" && \
test -f spec/changes/$CHANGE_ID/proposal.md && \
test -f spec/changes/$CHANGE_ID/tasks.md && \
grep -q "## ADDED\|MODIFIED\|REMOVED" spec/changes/$CHANGE_ID/specs/**/*.md && \
grep -q "### Requirement:" spec/changes/$CHANGE_ID/specs/**/*.md && \
grep -q "#### Scenario:" spec/changes/$CHANGE_ID/specs/**/*.md && \
echo "✓ All validations passed" || echo "✗ Validation failed"

Show Proposal Summary

# Display proposal overview
CHANGE_ID="add-user-auth"
echo "Proposal: $CHANGE_ID"
echo "Files: $(find spec/changes/$CHANGE_ID -type f | wc -l)"
echo "Tasks: $(grep -c "^[0-9]\+\." spec/changes/$CHANGE_ID/tasks.md)"
echo "Requirements: $(grep -h "### Requirement:" spec/changes/$CHANGE_ID/specs/**/*.md | wc -l)"
echo "Scenarios: $(grep -h "#### Scenario:" spec/changes/$CHANGE_ID/specs/**/*.md | wc -l)"

Validation Checklist

Before presenting proposal to user:

Manual Checks:
- [ ] Change ID is descriptive and unique
- [ ] proposal.md Why section explains the problem
- [ ] proposal.md What section lists concrete changes
- [ ] proposal.md Impact section identifies affected areas
- [ ] tasks.md has 5-15 concrete, testable tasks
- [ ] Tasks are ordered by dependencies

Automated Checks:
- [ ] Directory structure exists
- [ ] Required files present (proposal.md, tasks.md, spec-delta.md)
- [ ] Delta operations present (ADDED/MODIFIED/REMOVED)
- [ ] Requirements follow format: `### Requirement: Name`
- [ ] Scenarios follow format: `#### Scenario: Name`
- [ ] At least 2 scenarios per requirement
- [ ] Requirements use SHALL keyword

Run all automated checks:

# Execute validation script
bash validate-proposal.sh {change-id}

Proposal: {Change Title}

Why

[Describe the problem or opportunity]

Context:

• [Background point 1]
• [Background point 2]

Current state: [How things work now]

Desired state: [How things should work]

What Changes

• [Change 1]
• [Change 2]
• [Change 3]

Impact

Affected Specifications

• spec/specs/{capability}/spec.md - [What changes]

Affected Code

• src/{module} - [What needs implementation]

User Impact

• [How this affects users, if applicable]

API Changes

• [Breaking changes, if any]
• [New endpoints, if any]

Migration Required

• [ ] Database migration
• [ ] API version bump
• [ ] User communication needed
• [ ] Documentation updates

Timeline Estimate

[Rough estimate: small/medium/large, or number of days]

Risks

• [Risk 1 and mitigation]
• [Risk 2 and mitigation]

Spec Delta: {Capability Name}

This file contains specification changes for spec/specs/{capability}/spec.md.

ADDED Requirements

Requirement: {Requirement Name}

{WHEN/IF clause describing trigger} the system SHALL {action and outcome}.

Scenario: {Positive Scenario Name}

GIVEN {preconditions} WHEN {action} THEN {expected outcome} AND {additional outcome}

Scenario: {Error Scenario Name}

GIVEN {error preconditions} WHEN {action} THEN {expected error handling}

---

MODIFIED Requirements

Requirement: {Existing Requirement Name}

Previous: {Brief summary of old behavior}

{Complete updated requirement text in EARS format} WHEN {trigger}, the system SHALL {new action and outcome}.

Scenario: {Updated Scenario Name}

GIVEN {new preconditions} WHEN {action} THEN {new expected outcome}

---

REMOVED Requirements

Requirement: {Deprecated Requirement Name}

Reason for removal: {Why this is being deprecated}

Migration path: {How users should adapt}

---

Notes

• Use ADDED for completely new capabilities
• Use MODIFIED when changing existing behavior (include full updated text)
• Use REMOVED for deprecated features
• Always include scenarios for each requirement
• Consider both positive and error cases

Implementation Tasks

Phase 1: Foundation

1. [Setup task - database schema, dependencies, etc.] 2. [Core infrastructure task]

Phase 2: Core Implementation

3. [Main feature task 1] 4. [Main feature task 2] 5. [Main feature task 3]

Phase 3: Integration

6. [API integration task] 7. [UI integration task]

Phase 4: Quality & Documentation

8. [Unit tests for X] 9. [Integration tests for Y] 10. [Update API documentation] 11. [Update user documentation]

Phase 5: Deployment

12. [Database migration] 13. [Deploy to staging] 14. [Validation testing] 15. [Deploy to production]

---

Notes:

• Each task should be independently completable
• Include test tasks for each major component
• Order tasks by dependencies
• Keep tasks concrete and verifiable