/opsx:propose command and openspec-propose skills are missing after update to 1.2.0 #769

Activity

1. 21st-connector commented on Feb 27, 2026

   

   21st-connectorbot

   on Feb 27, 2026 – with 21st - Connector

   Last edited by 21st-connector

   Contributor

   More actions

   Task completed.

   The enrichment comment has been posted on issue #769. Here's a summary of what was found:

   Root cause: The migration logic in src/core/migration.ts:92-131 scans disk for existing workflow artifacts when upgrading from pre-1.2.0. Since propose is new in v1.2.0, it doesn't exist on disk yet, so the migration sets profile: 'custom' with only old workflows — permanently excluding propose from generation.

   Duplicate: This is effectively a duplicate of closed issue #755, which described the same problem.

   Workaround: Run openspec config profile core && openspec update to switch to the core profile which includes propose.

   Suggested fix: The migration could auto-include new CORE_WORKFLOWS entries during upgrade rather than only preserving what was already on disk.

   ---

   View full conversation

   Powered by 1Code
2. 21st-connector commented on Feb 27, 2026

   

   21st-connectorbot

   on Feb 27, 2026 – with 21st - Connector

   Contributor

   More actions

   Issue Analysis

   Likely Duplicate

   This appears to be a duplicate of #755 ("Version 1.2.0 is missing /opsx:propose"), which was closed. Both describe the same symptom: /opsx:propose is referenced but not generated after openspec init or openspec update on v1.2.0.

   Root Cause

   The propose workflow template is fully implemented and registered in the codebase — the issue is in the migration path for users upgrading from pre-1.2.0.

   When an existing user (who installed before v1.2.0) runs openspec init or openspec update, the migration logic at src/core/migration.ts:92-131 runs first:

   1. migrateIfNeeded() checks if the global config (~/.config/openspec/config.json) has a profile field.
   2. If no profile is set (pre-1.2.0 config), it scans the disk for installed workflow artifacts (lines 112-114).
   3. Since propose is new in v1.2.0, it doesn't exist on disk yet, so it's excluded from the detected workflows.
   4. The migration sets profile: 'custom' with only the old workflows (line 122-123).
   5. All subsequent init/update calls respect this custom profile via src/core/profiles.ts:46-47 and never generate propose.

   A hint is printed at line 130: "New in this version: /opsx:propose. Try 'openspec config profile core' for the streamlined experience." — but this is easy to miss in the output.

   Key Files

   File	Relevance
   src/core/migration.ts:92-131	Migration logic that sets profile: 'custom' without propose
   src/core/profiles.ts:14	CORE_WORKFLOWS — confirms propose IS in the core profile
   src/core/profiles.ts:42-50	getProfileWorkflows() — custom profile returns only stored workflows
   src/core/init.ts:517-521	Init reads profile from global config, filters templates
   src/core/update.ts:94-100	Update runs migration then reads profile config
   src/core/templates/workflows/propose.ts	The propose skill/command templates (fully implemented)
   src/core/shared/skill-generation.ts:68	Propose registered in getSkillTemplates()
   src/core/shared/tool-detection.ts:25,44	Propose registered in SKILL_NAMES and COMMAND_IDS

   Workaround

   Switch to the core profile, which includes propose by default:

   openspec config profile core
   openspec update

   Or add propose to your custom profile:

   openspec config profile custom --workflows propose,explore,apply,archive,...
   openspec update

   Potential Fix

   The migration in src/core/migration.ts could be improved to automatically include new CORE_WORKFLOWS entries that were introduced since the user's last version. For example, at line 123, before saving:

   // Auto-include new core workflows that didn't exist in previous versions
   import { CORE_WORKFLOWS } from './profiles.js';
   const newCoreWorkflows = CORE_WORKFLOWS.filter(w => !installedWorkflows.includes(w));
   config.workflows = [...installedWorkflows, ...newCoreWorkflows];

   Alternatively, the migration could default to the core profile instead of custom and let users opt into expanded workflows, rather than the other way around.
3. clay-good

   added

   bugSomething isn't workingSomething isn't working

   on Jun 29, 2026
4. clay-good commented on Aug 3, 2026

   

   clay-good

   on Aug 3, 2026

   Collaborator

   More actions

   Closing this as an exact duplicate of #755, where the same v1.2.0 upgrade behavior was diagnosed and answered by a maintainer.

   The two reports have the same symptom and cause: OpenSpec preserves an upgrading user's already-installed workflows as a custom profile, so the newly introduced propose workflow is not silently added. The canonical maintainer answer is here:

   #755 (comment)

   The supported resolution is:

   openspec config profile
   # select the core profile, or add "propose" to a custom workflow selection
   openspec update

   Proof on current main:

   • The migration still deliberately preserves the detected workflows and prints the profile guidance: src/core/migration.ts.
   • The current CLI guide documents openspec config profile, its core/custom choices, and the subsequent update flow: docs/cli.md.
   • I reran the current migration and init suites; all 87 tests passed, including the preservation and “new in this version” guidance cases.

   No information is being discarded: #755 retains the diagnosis, workaround, suggestions, and maintainer decision. This issue adds the same report without a distinct remaining requirement.
5. clay-good

   closed this as not plannedon Aug 3, 2026