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 的更多技能

ai-agent
rivet-dev
建立一個具有持久記憶的AI agent後端:每個對話一個Rivet Actor、排隊消息處理、以及將串流LLM回應作為即時事件。
official
ai-agent-workspace
rivet-dev
賦予每個AI代理自己的電腦:一個持久的作業空間,包含檔案系統、程序、Shell、網路功能,以及輕量級進程內的代理會話…
official
chat-room
rivet-dev
使用 Rivet Actors 建立即時聊天室後端:每個房間一個 Actor、SQLite 支援的訊息歷史記錄,以及透過 WebSocket 向所有連線用戶端廣播。
official
collaborative-text-editor
rivet-dev
使用 Yjs CRDT 與 Rivet Actors 建構協作文字編輯器後端:每個文件的 Actor 負責轉發同步與感知更新,並持久化快照。
official
cron-jobs
rivet-dev
使用 Rivet Actors 實現持久化定時任務:schedule.after 和 schedule.at 計時器可在重啟與崩潰後保持狀態,並支援重新設定週期性任務與冪等處理器。
official
live-cursors
rivet-dev
使用 Rivet Actors 實現的即時游標與多人協作狀態:每個連線的游標狀態、透過事件或原始 WebSocket 的即時更新,以及節流控制。
official
per-tenant-database
rivet-dev
使用每個租戶一個 Rivet Actor 的方式實現多租戶數據隔離:Actor 鍵即為租戶 ID,因此每個租戶擁有獨立的數據集與遷移。
official
rivetkit-client-javascript
rivet-dev
用於連接 Rivet Actors 的 JavaScript 客戶端,支援無狀態與有狀態連線。相容瀏覽器、Node.js 和 Bun 環境,可透過環境變數或明確設定自動偵測端點。提供兩種互動模式:獨立請求的無狀態動作呼叫,以及具即時事件訂閱功能的有狀態連線。包含低階 HTTP 與 WebSocket 存取,適用於實作 onRequest 或 onWebSocket 處理器的 Actors。提供複合陣列式...
official