About open-spec-propose
open-spec-propose is a workflow skill for turning a requested change into proposal, design, and task artifacts. It is intended for projects using the OpenSpec workflow and leaves implementation to the separate open-spec-apply skill.
Key features
- 01Derive kebab-case change names
- 02Create proposal, design, and task files
- 03Check readiness for implementation
- 04Keep working artifacts separate from canonical specs
Use cases
- 01Document the goals and scope of a requested change
- 02Plan architecture and implementation steps before coding
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ aircury/ ai-framework --skill open-spec-proposeAfter installing, type/open-spec-proposein Claude Code to confirm it loaded.
Details
From the project READMEPropose a new change and create optional working artifacts.
I'll create a change with artifacts:
- proposal.md (what & why)
- design.md (how)
- tasks.md (implementation steps)
When ready to implement, use the open-spec-apply skill
Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.
Steps
-
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.
-
Create the change directory
Create
specs/changes/<name>/.specs/changes/is gitignored. It is optional workflow scaffolding. Onlyspecs/features/is canonical and versioned. -
Create the working artifacts
Use the TodoWrite tool to track progress.
Create:
proposal.md: problem, goals, non-goals, scopedesign.md: architecture, decisions, tradeoffs, boundariestasks.md: concrete implementation steps with checkboxes
Artifact rules:
- Keep them technology-aware if helpful for delivery.
- Keep them aligned with
AGENTS.mdand the enabled capability docs. - Use
specs/features/as the canonical behavior baseline. - If the change modifies existing behavior, reference the affected canonical specs.
- If the user already gave enough detail, write the artifacts directly instead of asking more questions.
-
Ensure the change is implementation-ready
Before finishing, make sure:
proposal.mdexplains why the change exists.design.mdexplains the intended approach and boundaries.tasks.mdcontains an ordered execution plan.- The change name and artifacts are specific enough that the
open-spec-applyskill can execute them.
Output
After completing all artifacts, summarise:
- Change name and location
- List of artifacts created with brief descriptions
- What's ready: "All artifacts created! Ready for implementation."
- Prompt: "Use the
open-spec-applyskill to implement. When done, use theopen-spec-completeskill to syncspecs/features/and clean up these ephemeral artifacts."
Guardrails
- Create all three core artifacts unless the user explicitly asks for less
- 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
- Never treat working artifacts as canonical specs