core profile: openspec-update-change references /openspec-continue-change and /openspec-new-change, neither of which core installs

[skovtunenko]

Disclosure: I used an AI assistant to investigate this and draft the report. The repro below ran on my machine; the counts and quotes are verbatim from its output.

Summary

On the default core profile, two generated skills reference workflows core never installs. openspec-update-change names /openspec-continue-change 5 times and /openspec-new-change twice. openspec-apply-change names /openspec-continue-change once. CLI 1.11.0.

Same class as #963, #913 and #1409. The umbrella, #919, is still open.

Repro

openspec init --tools claude --profile core --no-animation --force

grep -c '/openspec-continue-change' .claude/skills/openspec-update-change/SKILL.md  # 5
grep -c '/openspec-new-change'      .claude/skills/openspec-update-change/SKILL.md  # 2
grep -c '/openspec-continue-change' .claude/skills/openspec-apply-change/SKILL.md   # 1

Skills written: openspec-propose, openspec-explore, openspec-apply-change, openspec-update-change, openspec-sync-specs, openspec-archive-change. No continue, no new.

The part that actually breaks

update-change refuses to create a missing artifact and hands off to a workflow that is not there.

line 74: Artifacts still missing -> suggest /openspec-continue-change to create them.

line 89: Do not advance the build frontier: no new artifacts, no new files under glob artifacts - that is /openspec-continue-change's job.

On core that is a closed loop. Line 19 does carry a fallback:

/openspec-continue-change is an optional workflow and may not be installed. Before suggesting it anywhere below, verify that it is available. If it is unavailable, openspec status ... shows the next artifact and openspec instructions ... explains how to create it.

One sentence, 70 lines above the two spots where the agent hits the wall, and it delegates the availability check to the model. Line 91 has the same shape for /openspec-new-change.

#1733 is adjacent but not a fix. It opens up the partially-populated-glob case and states: "An artifact with no existing output remains outside update and routes to continue."

Why the generator emits it

src/utils/command-references.ts exists for exactly this. Its own docstring:

Converts /opsx:<command> patterns to /openspec-<skill> so that generated skills do not reference commands that were never generated.

It branches on tool id and on delivery. It never branches on profile. COMMAND_TO_SKILL_NAME maps all 12 workflows, and getProfileWorkflows() from src/core/profiles.ts is not called anywhere in the module. So /opsx:continue in a template is rewritten to /openspec-continue-change regardless of whether continue was installed.

This is the same drift the file already warns about on the tool axis: "the list drifted and left 16 tools advertising commands their palettes never registered (#727, #1307)."

Prior art, and how each was settled

Issue	Instance	Outcome
#963	apply-change -> continue-change	Closed via #1437. Inline CLI fallback added, reference kept. That is why line 54 still reads as it does.
#913	archive-change -> sync-specs	Settled the other way: sync was added to CORE_WORKFLOWS.
#1409	openspec update console output	Fixed by making the output profile-aware.
#919	umbrella	Open since April. Criteria: "Default profile workflows are self-sufficient. No required flow can call missing skills in default mode."

Three instances, closed one at a time, three different remedies. update-change is the fourth.

Suggested fix

Filter at generation time. getTransformerForTool() already has the context to take the active workflow set; drop or rewrite references outside it rather than emitting them and asking the agent to re-check at runtime. That also closes #919.

Narrower option: apply the #963 treatment to update-change lines 62, 74 and 89, which at least removes the dead end.

Environment

• @fission-ai/openspec 1.11.0
• profile core, delivery skills
• tool: claude
• macOS, Darwin 25.6.0

[skovtunenko]

Config on the machine that produced the repro, from openspec config list (telemetry id redacted):

featureFlags: {}
profile: core
delivery: skills
telemetry:
  noticeSeen: true
completionTipSeen: true

Profile settings:
  profile: core (explicit)
  delivery: skills (explicit)
  workflows: propose, explore, apply, update, sync, archive (from core profile)

Nothing custom. continue and new are absent from the resolved workflow set, and the skills tree on disk matches that set exactly. Both are still named in the generated bodies.

delivery: skills is worth noting, because it is the code path that emits them. With no /opsx:* command files generated, getTransformerForTool() takes its first branch, getSkillReferenceTransformer() returns transformToSkillReferences, and every /opsx:continue in the template is rewritten to /openspec-continue-change with no check against the resolved workflow set.

[clay-good]

Fix opened: #1775

Took the generation-time filter you suggested. command-references.ts keeps deciding how a reference is spelled; a new optional-workflow.ts decides whether it is emitted, resolved in getSkillTemplates()/getCommandTemplates() — the one place every generation path already funnels the resolved workflow set through. Your repro now returns 0/0/0, and a new test generates the whole core skill and command set and fails if any body names an uninstalled workflow.

Scoped to the default profile (which is what #919's success criteria are worded for); arbitrary custom subsets can still dangle and are called out in the PR.