/opsx:apply suggests openspec-continue-change which is not installed on core profile

[kitimark]

Summary

The openspec-apply-change skill template references openspec-continue-change when the change state is "blocked" (missing artifacts). On the core profile (propose, explore, apply, archive), openspec-continue-change is not installed — the continue workflow is only available in custom profiles.

This is the same class of bug as #913 — a core profile template referencing a skill that isn't installed on the default profile.

Environment

• OpenSpec CLI: 1.2.0
• Profile: core (default)

Repro

1. openspec init with default profile
2. Create a change and skip some artifacts
3. Run /opsx:apply on the change
4. Agent reports state: "blocked" and suggests openspec-continue-change

Actual

Agent suggests using openspec-continue-change, a skill that doesn't exist on core profile.

Expected

Use concept-based guidance instead (e.g., "suggest continuing work on the missing artifacts") — following PR #726 decision #9.

Why this happens

Same root cause as #913 — PR #726 introduced the core profile but didn't audit all cross-skill references in templates.

src/core/templates/workflows/apply-change.ts line 49:

If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change

Related

• /opsx-archive can offer 'Sync now' even when openspec-sync-specs is not installed (core profile) #913 (/opsx:archive → openspec-sync-specs, same class of bug)
• Refactor skill packaging so optional workflows do not break default experiences #919 (umbrella: default profiles must be self-sufficient)
• PR feat: simplify skill installation with profiles and smart defaults #726 decision feat(cli): add update command #9 (concept-based guidance over cross-skill references)

[mvanhorn]

Submitted PR #1096. Switches the blocked-state suggestion text to profile-agnostic phrasing and updates parity-test hashes; new test asserts the core-only skill name is gone from the rendered template.