tomevault-io 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 worktree tasks (worktree creation first, PR last, cleanup after merge), 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 worktree workflow: worktree creation first task, PR creation last task, worktree cleanup after merge — never switch the primary checkout away from
dev - Only create GitHub issues in the target repository specified by the plan
Converted and distributed by TomeVault — claim your Tome and manage your conversions.