Feature Delivery

一个功能分三段：设计时只让用户拍板必须由他决定的事，实现时直接采用用户习惯，交付前主动发现同类偏差，减少重复纠偏和来回沟通。本技能保存个人工程偏好和基础实现约束，不是某个业务系统的需求清单，也不要求每条偏好都适用于所有项目。

设计

新功能、跨模块改动、存在多个可行方案或有视觉取舍的 UI 变更，且确有需要用户拍板的点时，实现前先读 功能设计，出一份 HTML 设计文档。小修复、用户已给出完整方案、或没有待拍板点时跳过，直接实现。设计文档控制信息密度：按场景组织，每个场景上方写描述，下方左右对比现状与改后的仿真界面（真实数据），在界面上圈出问题和改动，再列 1～3 个带推荐的待拍板项。

设计环节同时定下 验收清单：每项有编号、操作、可判定的预期和验证方式，覆盖改后场景、本次会遇到的失败与恢复路径和可能波及的不变行为。有设计文档时放在文档里；跳过设计文档时，开始实现前在回复里列出。

前端协作与读取

• 按用户或项目要求，在 UI 设计或修改前读取 lobe-design/SKILL.md，再按其路由加载命中的参考；组件选择、cssVar token、视觉工艺和设计标准由它维护，本技能不复制组件目录或主题规则。不使用 Lobe 的项目保持既有技术栈。
• 页面、列表、表单、抽屉或异步流程实现前读取 交互与状态，涉及输入与草稿再读 表单与输入，涉及查询与展示再读 详情与展示。本技能检查状态、边界及恢复，项目已有 ux 时同时读取并沿用其交互规范，不另建一份产品行为定义。
• 设计问题按 lobe-design 的症状路由复核，交互问题按本技能对应参考复核；放行仍需实际浏览器证据，扫描零命中不代表交互或设计合格。

实现

1. 先读本次需求、已拍板的设计与项目约定，再读 工程选择原则，从 规则索引 选择相关的前端、后端约束；采用 Lobe/Admin 范式的项目同时读取项目范式补充。开始实现时就使用这些约束，不等用户指出问题后才读取。
2. 确定变动范围，运行扫描；结合项目已有 lint、类型检查和相关测试完成确定性检查，扫描列出的项目命令只是候选，核实后按项目包管理方式执行。
3. Agent 重点检查脚本不能判断的组件选择、布局、封装、职责和行为，沿共享组件及调用点检查同类偏差；当前业务结果以本次需求为准，不从历史项目推定。
4. 有修复授权时处理并复验；出现可复用纠偏时，按 反馈沉淀 查重并在同次修复中更新所属技能或项目门禁，使下一次实现与验收能读到它。

本次明确要求优先于项目既有约定，项目既有约定优先于本技能的个人默认偏好；不因应用偏好切换技术栈或扩大业务范围。

# FD_DIR 为实际加载的技能目录，PROJECT 为项目根目录
bun "$FD_DIR/scripts/accept.ts" scan --project "$PROJECT"
# 只扫描指定 commit 到当前工作树的变动文件及未忽略的新文件
bun "$FD_DIR/scripts/accept.ts" scan --project "$PROJECT" --base "$BASE_COMMIT"

需要 Bun ≥ 1.3、ripgrep，Git 项目另需 Git。脚本不执行项目代码，返回 0 仍需审查，1 表示已激活规则命中门禁，2 表示错误或覆盖不完整；有缺失工具时如实报告自动检查未完成，继续可执行的审查。扫描范围、CLI 和项目规则格式见 脚本契约。

验收

• 后端沿用项目测试和授权环境，核对实际接口、失败反馈及数据变化；不因验收自行迁移、seed 或 reset。
• 按设计环节的验收清单逐项验收：先读清单的最新版本，每项按其操作执行，对照预期给出通过、失败、阻塞或未执行，附实际观察和证据，编号与清单一致；不合并、不跳过、不改写预期，未执行写明原因。清单外发现的问题追加为新检查项（X1、X2…）。修复后复验失败项和与修复共用代码路径的项，结果对应当前版本。
• 前端完成真实浏览器交互及 console/network 检查；使用 browser-harness 时向它交接功能范围、被测版本，以及验收清单中需要浏览器验证的条目和预期，已有服务同时交接实际 APP_URL、所有者及保留要求，其环境、登录态、采证与清理由该技能负责。
• 独立使用时采用项目已有浏览器工具完成同样的交互验证；项目指定 browser-harness 时遵循该入口，不因本技能支持独立使用而绕过。

只审查源码不能宣称运行验收通过。报告具体问题及文件位置、相关规则、实际证据和未验证项，不逐条复述整个规则库；前端同时给出 APP_URL、关键页面结果、console/network 错误及资源释放情况。复验对应当前版本，只清理自有进程并保护真实开发与业务数据；一次性验收资源按 任务资源生命周期 收尾。

既有流程需要或用户要求独立验收报告时，默认交付 REPORT.html，生成前读取 HTML 验收报告，用 report.ts 从检查结果渲染，有设计文档时用 checklist 指向它，由脚本核对清单项全部有对应结果；不出独立报告时，回复中同样按清单编号逐项给出结果。普通问答、静态审查和内部计划不因此增加独立报告。

用户只要求审查时不改实现和规则；已要求沉淀项目规范时完成规则写入与下次读取入口，不只返回建议。技能自身验证按需使用 asset-validation。

分享链接

用户常在手机上查看，设计文档和 HTML 验收报告交付时上传到 R2，回复里同时给公网链接和本地路径：

bun "$FD_DIR/scripts/share.ts" upload --file "<工作区根>/reports/<文件>.html" --task <任务名> [--name <名称>] [--release-when <释放条件>]

• 写入只经 cf CLI：每次先以完整参数 --dry-run 核对账户、桶和 key，再原样执行一次，失败不重试；同名对象已存在时拒绝，不覆盖。写入后重新列出对象，并读取公网链接核对 200、类型和 MD5。stdout 的 url 就是交付链接。
• 单文件放在 <上海日期>/<文件名>。页面经 src、href、poster 引用了本地文件时（报告的证据截图、清单所在的设计文档），脚本把它们一并上传，以工作区根为根放在 <上海日期>/<名称>/ 下，线上相对链接照常可用；引用越出工作区根、指向隐藏路径或文件不存在时拒绝上传。--name 替换单文件的文件名或带资源时的目录名。
• 链接公开，拿到即可访问；上传前按 证据与资源交接 检查敏感内容，被引用的证据同样公开。
• 文档修订后用新名称上传（如 --name <原名>-v2.html），把新链接给用户，被替代的旧对象按回收规则删除。
• --task 用本任务名，与 worktree、容器 owner 标签一致。每次上传都会登记，保留、回收和扫描见 R2 分享对象。
• 需要已登录的 cf CLI 和本机配置 ~/.config/r2-share/config.json（R2_SHARE_CONFIG 可指定其他文件），写明 account、bucket、domain（桶已启用的自定义域名）和可省略的 profile，不写凭据；缺配置时脚本报错并给出格式。