SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场cflx-proposal

cflx-proposal

编程与开发

查看项目

更新于 10-16 05:38

技能介绍

用途

cflx-proposal 用于为 Conflux（基于 OpenSpec）项目创建结构化的变更提案。它通过交互式对话与用户协作，帮助梳理需求、收集上下文，并生成符合规范的提案文档。该技能仅用于提案创建，不实现或修改产品/源代码。

主要能力

  • 通过交互式对话理解变更需求，主动从当前会话和仓库中收集上下文。
  • 生成结构化的提案目录，包含 proposal.md（变更描述与上下文）、tasks.md（实现任务清单）、可选的 design.md（架构与设计）以及 specs/ 下的规格增量（spec.md）。
  • 默认倾向于将需求拆分为多个独立的变更提案，每个提案使用独立的动词开头 change-id，并在最终总结中说明依赖/顺序关系及可并行性。
  • 自动生成简洁、唯一的动词开头 kebab-case change-id，不要求用户确认。
  • 支持严格校验（strict validation），确保提案符合规范。
  • 任务设计遵循 mock-first 原则，优先使用 mock/stub/fixture 进行本地验证，避免阻塞于外部依赖。
  • 将任务分类为 AI 可执行任务（带复选框）和 Future Work 任务（无复选框，如人工审批、外部系统部署、长等待验证等）。

使用方式

该技能通过自然语言触发，当用户请求“创建提案”“起草变更”“提议新功能”或任何创建结构化变更文档的请求时激活。

交互流程包括：

  1. 理解变更：主动收集上下文，必要时提出澄清问题。
  2. 评估拆分边界：默认拆分独立或弱耦合的范围。
  3. 生成 change-id：动词开头、kebab-case、无日期前后缀、简洁且唯一。
  4. 起草提案内容：创建 proposal.md，包含标题、问题/上下文、提议方案、验收标准、范围外内容（如适用）。
  5. 创建任务分解：创建 tasks.md，任务需包含验证方法，优先使用仓库可验证的证据。
  6. 设计文档（可选）：当变更跨多个系统、需要记录架构决策或权衡时创建 design.md。
  7. 编写规格增量：创建 specs/<capability>/spec.md，使用 ADDED/MODIFIED/REMOVED 章节，每个需求至少一个场景。
  8. 校验提案：运行 python3 "$SKILL_ROOT/scripts/cflx.py" validate <id> --strict，失败时展示错误并修正后重新校验。
  9. 最终审查：展示目录结构、总结要点、确认就绪，若拆分为多个提案则提供提案索引。

内置工具命令：

  • 列出已有变更：python3 "$SKILL_ROOT/scripts/cflx.py" list
  • 列出规格：python3 "$SKILL_ROOT/scripts/cflx.py" list --specs
  • 显示变更详情：python3 "$SKILL_ROOT/scripts/cflx.py" show <id>
  • 严格校验：python3 "$SKILL_ROOT/scripts/cflx.py" validate <id> --strict
  • 带证据警告校验：python3 "$SKILL_ROOT/scripts/cflx.py" validate <id> --strict --evidence warn
  • 带证据错误校验：python3 "$SKILL_ROOT/scripts/cflx.py" validate <id> --strict --evidence error

适用场景

  • 功能新增：理解用户需求，审查现有架构，提出最小可行方案，分解实现任务，添加规格需求。
  • 缺陷修复：理解缺陷行为，定位根因区域，提出修复方案，包含回归测试，行为变更时添加 MODIFIED 规格。
  • 重构：明确重构目标，识别受影响组件，规划增量步骤，确保测试覆盖，记录设计决策。
  • 任何需要创建结构化变更文档的请求。

限制

  • 仅用于提案创建，不实现或修改产品/源代码。
  • 可读取任意文件以收集上下文，但仅可写入 openspec/changes/<change-id>/ 目录下。
  • 严格模式下必须包含至少一个规格增量（spec delta）。
  • 对于仅修复缺陷的提案（无预期新行为），需添加最小的 ## MODIFIED Requirements 增量，包含至少一个 ### Requirement: 和一个 #### Scenario:。
  • 该技能设计用于直接人工交互，不适用于自动化编排。
  • 无法本地验证且需要凭证或外部系统的需求，应设计基于 mock/stub/fixture 的验证；真正不可 mock 的依赖（人工决策、真实外部系统、长等待检查）归入范围外/未来工作。
  • 不要求用户选择或确认 change-id，由技能自动生成。
  • 若上下文收集后请求已足够清晰，直接起草提案，不强制额外澄清轮次。

提案结构

openspec/changes/<change-id>/ ├── proposal.md # 变更描述与上下文 ├── tasks.md # 实现任务清单 ├── design.md # 架构与设计（可选） └── specs/ # 规格增量 └── <capability>/ └── spec.md # 需求规格

任务格式

Implementation Tasks

  • [ ] Task 1: 描述（验证：如何验证完成）
  • [ ] Task 2: 描述（验证：...）

Future Work

  • 需要人工操作的事项
  • 需要外部系统的事项
  • 长等待验证任务

规格增量格式

ADDED Requirements

Requirement: <requirement-name>

<Description>

Scenario: <scenario-name>

Given: <preconditions> When: <action> Then: <expected-outcome>

MODIFIED Requirements

Requirement: <existing-requirement-name>

<Updated description>

Scenario: <scenario-name>

...

REMOVED Requirements

Requirement: <deprecated-requirement-name>

<Reason for removal>

关键规则：每个需求至少一个场景；使用 ADDED/MODIFIED/REMOVED 章节；具体且可测试。