Menú
通用创建提案技能。根据需求是否有设计稿或 UI 描述、是否有接口、是页面还是功能组件等可选条件，决定设计稿分析、接口与数据层、以及实现后的 UI 还原验收等步骤。适用于各类需求提案，不限于纯 UI 页面。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
检查 .agents 下 rules、skills、README 与模板基线依赖的一致性，避免规则漂移、悬空引用和 React 能力越界。修改或新增 .agents 内容时使用本技能。
指导在前端项目中按团队规范创建和维护接口请求层，涵盖统一请求客户端、业务 API 文件、类型组织、错误处理、mock 过渡与 React 使用边界。当前端需要新增或重构接口时使用本技能。
指导在前端项目中按团队规范创建和维护 React 组件，涵盖通用组件与页面级组件的边界、目录结构、样式隔离、类型设计与导出策略。当前端需要新增、拆分或沉淀组件时使用本技能。
指导在前端项目中按团队规范创建和维护路由（React Router Data Router），涵盖路由单源、页面目录、路由模块注册、懒加载、标题与守卫等约束。当前端需要新增或重构页面路由时使用本技能。
指导在前端项目中按团队规范使用 Zustand 创建和维护全局状态 store，包括目录结构、命名与持久化策略。当前端需要新增或重构状态管理时使用本技能。
指导在前端项目中正确使用 Ant Design 与自定义主题 CSS 变量，避免硬编码颜色并保证暗色/浅色主题切换一致性。当前端编写或修改样式时使用本技能。
| name | create-proposal |
| description | 通用创建提案技能。根据需求是否有设计稿或 UI 描述、是否有接口、是页面还是功能组件等可选条件，决定设计稿分析、接口与数据层、以及实现后的 UI 还原验收等步骤。适用于各类需求提案，不限于纯 UI 页面。 |
当需要为一个需求创建 OpenSpec 提案（proposal、tasks、spec）时使用本技能。需求可能是：
本技能根据「是否有设计稿/UI 描述」「是否有接口」「交付形态（页面/组件/其它）」等条件，决定执行哪些步骤、产出哪些任务。
在写 proposal / tasks / spec 之前，先确认下列条件，以便后续步骤按需执行。
| 条件 | 选项 | 影响 |
|---|---|---|
| 是否有设计稿或 UI 要求描述 | 有 / 无 | 有 → 可选用 design-analysis 产出 UI 分析清单；实现后可有 UI 还原验收步骤 |
| 是否有接口（已提供或约定） | 有 / 无 / 未就绪 | 有 → 正常对接；无 → 可不做数据层；未就绪 → mock，见项目 Mock 数据策略 |
| 交付形态 | 新页面 / 功能组件 / 能力模块 / 其它 | 决定目录结构（routes vs components）、tasks 模板 |
| 是否仅样式/还原类 | 是 / 否 | 是 → 重点在 design-analysis + 验收 |
当需求包含界面且有设计稿（.pen、figma链接、设计图、标注）或有明确 UI 描述时：
.agents/skills/design-analysis/SKILL.mddocs/样式还原/<名称>-UI分析清单.md这样后续开发可以依据分析清单精确实现，实现后的验收也以此清单为基准。不限定「必须先分析再写提案」：可以边写提案边分析，或先分析再写提案，只要在开发前有一份分析清单即可。
在 tasks 中可写明：页面/组件开发须依据 docs/样式还原/<名称>-UI分析清单.md 实现布局与样式。
若交付形态是页面或功能组件，根据 .agents/rules/04-组件规范.md 判断组件放置位置：
src/components/<name>/src/views/<page>/components/<name>/ 或对应功能目录下涉及页面时，常见约定：
.module.scsssrc/types/<feature>/，含 model.ts、api.ts.agents/rules/08-通用约束.md）若需求涉及接口（已提供或未就绪）：
.agents/rules/03-项目结构.md 等规范，在 tasks 中安排 types/、http/ 等。src/types/<feature>/ 下定义 model.ts、api.ts，在 src/http/<feature>.ts 下提供 mock；tasks 中标注「mock，后续替换」。若不涉及接口，可省略或仅写「无后端依赖」。
根据需求类型书写，建议包含：
若有设计稿或 UI：可写「图标/图片使用占位元素」「开发依据 docs/样式还原/xxx-UI分析清单.md」等。
按交付形态与条件勾选任务，例如：
index.module.scss、与布局一致的结构；若有分析清单则写「依据 xxx-UI分析清单 实现」。index.tsx、index.module.scss、占位与规范。src/types/<feature>/、src/http/<feature>.ts 或 mock。.agents/skills/ui-verification/SKILL.md 进行 UI 还原验收，产出问题清单并反思分析不足」。定义需求规格：场景、验收标准、可选的状态与边界。若有 UI，可引用分析清单中的「验证检查清单」作为验收参考。
当需求包含界面且有设计稿并已产出 UI 分析清单时，在实现完成后需要进行 UI 还原验收时：
.agents/skills/ui-verification/SKILL.md当开发涉及 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/05-API规范.md - 接口目录与命名规范.agents/rules/08-通用约束.md - 占位元素等.agents/rules/09-样式规范.md - 设计稿颜色提取.agents/skills/design-analysis/SKILL.md - 设计稿分析（有设计稿时使用，产出 UI 分析清单）.agents/skills/create-component/SKILL.md - 创建组件.agents/skills/create-api/SKILL.md - 创建接口层.agents/skills/ui-verification/SKILL.md - UI 验收（实现后需验收时使用）