create-proposal

name	create-proposal
description	通用创建提案技能。根据需求是否有设计稿或 UI 描述、是否有接口、是页面还是功能组件等可选条件，决定设计稿分析、接口与数据层、以及实现后的 UI 还原验收等步骤。适用于各类需求提案，不限于纯 UI 页面。

创建提案

使用时机

当需要为一个需求创建 OpenSpec 提案（proposal、tasks、spec）时使用本技能。需求可能是：

• 新增/改版一个页面（有或没有设计稿）
• 开发一系列功能组件（有或没有 UI 描述）
• 有接口或无接口（后端未就绪时用 mock）
• 纯逻辑、纯接口、或 UI + 接口 等组合

本技能根据「是否有设计稿/UI 描述」「是否有接口」「交付形态（页面/组件/其它）」等条件，决定执行哪些步骤、产出哪些任务。

---

步骤 1：明确需求类型与条件

在写 proposal / tasks / spec 之前，先确认下列条件，以便后续步骤按需执行。

条件	选项	影响
是否有设计稿或 UI 要求描述	有 / 无	有 → 可选用 design-analysis 产出 UI 分析清单；实现后可有 UI 还原验收步骤
是否有接口（已提供或约定）	有 / 无 / 未就绪	有 → 正常对接；无 → 可不做数据层；未就绪 → mock，见项目 Mock 数据策略
交付形态	新页面 / 功能组件 / 能力模块 / 其它	决定目录结构（routes vs components）、tasks 模板
是否仅样式/还原类	是 / 否	是 → 重点在 design-analysis + 验收

---

步骤 2：若有设计稿或 UI 描述 —— 设计稿分析（可选但推荐）

当需求包含界面且有设计稿（.pen、figma链接、设计图、标注）或有明确 UI 描述时：

• 使用技能：.agents/skills/design-analysis/SKILL.md
• 产出：docs/样式还原/<名称>-UI分析清单.md

这样后续开发可以依据分析清单精确实现，实现后的验收也以此清单为基准。不限定「必须先分析再写提案」：可以边写提案边分析，或先分析再写提案，只要在开发前有一份分析清单即可。

在 tasks 中可写明：页面/组件开发须依据 docs/样式还原/<名称>-UI分析清单.md 实现布局与样式。

---

步骤 3：定义组件与代码结构（涉及 UI 时）

若交付形态是页面或功能组件，根据 .agents/rules/04-组件规范.md 判断组件放置位置：

• 多处复用 → src/components/<name>/
• 单页或单能力内使用 → src/routes/<page>/components/<name>/ 或对应功能目录下

涉及页面时，常见约定：

• 样式文件使用 .module.scss
• interfaces/ 下为文件夹，含 model.ts、api.ts
• 图标/图片未定时用占位元素（见 .agents/rules/08-通用约束.md）

---

步骤 4：接口与数据层（有接口或需 mock 时）

若需求涉及接口（已提供或未就绪）：

• 已提供接口：按 .agents/rules/03-项目结构.md 等规范，在 tasks 中安排 interfaces/、http/ 等。
• 未就绪：按项目 Mock 数据策略，在 interfaces/<feature>/ 下定义 model.ts、api.ts，在 http/ 下提供 mock；tasks 中标注「mock，后续替换」。

若不涉及接口，可省略或仅写「无后端依赖」。

---

步骤 5：创建提案文档

5.1 proposal.md

根据需求类型书写，建议包含：

• Why：业务价值或目标
• What Changes：改动范围（新页面 / 新组件 / 新接口 / 样式还原等）
• Impact：受影响或新增的 capability、目录、文件

若有设计稿或 UI：可写「图标/图片使用占位元素」「开发依据 docs/样式还原/xxx-UI分析清单.md」等。

5.2 tasks.md

按交付形态与条件勾选任务，例如：

• 新页面：路由目录、Page、Loader、index.module.scss、与布局一致的结构；若有分析清单则写「依据 xxx-UI分析清单 实现」。
• 功能组件：组件目录、index.tsx、index.module.scss、占位与规范。
• 接口/数据层：interfaces/<feature>/、http/<feature>.ts 或 mock。
• UI 还原验收：若有设计稿且产出了分析清单，可在 tasks 末尾加「实现后使用 .agents/skills/ui-verification/SKILL.md 进行 UI 还原验收，产出问题清单并反思分析不足」。

5.3 spec.md

定义需求规格：场景、验收标准、可选的状态与边界。若有 UI，可引用分析清单中的「验证检查清单」作为验收参考。

---

步骤 6：实现后的 UI 还原验收（可选）

当需求包含界面且有设计稿并已产出 UI 分析清单时，在实现完成后需要进行 UI 还原验收时：

• 使用技能：.agents/skills/ui-verification/SKILL.md
• 该技能通用指导如何进行 UI 验收：对照分析清单与设计稿、产出 UI 问题清单、修复与再验证、反思分析不足并反哺 design-analysis。

---

样式还原验证检查清单（供 create-route / create-component 引用）

当开发涉及 UI 还原（有设计稿或分析清单）时，可对照以下检查项自检；更完整项见 docs/样式还原/<名称>-UI分析清单.md 中的「验证检查清单」。

布局：区域位置、尺寸、间距是否与分析清单/设计稿一致；对齐方式（如 flex-start vs center）是否正确。
样式：颜色、字体、字号、字重、圆角、边框、阴影、效果（如 backdrop-filter）是否一致。
元素：是否缺少区块、图标、占位图；占位尺寸与比例是否正确。
交互：默认/hover/active 等状态是否还原（若有设计）。

create-route、create-component 等技能中「涉及 UI 还原时」可引用：.agents/skills/create-proposal/SKILL.md 中的「样式还原验证检查清单」及对应页面的 docs/样式还原/<名称>-UI分析清单.md。

---

相关规范与技能

• .agents/rules/03-项目结构.md - 目录结构、Mock 数据策略
• .agents/rules/04-组件规范.md - 组件放置决策
• .agents/rules/08-通用约束.md - 占位元素等
• .agents/rules/09-样式规范.md - 设计稿颜色提取
• .agents/skills/design-analysis/SKILL.md - 设计稿分析（有设计稿时使用，产出 UI 分析清单）
• .agents/skills/ui-verification/SKILL.md - UI 验收（实现后需验收时使用）