openspec-sync-specs

작성자: rivet-dev

델타 스펙의 변경 사항을 메인 스펙에 동기화합니다. 사용자가 변경 사항을 보관하지 않고 델타 스펙의 변경 사항으로 메인 스펙을 업데이트하려는 경우 사용합니다.

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

rivet-dev의 다른 스킬

multiplayer-game
rivet-dev
멀티플레이어 게임 구축을 위한 실용적 패턴: 매치메이킹, 틱 루프, 실시간 상태, 관심 관리, 검증. 10가지 게임 유형(배틀로얄, 아레나, IO 스타일, 오픈 월드, 파티, 물리 2D/3D, 랭크, 턴제, 방치형)에 대한 시작 코드와 아키텍처 패턴, 액터 토폴로지, 생명주기 다이어그램, 넷코드 전략 포함. 고정 실시간 루프 대 액션 기반 업데이트, 물리 엔진 선택(Rapier 2D/3D), 공간... 등 서버 시뮬레이션 기본 사항 다룸.
rivetkit
rivet-dev
AI 에이전트, 멀티플레이어 앱, 워크플로 자동화를 위한 장기 실행 상태 저장 컴퓨팅입니다. 액터는 데이터베이스 왕복 없이 요청 간 상태를 유지하는 영구적인 인메모리 프로세스로, 0에서 수백만 개의 동시 인스턴스까지 자동 확장됩니다. WebSocket 및 이벤트를 통한 내장 실시간 통신, 순서가 지정된 메시지 처리를 위한 내구성 있는 큐, 구조화된 데이터 쿼리를 위한 SQLite를 제공합니다. 상태는 Rivet Cloud 또는 자체 호스팅을 통해 재시작 및 충돌 후에도 유지됩니다...
ai-agent
rivet-dev
지속적 메모리를 갖춘 AI 에이전트 백엔드 구축: 대화당 하나의 Rivet Actor, 대기열 메시지 처리, 실시간 이벤트로 스트리밍되는 LLM 응답.
ai-agent-workspace
rivet-dev
모든 AI 에이전트에게 자신만의 컴퓨터를 부여하세요: 경량 인프로세스 상에서 파일 시스템, 프로세스, 셸, 네트워킹 및 에이전트 세션을 갖춘 영구 작업 공간입니다…
chat-room
rivet-dev
Rivet Actors로 실시간 채팅방 백엔드 구축: 방마다 하나의 액터, SQLite 기반 메시지 기록, 모든 연결된 클라이언트에 WebSocket 브로드캐스트.
collaborative-text-editor
rivet-dev
Yjs CRDT와 Rivet Actors를 사용하여 협업 텍스트 편집기 백엔드를 구축합니다: 문서별 액터가 동기화 및 인식 업데이트를 중계하고 스냅샷을 유지합니다.
cron-jobs
rivet-dev
Rivet Actors를 사용한 내구성 있는 크론 작업: schedule.after 및 schedule.at 타이머는 재시작과 충돌에도 유지되며, 반복 작업 재설정 및 멱등성 핸들러를 지원합니다.
live-cursors
rivet-dev
Rivet Actors를 사용한 라이브 커서 및 멀티플레이어 프레즌스: 연결별 커서 상태, 이벤트 또는 원시 WebSocket을 통한 실시간 업데이트, 스로틀링.