openspec-sync-specs

作者: sentry

從變更中同步差異規格到主要規格。當用戶想要用差異規格的變更來更新主要規格,而不歸檔該變更時使用。

npx skills add https://github.com/getsentry/sentry-mcp --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. 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

來自 sentry 的更多技能

generate-frontend-forms
sentry
使用 Sentry 新表單系統建立表單的指南。適用於實作表單、表單欄位、驗證或自動儲存功能時使用。
official
sentry-snapshots-cocoa
sentry
完整的 Sentry Snapshots 設定,適用於 Apple/Cocoa 專案。當被要求「設定 SnapshotPreviews」、「設定 Apple 快照測試」、「上傳 Apple 快照至…」時使用。
official
architecture-review
sentry
員工級別的程式碼庫健康檢查。找出單體模組、靜默失敗、型別安全漏洞、測試覆蓋缺口,以及LLM友善性問題。
official
linear-type-labeler
sentry
根據每個問題的標題與描述內容,從 Sentry 工作區的標籤分類法中分類 Linear 問題,並套用對應的類型標籤。
official
sentry-flutter-sdk
sentry
完整的 Sentry SDK 設定,適用於 Flutter 和 Dart。當被要求「為 Flutter 加入 Sentry」、「安裝 sentry_flutter」、「在 Dart 中設定 Sentry」或設定錯誤…時使用。
official
sentry-svelte-sdk
sentry
完整的 Sentry SDK 設定,適用於 Svelte 和 SvelteKit。當被要求「將 Sentry 加入 Svelte」、「將 Sentry 加入 SvelteKit」、「安裝 @sentry/sveltekit」或進行設定時使用…
official
vercel-react-best-practices
sentry
來自 Vercel Engineering 的 React 與 Next.js 效能優化指南。此技能應在撰寫、審查或重構 React/Next.js… 時使用。
official
sentry-tanstack-start-sdk
sentry
完整的 Sentry SDK 設定,適用於 TanStack Start React。當被要求「將 Sentry 加入 TanStack Start」、「安裝 @sentry/tanstackstart-react」或設定錯誤…時使用。
official