Borrowing it
Nothing to install: this file belongs to feimacode/feima-copilot-llms-extension. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/feimacode/feima-copilot-llms-extension/main/.claude/skills/openspec-sync-specs/SKILL.mdgit clone --depth 1 https://github.com/feimacode/feima-copilot-llms-extensionWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/feimacode/feima-copilot-llms-extension/openspec-sync-specs)<a href="https://agentmods.dev/skills/feimacode/feima-copilot-llms-extension/openspec-sync-specs"><img src="https://agentmods.dev/badge/skills/feimacode/feima-copilot-llms-extension/openspec-sync-specs.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.01025 |
| Opus 5 | $0.00019 | $0.00513 |
| Sonnet 5 | $0.00008 | $0.00205 |
| Haiku 4.5 | $0.00004 | $0.00103 |
Grade A, and why
openspec-sync-specs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
86% identical to openspec-sync-specs — 21 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
-
If no change name provided, prompt for selection
Run
openspec list --jsonto 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.
-
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.
-
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
-
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
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 139 lines · 38 tokens per session scan A ea77918baec6
openspec-sync-specs is a skill published in the GitHub repository feimacode/feima-copilot-llms-extension (5 stars, last pushed 6d ago), licensed MIT. It adds 38 tokens to every session and 1,025 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 86% identical to openspec-sync-specs, differing in 21 lines, and is treated as a copy.
Other skills, from other repositories
byok-custom-model
Register a custom LLM endpoint with your own API key for chat in Starchild. Use when adding a personal Anthropic, OpenAI, Grok, Qwen, DeepSeek, Meta (Muse Spark), NEAR AI, or Venice key as a chat model (e.g. add my Claude key, register DeepSeek, use Muse Spark 1.1).
codex-app-threads
Create, list, read, message, wait on, fork, rename, archive, and pin Codex threads (sidebar tasks), plus automations and app navigation, using the app-native codexapp tools. Use when the session uses a custom (non-OpenAI) model, for example deepseek-v4-flash or mimo-v2.5, and the user asks to create a thread or a new…
china-translate
中英互译 + 本地化 - 技术翻译、UI本地化、文化适配、避免机翻腔.
douyin-script
抖音/快手短视频脚本 - 前3秒hook、脚本结构、热门音乐建议、话题标签策略.
ppt-designer
PPT 演示助手 - 幻灯片设计、内容结构、视觉优化、动画建议、演讲稿.
xiaohongshu-writer
小红书笔记写作助手 - 标题优化、emoji策略、话题标签、封面文案、笔记结构.