원클릭으로
openspec-sync-specs
OpenSpec规格同步专家,将变更中的增量规格同步到主规格文档。当用户需要更新主规格、同步delta规格或在不归档的情况下更新规格时调用此Skill。支持中文触发:同步规格、sync specs、规格同步、更新主规格、delta同步。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
OpenSpec规格同步专家,将变更中的增量规格同步到主规格文档。当用户需要更新主规格、同步delta规格或在不归档的情况下更新规格时调用此Skill。支持中文触发:同步规格、sync specs、规格同步、更新主规格、delta同步。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
"PDD框架下的业务分析Skill,运用专业方法论进行需求分析和业务建模。当用户输入/analyze、/audit、/doc等命令,或需要对业务流程、管理制度、Excel表单进行专业分析时触发。支持中文触发:业务分析、需求分析、需求建模、5W1H分析、MECE、流程分析。"
"PDD熵减智能体,持续监控和偿还技术债务,防止系统腐化。当用户需要代码清理、文档更新、技术债务管理、架构对齐、熵减、垃圾回收、清理技术债务时自动触发。即使用户只说'熵减'、'清理技术债务'或'垃圾回收',也应触发此Skill。支持中文触发:熵减、技术债务、代码清理、文档更新、架构对齐、垃圾回收。"
根据开发规格实现功能点代码的核心Skill。当用户想要开始编码实现、根据规格文档生成代码、实现功能点时调用此Skill。此Skill会自动调用pdd-template-engine生成基础代码框架,然后由software-engineer补充业务逻辑。即使只有规格文档没有明确说'实现',只要涉及代码生成、功能开发,都应触发此Skill。支持中文触发:实现功能点、编码实现、开始编码、功能开发、代码实现、PDD实现。
PRD驱动开发的主入口Skill,协调整个开发流程。当用户想要基于PRD文档进行功能开发、从需求文档生成代码、执行PDD方法论流程、开发业务模块、实现完整功能、'搞个功能'、'资产转让'、'国有产权转让'、'帮我搞个资产转让的功能'时必须调用此Skill。即使用户没有明确说'使用PDD',只要涉及PRD文档、需求文档、功能点开发、规格文档、模块开发、根据文档开发、业务功能实现、'开发ZCCZ'、'我想开发'、'搞个功能'等场景,都应触发此Skill。此Skill会自动协调pdd-ba、pdd-extract-features、pdd-generate-spec、pdd-implement-feature等子Skill完成从需求分析到代码交付的完整流程。注意:单一接口设计、调试问题、文档查询等场景不应触发此Skill。支持中文触发:PRD驱动开发、PDD开发、功能开发、启动PDD。
"交通事故责任评估与判定专业技能。当用户需要交通事故责任分析、事故现场照片评估、交通法规咨询、事故责任划分、法律依据查询时触发此技能。适用于车辆碰撞事故、行人事故、非机动车事故等各类道路交通事故的责任认定场景。无论用户使用'交通事故'、'车祸'、'责任判定'、'交通法规'、'事故定责'等何种表述,只要涉及交通事故评估或责任认定,均应调用此技能。支持中文触发:交通事故、车祸、责任判定、交通法规、事故定责、责任划分、事故评估、追尾、碰撞、违章、赔偿。"
自动化重构专家技能,将收集到的质量改进任务转化为具体的代码操作。当用户需要代码重构、消除重复、简化复杂度时自动触发。即使用户只说'重构代码'、'消除重复'或'简化代码',也应触发此Skill。支持中文触发:重构代码、消除重复、简化复杂度、自动重构、代码重构、PDD重构。
| name | openspec-sync-specs |
| description | OpenSpec规格同步专家,将变更中的增量规格同步到主规格文档。当用户需要更新主规格、同步delta规格或在不归档的情况下更新规格时调用此Skill。支持中文触发:同步规格、sync specs、规格同步、更新主规格、delta同步。 |
| license | MIT |
| compatibility | Requires openspec CLI. |
| metadata | {"author":"openspec","version":"1.0","generatedBy":"1.2.0"} |
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 --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.
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:
MODIFIED Requirements:
REMOVED Requirements:
RENAMED Requirements:
d. Create new main spec if capability doesn't exist yet:
openspec/specs/<capability>/spec.mdShow summary
After applying all changes, summarize:
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:
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