Catalog
fauziyasin-s2m4qw/openspec-sync-specs

fauziyasin-s2m4qw

openspec-sync-specs

Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.

v1.0LATEST
NewUpdated Oct 5, 2026

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).

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 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
    

    If status reports actionContext.mode: "workspace-planning", explain that workspace spec sync is not supported in this slice and STOP. Do not fall back to repo-local paths or edit linked repos.

  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 repo-local capability delta spec path returned by the CLI:

    a. Read the delta spec to understand the intended changes

    b. Read the main spec at openspec/specs/<capability>/spec.md (may not exist yet)

    c. Apply changes intelligently:

    ADDED Requirements:

    • If requirement doesn't exist in main spec → add it
    • If requirement already exists → update it to match (treat as implicit MODIFIED)

    MODIFIED Requirements:

    • Find the requirement in main spec
    • Apply the changes - this can be:
      • Adding new scenarios (don't need to copy existing ones)
      • Modifying existing scenarios
      • Changing the requirement 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 openspec/specs/<capability>/spec.md
    • Add Purpose section (can be brief, mark as TBD)
    • Add Requirements section with the ADDED requirements
  5. Show summary

    After applying all changes, summarize:

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

Delta Spec Format Reference

## ADDED Requirements

### Requirement: New Feature
The system SHALL do something new.

#### Scenario: Basic case
- **WHEN** user does X
- **THEN** system does Y

## MODIFIED Requirements

### Requirement: Existing Feature
#### Scenario: New scenario to add
- **WHEN** user does A
- **THEN** system does B

## REMOVED Requirements

### Requirement: Deprecated Feature

## RENAMED Requirements

- FROM: `### Requirement: Old Name`
- TO: `### Requirement: New Name`

Key Principle: Intelligent Merging

Unlike programmatic merging, you can apply partial updates:

  • To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
  • The delta represents intent, not a wholesale replacement
  • Use your judgment to merge changes sensibly

Output On Success

## Specs Synced: <change-name>

Updated main specs:

**<capability-1>**:
- Added requirement: "New Feature"
- Modified requirement: "Existing Feature" (added 1 scenario)

**<capability-2>**:
- Created new spec file
- Added requirement: "Another Feature"

Main specs are now updated. The change remains active - archive when implementation is complete.

Guardrails

  • Read both delta and main specs before making changes
  • Preserve existing content not mentioned in delta
  • If something is unclear, ask for clarification
  • Show what you're changing as you go
  • The operation should be idempotent - running twice should give same result

Overall Score

82/100

Grade

B

Good

Grades are signals, not a certification. Always review a skill yourself before use.

Safety

85

Quality

80

Clarity

85

Completeness

75

Summary

A spec synchronization skill that applies delta changes from OpenSpec change branches to main specification files. The agent reads delta specs in a structured format, intelligently merges them into main specs (adding, modifying, removing, or renaming requirements), and reports what was changed. It operates within a single OpenSpec project and requires explicit user confirmation before selecting changes.

Detected Capabilities

file readfile writeshell executionjson parsinguser promptingartifact path resolution

Trigger Keywords

Phrases that agents use to match this skill to user intent.

sync delta specsmerge requirement changesupdate openspecapply spec changescapability syncdelta to main

Risk Signals

INFO

Writes to openspec/specs/<capability>/spec.md within project scope

Step 4, File Operations
INFO

Executes openspec CLI commands (list, status) with user-controlled change names

Steps 1-2, CLI Commands
INFO

Creates new spec files if capability doesn't exist

Step 4d, File Creation

Use Cases

  • Apply feature requirement changes from a delta spec to production specs
  • Merge new scenario definitions into existing requirements without duplication
  • Rename or deprecate requirements across capability specs
  • Intelligently combine partial requirement updates across multiple capabilities
  • Maintain audit trail of spec changes by keeping delta specs linked to implementation changes

Quality Notes

  • Clear multi-step workflow with explicit user prompting guardrail (Step 1)
  • Well-documented delta spec format with examples (Delta Spec Format Reference section)
  • Intelligent merging logic explained (partial updates, scenario addition without duplication)
  • Guardrails section explicitly addresses safety concerns (idempotence, preservation of existing content, clarification on ambiguity)
  • Output format clearly defined to show what was changed and in what capability
  • Scope limitations well-defined (rejects workspace-planning mode, operates on repo-local paths only)
  • Strong emphasis on reading both specs before applying changes to prevent data loss
  • Error handling guidance for missing delta specs and missing change names
  • Potential improvement: No guidance on conflict resolution if delta requires contradictory changes
  • Potential improvement: No mention of how to handle malformed delta specs or invalid markdown
Model: claude-haiku-4-5-20251001Analyzed: Oct 5, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Use fauziyasin-s2m4qw/openspec-sync-specs in your dev environment

Command Palette

Search for a command to run...