front-skill：安全的前端开发协作

在已有前端仓库中实施需求时，以仓库当前约定和用户已有修改为事实来源。先调查、再复用、后修改；每次只做最小且完整的变更，并用实际证据验证结果。

先判定本轮模式

从用户措辞和授权范围选择一种模式，不能把分析、审查和实施混在同一轮：

• 分析模式：用户说“分析、评估、给方案、只调查”或明确禁止修改。只读取仓库和设计依据，输出实施合同，不编辑文件。
• 审查模式：用户说“审查、review、检查当前 Diff”。只检查现有变更，输出按优先级排序的问题和验证证据，不顺手修复。
• 实施模式：用户要求新增、修改、修复或实现。先输出简短实施合同，再按选定流程编辑和验证；用户已明确授权时无需再次请求确认。
• 单点实施模式：用户限定文件、代码块或“只改这里”时，使用单点流程并把范围外问题记录为不改项。

如果同一请求同时包含分析和实施，先完成分析合同，再在同一授权范围内继续实施。

实施合同（编辑前必须形成）

用以下固定字段记录判断，字段无法确认时写“待验证”，不能用猜测补齐：

1. 目标 / 非目标：本轮要改变和明确不改变的行为。
2. 入口与影响链路：页面、路由、组件、状态、请求和权限的真实关系。
3. 复用点：按“现有功能 → 同业务 → 公共层 → 框架能力 → 新增”的顺序列出依据。
4. 变更边界：允许修改的文件/区域、禁止触碰的接口和用户已有改动。
5. 契约与边界：输入输出、状态、异常、响应式、浏览器/设备、国际化和无障碍。
6. 验证矩阵：每项验收标准对应命令、页面入口或截图证据。

• 新功能、多文件修改或完整缺陷修复：阅读 references/feature-workflow.md。
• 用户指定单文件、单代码块或强调“只改这里”：阅读 references/surgical-change.md。
• 包含 Figma、设计稿、截图、原型或视觉还原：同时阅读 references/ui-figma.md。
• 最终复查、交付，或发生编辑失败、乱码、命令超时：同时阅读 references/validation.md。
• 只审查当前 Diff：阅读 references/review-workflow.md。

不可违反的规则

1. 修改前先调查。阅读仓库说明、Git 状态、目标文件、入口链路、同类实现、公共组件、工具函数和项目配置。
2. 按顺序复用：当前功能已有实现 → 同业务模块实现 → 项目公共组件/Hook/指令/工具/样式 → 框架或组件库原生能力 → 最后才新增代码。存在同类能力但仍需新写时，说明原因。
3. 将需求转成实施边界：目标与非目标、允许修改的文件/区域、禁止修改的行为、必须复用的内容、数据与交互契约、兼容范围、验证方式。用户给出的计划和范围优先。
4. 只做最小且完整的修改。未经要求，不改事件或回调契约、默认值、公共接口、状态初始化、路由、数据结构和相邻代码，不批量格式化无关文件。
5. 保护用户已有修改。把脏工作区中的无关变更视为用户资产，不覆盖、不清理、不回退。
6. 源码优先使用当前平台提供的局部补丁或精确编辑工具。禁止为了小改动使用 PowerShell Set-Content、Out-File、Shell 重定向、未知编码转换或整文件生成覆盖源码。
7. 保持文件原有编码和换行风格，尤其保护 UTF-8 中文。补丁因编码问题失败时，停止编辑该文件，先确认编码并从可信来源恢复；禁止猜测乱码原文。
8. 小步执行：调查 → 局部修改 → 查看实际 Diff → 定向验证 → 再继续下一步。
9. 优先复用已经运行的开发服务和测试环境。不重复启动监听进程，不随意结束用户进程；长命令使用合理超时，超时不能算通过。
10. 未经用户明确要求，禁止提交、推送、创建 PR、发布、部署或执行其他远程写操作。实现需求不等于获得这些权限。
11. 只有在代码能够解析/编译、Diff 未越界、相关检查通过或已如实说明剩余问题，并且可见交互在适用时得到验证后，才能声称完成。
12. 任何检查失败、命令超时或入口无法复现，都必须保留为未验证项；先缩小检查范围或修复阻塞原因，不能把“命令结束”当作通过。
13. 分析/审查模式禁止编辑；实施中发现范围外缺陷时记录并继续，不借机扩大范围，除非它直接阻塞目标验收。

接收其他模型的计划

1. 依据当前仓库复核计划中的路径、组件、接口和假设，不盲目照抄。
2. 将“参考某文件”落实成明确关系：直接复用、复用配置与结构、只复用视觉规范，或仅作为业务背景。
3. 把软性建议转成可检查的实施清单，但不得擅自扩大用户范围。
4. 按可独立验证的批次实现；每批完成后先复查 Diff 和验证结果。
5. 最终依据实际代码变化审查，而不是依据计划文字推断已经完成。

交付要求

先说明结果，再简洁列出：

• 实际修改的文件及用途；
• 复用的现有实现；
• 实际运行的验证及结果；
• 未验证内容、假设和已有失败；
• UI 需求对应的本地访问或复现方式。
• 本轮模式、验收标准与未验证项。

没有完成编译或实际交互验证时，不得使用“已完成”“已修复”等确定性表述。

推荐调用方式

普通前端需求：

调用当前平台中的 front-skill 完成下面的需求：
[需求内容、设计链接或截图]

单点修改：

调用当前平台中的 front-skill 做一个单点修改。
仅修改以下文件和指定区域，禁止修改其他行为：
[文件、代码区域和目标参考实现]