openspec-propose

name	openspec-propose
description	Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
license	MIT
compatibility	Requires openspec CLI.
metadata	{"author":"openspec","version":"1.0","generatedBy":"1.2.0"}

Propose a new change — create the change and generate drafts of all artifacts in one step.

This is step ① of the OpenSpec + Superpowers workflow. The artifacts created here are drafts that get refined later:

• proposal.md — confirmed by the human in step ② (review)
• design.md — deepened by superpowers:brainstorming in step ③
• tasks.md — atomized by superpowers:writing-plans in step ③

When ready, run /opsx:apply <name> (which orchestrates ③④⑤).

---

Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.

Steps

1. If no clear input provided, ask what they want to build

   Use the AskUserQuestion tool (open-ended, no preset options) to ask:

   "What change do you want to work on? Describe what you want to build or fix."

   From their description, derive a kebab-case name (e.g., "add user authentication" → add-user-auth).

   IMPORTANT: Do NOT proceed without understanding what the user wants to build.

2. Size triage — recommend openspec-quick if the change looks small

   Before creating any files, check the description for "small change" signals:

   • Description short (< 50 chars) AND a single concrete action.
   • Phrases like: "修一下" / "加个字段" / "改个文案" / "fix" / "add a log" / "rename".
   • Bug-fix language: "不对" / "错" / "失败" / "throws" / "returns wrong".
   • User names a specific file/function and a single change to it.
   • You can imagine the diff < 50 lines without speculating.

   If 2 or more signals fire, do NOT create a change. Use AskUserQuestion:

   "This change looks small. The full OpenSpec + Superpowers cycle has 5+ steps of fixed overhead plus ~3 subagent calls per task — usually not worth it for small fixes. Recommend switching to /opsx:quick."

   Options:

   • Switch to /opsx:quick (recommended) — exit; tell user to re-run as /opsx:quick <original description>. Do NOT silently switch.
   • Continue with /opsx:propose anyway — proceed to step 3.
   • Let me re-describe in more detail — re-ask the input question, then re-run triage.

   If signals don't fire — proceed silently to step 3.

   Ask only once. If user picked "continue anyway" once, never re-prompt in the same propose run.

3. Create the change directory

   openspec new change "<name>"
   

   This creates a scaffolded change at openspec/changes/<name>/ with .openspec.yaml.

4. Get the artifact build order

   openspec status --change "<name>" --json
   

Output

After completing all artifacts, summarize:

• Change name and location
• List of artifacts created with brief descriptions
• What's drafted: "Drafts created — proposal.md, design.md, tasks.md."
• Prompt the user with the next two steps in the workflow:

Next:
  ②  Review proposal.md — does it capture the right intent?
  ③+④ Run `/opsx:apply <name>` — Superpowers will:
       • brainstorming → deepen design.md
       • writing-plans → atomize tasks.md into TDD steps
       • subagent-driven-development → execute task by task

This skill only produces drafts. The Superpowers skills invoked by /opsx:apply are what turn drafts into a buildable plan.

Artifact Creation Guidelines

• Follow the instruction field from openspec instructions for each artifact type
• The schema defines what each artifact should contain - follow it
• Read dependency artifacts for context before creating new ones
• Use template as the structure for your output file - fill in its sections
• IMPORTANT: context and rules are constraints for YOU, not content for the file
  • Do NOT copy <context>, <rules>, <project_context> blocks into the artifact
  • These guide what you write, but should never appear in the output

Guardrails

• Create ALL artifacts needed for implementation (as defined by schema's apply.requires)
• Always read dependency artifacts before creating a new one
• If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
• If a change with that name already exists, ask if user wants to continue it or create a new one
• Verify each artifact file exists after writing before proceeding to next