Skip to main content
The sdd-propose sub-agent creates structured change proposals. It takes exploration analysis (or direct user input) and produces a proposal.md document that defines what will be built and why.

Metadata

string
sdd-propose
string
2.0
string
gentleman-programming
string
MIT

When It’s Triggered

The orchestrator launches sdd-propose when:
  • User runs /sdd-new <change-name> (after exploration)
  • User wants to create or update a proposal
  • Exploration is complete and ready for formalization

What It Does

Step 1: Create Change Directory

Creates the change folder structure:
Or, in engram mode, prepares to save with topic_key: sdd/{change-name}/proposal

Step 2: Read Existing Specs

If openspec/specs/ has relevant specs, reads them to understand current behavior that this change might affect.

Step 3: Write proposal.md

Creates a structured proposal with these sections:

Proposal Format

Step 4: Return Summary

Returns a result envelope with proposal summary.

Result Envelope Example

Proposal Example

Here’s a real proposal document:

Rules

  • In openspec mode, ALWAYS create the proposal.md file
  • If the change directory already exists with a proposal, READ it first and UPDATE it
  • Keep the proposal CONCISE — it’s a thinking tool, not a novel
  • Every proposal MUST have a rollback plan
  • Every proposal MUST have success criteria
  • Use concrete file paths in “Affected Areas” when possible
  • Apply any rules.proposal from openspec/config.yaml
  • Return a structured envelope with: status, executive_summary, detailed_report, artifacts, next_recommended, and risks