[Feature Request] Support schema selection in propose/new skills and commands #770

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 #770. Here's a summary of what I found and included:

   Key finding: The propose skill (src/core/templates/workflows/propose.ts) hardcodes openspec new change "<name>" with no schema flag and no schema selection step at all. Meanwhile, the new-change skill (src/core/templates/workflows/new-change.ts) already has a "Determine the workflow schema" step that handles --schema reactively — but doesn't proactively offer selection.

   The comment covers:

   • Affected files with exact line numbers for the hardcoded invocations and the missing schema step
   • Existing building blocks — openspec schemas --json, listSchemasWithInfo(), validateSchemaExists(), and the full schema resolution chain are all already implemented
   • Suggested approach — mirror the new-change skill's existing Step 2 into the propose skill, and optionally add proactive schema selection using AskUserQuestion when multiple schemas are detected
   • Related issues — /opsx:propose command and openspec-propose skills are missing after update to 1.2.0 #769/Version 1.2.0 is missing /opsx:propose #755 (propose skill missing in v1.2.0), [Proposal/Enhancement] Hardcoded spec format prevents custom schemas from working #666 (custom schema friction), New Schema Recommendation #706 (schema flexibility), and merged PRs feat(cli): add schema management commands #525/feat(resolver): add project-local schema support #522 that established the schema management infrastructure
   • Test considerations — parity test hashes that will need updating, and existing schema CLI tests to build on

   ---

   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 Triage & Codebase Analysis

   Thanks for the detailed write-up. Here's a breakdown of the relevant code and some notes to help get started on this.

   Affected Files

   opsx:propose / openspec-propose skill — src/core/templates/workflows/propose.ts

   • getOpsxProposeSkillTemplate() (line 9) and getOpsxProposeCommandTemplate() (line 118)
   • Both hardcode openspec new change "<name>" at lines 39 and 150 respectively, with no --schema flag and no schema selection step.
   • This is the core of the issue: there is no Step 2 to determine the workflow schema, unlike the new-change skill.

   opsx:new / openspec-new-change skill — src/core/templates/workflows/new-change.ts

   • getNewChangeSkillTemplate() (line 9) and getOpsxNewCommandTemplate() (line 82)
   • These already have a "Determine the workflow schema" step (lines 28–36 in the skill, lines 103–111 in the command) that:
     • Uses the default schema unless the user explicitly requests a different one
     • Responds to "show workflows" / "what workflows" by running openspec schemas --json
     • Passes --schema <name> when a non-default schema is requested
   • However, as the issue notes, this is reactive only — it doesn't proactively offer selection when multiple schemas are detected.

   Existing Building Blocks

   These utilities are already available and can be leveraged:

   Utility	Location	Purpose
   openspec schemas --json	src/commands/workflow/schemas.ts:22-46	Lists all schemas with name, description, artifacts, and source
   listSchemasWithInfo()	src/core/artifact-graph/resolver.ts:224-268	Programmatic schema discovery (returns SchemaInfo[])
   listSchemas()	src/core/artifact-graph/resolver.ts:161-206	Returns schema name list from all 3 tiers (project → user → package)
   validateSchemaExists()	src/commands/workflow/shared.ts:152-161	Validates schema name, throws with available schemas on failure
   resolveSchemaForChange()	src/utils/change-metadata.ts:162-196	4-tier resolution: explicit flag → .openspec.yaml → config.yaml → 'spec-driven' default
   DEFAULT_SCHEMA	src/commands/workflow/shared.ts:44	Constant: 'spec-driven'

   The CLI already fully supports --schema via src/commands/workflow/new-change.ts:38-40 and src/cli/index.ts:493-508.

   Suggested Implementation Approach

   For propose (the main gap):

   Add a schema determination step between the current Step 1 (get user input) and Step 2 (create the change directory) in both getOpsxProposeSkillTemplate() and getOpsxProposeCommandTemplate(). The new-change skill's existing Step 2 (lines 28–36 of new-change.ts) can serve as a direct template for this.

   Minimal change:

   1. Insert a new step in the propose instructions that mirrors the "Determine the workflow schema" block from new-change.ts
   2. Update the openspec new change "<name>" invocation at line 39/150 to conditionally include --schema <name>

   For proactive schema selection (enhancement):

   To address the "proactively ask" behavior when multiple schemas exist:

   1. Add a step that runs openspec schemas --json early in the flow
   2. If more than one schema is returned, use the AskUserQuestion tool to present the choices
   3. This would apply to both propose and new-change skills

   Related Issues & PRs

   • /opsx:propose command and openspec-propose skills are missing after update to 1.2.0 #769 / Version 1.2.0 is missing /opsx:propose #755 — Report that /opsx:propose is missing after updating to v1.2.0, which may need to be resolved first or in tandem
   • [Proposal/Enhancement] Hardcoded spec format prevents custom schemas from working #666 — "Hardcoded spec format prevents custom schemas from working" — related friction with custom schemas
   • New Schema Recommendation #706 — "New Schema Recommendation" — broader schema flexibility request
   • PR feat(cli): add schema management commands #525 (merged) — Added schema management CLI commands (schema which, schema validate, schema fork, schema init)
   • PR feat(resolver): add project-local schema support #522 (merged) — Added project-local schema support, establishing the 3-tier resolution

   Test Considerations

   • Skill template parity tests exist at test/core/templates/skill-templates-parity.test.ts — the content hashes for getOpsxProposeSkillTemplate (line 53) and getOpsxProposeCommandTemplate (line 54) will need to be updated after any instruction text changes.
   • Schema handling in the CLI is tested at test/commands/artifact-workflow.test.ts (lines 154-173 for --schema support, lines 659-698 for config/CLI schema precedence).

   This appears to not be a duplicate of any existing issue. The closest is #666, but that's about schema format constraints rather than schema selection UX in skills.
3. clay-good

   closed this as completedin #1504on Aug 4, 2026