Two workflows for managing OpenSpec changes at the proposal stage.
Input: Optionally specify a workflow name (create or validate) and a target (plan path or change ID). If omitted, ask the user which workflow they need.
Workflow Selection
Determine which workflow to run:
| User Intent | Workflow | Reference |
|---|---|---|
| Turn a plan into an OpenSpec change | Create Change from Plan | references/create-change-from-plan.md |
| Validate a change before implementation | Validate Change | references/validate-change.md |
If the user's intent is unclear, use AskUserQuestion to ask which workflow they need.
Create Change from Plan
Turns an implementation plan document into a fully formed OpenSpec change with proposal, specs, design, and tasks — including GitHub issue creation for public repos.
When to use: The user has a plan document (typically in specfact-cli-internal/docs/internal/implementation/) and wants to create an OpenSpec change from it.
Load references/create-change-from-plan.md and follow the full workflow.
Key steps:
- •Select and parse the plan document
- •Cross-reference against existing plans and validate targets
- •Resolve any issues interactively
- •Create the OpenSpec change via
opsx:ffskill - •Review and improve: enforce TDD-first, add git workflow tasks (branch first, PR last), validate against
openspec/config.yaml - •Create GitHub issue (public repos only)
Validate Change
Performs dry-run simulation to detect breaking changes, analyze dependencies, and verify format compliance before implementation begins.
When to use: The user wants to validate that an existing change is safe to implement — check for breaking interface changes, missing dependency updates, and format compliance.
Load references/validate-change.md and follow the full workflow.
Key steps:
- •Select the change (by ID or interactive list)
- •Parse all change artifacts (proposal, tasks, design, spec deltas)
- •Simulate interface changes in a temporary workspace
- •Analyze dependencies and detect breaking changes
- •Present findings and get user decision if breaking changes found
- •Run
openspec validate <change-id> --strict - •Create
CHANGE_VALIDATION.mdreport
Guardrails
- •Read
openspec/config.yamlfor project context and rules - •Read
CLAUDE.mdfor project conventions - •Never modify production code during validation — use temp workspaces
- •Never proceed with ambiguities — ask for clarification
- •Enforce TDD-first ordering in tasks (per config.yaml)
- •Enforce git workflow: branch creation first task, PR creation last task
- •Only create GitHub issues in the target repository specified by the plan