openspec-sync-specs

Sync delta specs from a change to main specs.

This is an agent-driven operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).

Store selection: If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run openspec store list --json to discover registered store ids, then pass --store <id> on the commands that read or write specs and changes (new change, status, instructions, list, show, validate, archive, doctor, context). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local openspec/ root.

Input: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.

Steps

1. If no change name provided, prompt for selection

   Run openspec list --json --store "<store-id>" (omit the store option for repo-local work) to get available changes. Use the AskUserQuestion tool to let the user select.

   Show changes that have delta specs (under specs/ directory).

   IMPORTANT: Do NOT guess or auto-select a change. Always let the user choose.

2. Resolve change context

   Run:

   openspec status --change "<name>" --json --store "<store-id>"
   

3. Find delta specs

   Use artifactPaths.specs.existingOutputPaths from the status JSON as the list of delta spec files.

   Each delta spec file contains sections like:

   • ## ADDED Requirements - New requirements to add
   • ## MODIFIED Requirements - Changes to existing requirements
   • ## REMOVED Requirements - Requirements to remove
   • ## RENAMED Requirements - Requirements to rename (FROM:/TO: format)

   If no delta specs found, inform user and stop.

4. For each delta spec, apply changes to main specs

   For each concrete capability delta spec path returned by the selected store's status output:

   a. Read the delta spec to understand the intended changes

   b. Resolve and read the corresponding main spec from the selected OpenSpec root returned by the CLI (it may not exist yet). Never assume the current repository's openspec/specs directory when a store is active.

   c. Apply changes intelligently:

   ADDED Requirements:

   • If requirement doesn't exist in main spec → add it
   • If a requirement with the same normalized heading/identity already exists → merge only descriptions or scenarios explicitly changed by the delta; preserve all unmentioned content

   MODIFIED Requirements:

   • Find the requirement in main spec
   • Match scenarios by normalized scenario heading/identity
   • Add only scenarios that do not exist; update an existing scenario only when the delta explicitly changes that scenario
   • Change the requirement description only when the delta supplies a replacement description
   • Preserve scenarios/content not mentioned in the delta

   REMOVED Requirements:

   • Remove the entire requirement block from main spec

   RENAMED Requirements:

   • Find the FROM requirement, rename to TO

   d. Create new main spec if capability doesn't exist yet:

   • Create the concrete capability path under the selected root returned by the CLI
   • Add Purpose section (can be brief, mark as TBD)
   • Add Requirements section with only ADDED requirements that are not already present

   e. Verify idempotence:

   • Re-read the merged main spec and compare requirement/scenario identities
   • Confirm no duplicate headings were introduced and that applying the same delta again would produce no diff

5. Show summary

   After applying all changes, summarize:

   • Which capabilities were updated
   • What changes were made (requirements added/modified/removed/renamed)