openspec-sync-specs

Synchroniser les spécifications delta à partir d'une modification vers les spécifications principales. Utiliser lorsque l'utilisateur souhaite mettre à jour les spécifications principales avec les modifications d'une spécification delta, sans archiver la modification.

npx skills add https://github.com/rivet-dev/rivet --skill 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).

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. Find delta specs

    Look for delta spec files in openspec/changes/<name>/specs/*/spec.md.

    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.

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

    For each capability with a delta spec at openspec/changes/<name>/specs/<capability>/spec.md:

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

Plus de skills de rivet-dev

ai-agent
rivet-dev
Construisez un backend d'agent IA avec mémoire persistante : un acteur Rivet par conversation, gestion des messages en file d'attente et diffusion des réponses LLM en temps réel sous forme d'événements.
official
ai-agent-workspace
rivet-dev
Offrez à chaque agent IA son propre ordinateur : un espace de travail persistant avec un système de fichiers, des processus, des shells, un réseau et des sessions d’agent sur un environnement léger en processus…
official
chat-room
rivet-dev
Construisez un backend de salon de discussion en temps réel avec Rivet Actors : un acteur par salon, un historique des messages basé sur SQLite, et une diffusion WebSocket à chaque client connecté.
official
collaborative-text-editor
rivet-dev
Construire un backend d'éditeur de texte collaboratif avec les CRDT Yjs et les acteurs Rivet : des acteurs par document relaient les mises à jour de synchronisation et de conscience et persistent les instantanés.
official
cron-jobs
rivet-dev
Tâches cron durables avec Rivet Actors : les minuteurs schedule.after et schedule.at survivent aux redémarrages et aux pannes, plus le réarmement des tâches récurrentes et les gestionnaires idempotents.
official
live-cursors
rivet-dev
Curseurs en direct et présence multijoueur avec Rivet Actors : état du curseur par connexion, mises à jour en temps réel via événements ou WebSockets bruts, et limitation de débit.
official
per-tenant-database
rivet-dev
Isolation des données multi-locataire avec un Rivet Actor par locataire : la clé de l'actor est l'identifiant du locataire, de sorte que chaque locataire dispose de son propre ensemble de données isolé et de ses propres migrations.
official
rivetkit-client-javascript
rivet-dev
Client JavaScript pour se connecter aux Rivet Actors avec des connexions sans état ou avec état. Prend en charge les environnements navigateur, Node.js et Bun avec détection automatique des points de terminaison via des variables d'environnement ou une configuration explicite. Propose deux modes d'interaction : les appels d'action sans état pour des requêtes indépendantes et les connexions avec état avec abonnements aux événements en temps réel. Inclut un accès HTTP et WebSocket de bas niveau pour les acteurs implémentant les gestionnaires onRequest ou onWebSocket. Fournit un accès basé sur des tableaux composés...
official