ワンクリックで
openspec-new-change
OpenSpec新建变更专家,使用结构化的工件驱动流程创建新变更。当用户需要创建新功能、修复Bug或发起修改时调用此Skill。支持中文触发:新建变更、new change、创建变更、发起新变更、openspec new。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
OpenSpec新建变更专家,使用结构化的工件驱动流程创建新变更。当用户需要创建新功能、修复Bug或发起修改时调用此Skill。支持中文触发:新建变更、new change、创建变更、发起新变更、openspec new。
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-new-change |
| description | OpenSpec新建变更专家,使用结构化的工件驱动流程创建新变更。当用户需要创建新功能、修复Bug或发起修改时调用此Skill。支持中文触发:新建变更、new change、创建变更、发起新变更、openspec new。 |
| license | MIT |
| compatibility | Requires openspec CLI. |
| metadata | {"author":"openspec","version":"1.0","generatedBy":"1.2.0"} |
Start a new change using the experimental artifact-driven approach.
Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.
Steps
If no clear input provided, ask what they want to build
Use the AskUserQuestion tool (open-ended, no preset options) to ask:
"What change do you want to work on? Describe what you want to build or fix."
From their description, derive a kebab-case name (e.g., "add user authentication" → add-user-auth).
IMPORTANT: Do NOT proceed without understanding what the user wants to build.
Determine the workflow schema
Use the default schema (omit --schema) unless the user explicitly requests a different workflow.
Use a different schema only if the user mentions:
--schema <name>openspec schemas --json and let them chooseOtherwise: Omit --schema to use the default.
Create the change directory
openspec new change "<name>"
Add --schema <name> only if the user requested a specific workflow.
This creates a scaffolded change at openspec/changes/<name>/ with the selected schema.
Show the artifact status
openspec status --change "<name>"
This shows which artifacts need to be created and which are ready (dependencies satisfied).
Get instructions for the first artifact
The first artifact depends on the schema (e.g., proposal for spec-driven).
Check the status output to find the first artifact with status "ready".
openspec instructions <first-artifact-id> --change "<name>"
This outputs the template and context for creating the first artifact.
STOP and wait for user direction
Output
After completing the steps, summarize:
Guardrails