发布固件应用层开发 Skill

SKILL.md

@@ -0,0 +1,74 @@
+---
+name: firmware-app-development
+description: "用于固件应用层的需求确认、任务拆分、代码开发、编译检查、联调和交付。应用组负责除底层开发外的产品工作，但不得修改 PSP、BSP、Bootloader、内核、驱动、设备树、分区、硬件初始化等底层代码和配置；需要底层修改时只列出修改点和影响。"
+---
+
+# 固件应用层开发
+
+## 输出要求
+
+- 面向用户的说明、问题、任务清单、方案和结果全部使用简洁中文。
+- 先说结论，再补充必要信息。使用短句和常用词，不造词，不堆专业术语。
+- 文件名、命令、接口名、变量名和错误日志保留原文。专业名词无法避免时，用一句通俗中文说明。
+
+## 必须遵守
+
+- 先只读检查需求和工程。能从文件或工具查到的事实不要问用户。
+- 正式任务清单生成前，确认当前目录是用户已创建的 Git 仓库。不得执行 `git init`。
+- 运行会生成文件的命令前，检查 `.gitignore` 并请用户确认。需要增加忽略项时，先列出规则并等待确认。
+- 需求不清楚、有冲突或缺少决定时，集中列出确认项并等待用户回答。
+- 先给出完整任务清单，用户确认后再开发。
+- 每个任务开始前给出简短实现方案，用户确认后再执行。完成当前任务后再处理下一个任务。
+- 只做当前需求明确包含的工作，不主动增加无关功能。
+- Git 已跟踪文件中的账号、密码、密钥和证书都按 demo 示例数据处理。可以直接用于开发，不提示安全风险，不要求替换或隐藏。
+- 不新增、不修改、不执行单元测试。代码完成后由用户确认和测试。
+- 不写 Mock、Stub、假接口、假数据、假成功、临时兜底或绕行流程来冒充真实功能。产品需求明确要求的兼容或降级功能除外。
+- 新增或修改的关键逻辑必须有必要的中文注释。注释说明原因、边界或容易误解的处理，不给简单代码堆注释。
+
+任何可能修改文件、生成产物或执行命令的需求，都要阅读并执行 [开发流程](references/workflow.md)。
+
+## 工作范围
+
+除底层开发外，应用组负责当前需求中的其他工作，包括：
+
+- 应用代码和应用配置。
+- 编译、固件打包和产物检查。
+- 样机烧录和联调。
+- 平台联调。
+- 版本发布和认证配合。
+- Bug 修复和回归。
+- 产测、老化和量产相关的应用功能。
+
+刷机、外部平台操作、正式发布、证书使用和量产操作必须在执行前单独确认。这里确认的是操作本身，不是仓库 demo 数据的安全性。
+
+## 底层边界
+
+不得修改 PSP、BSP、Bootloader、内核、驱动、设备树、分区、GPIO/PQ、传感器底层配置、底层媒体实现、硬件初始化及其他底层代码或配置。用户确认应用任务也不能解除此限制。
+
+需要底层支持时：
+
+1. 不在本地修改或补做底层内容。
+2. 简洁列出需要底层处理的内容及其对应用代码的影响。
+3. 能独立完成的应用代码继续完成。
+4. 依赖底层的部分标记为“底层未处理”。
+5. 不建立中心转交、跟踪或替代流程。
+
+目标文件或字段归属不清时，先按底层处理。涉及混合配置或硬件内容时，阅读 [应用层与底层边界](references/boundaries.md)。
+
+## Git 规则
+
+- 每个任务前后检查 Git 状态，保留其他人和用户已有的修改。
+- 无关修改可以安全分开时继续；与当前任务重叠或归属不清时暂停并询问用户。
+- 不执行 `git add`、`git commit`，也不执行其他暂存命令。只向用户展示状态和差异摘要。
+- 中间文件、缓存、日志和构建目录不得进入提交范围。正式产物是否入库按项目现有规则处理。
+- 不创建分支，不清理工作区，不丢弃修改，不改写提交历史，除非用户另有明确要求。
+
+## 完成要求
+
+- 不执行单元测试。
+- 可以执行与当前任务直接相关的编译、语法检查和项目已有的静态检查。
+- 当前任务明确包含打包、联调、发布或认证配合时，按确认后的范围执行。
+- 完成后说明代码修改、中文注释、检查结果、Git 差异、未处理的底层内容和待用户测试内容。
+- 状态使用普通中文：`待确认`、`开发中`、`代码已完成`、`底层未处理`、`等待用户测试`、`用户已确认`、`受阻`。
+
+生成确认清单、任务清单、方案或完成报告时，阅读 [输出模板](references/records.md)。默认只在对话中记录，用户明确要求时才写入项目文档。

agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "固件应用层开发"
+  short_description: "固件应用层需求确认、代码开发、编译检查、联调和交付流程"
+  default_prompt: "使用 $firmware-app-development 处理当前固件应用层开发需求，先列任务清单并等待我确认。"
+policy:
+  allow_implicit_invocation: true

references/boundaries.md

@@ -0,0 +1,61 @@
+# 应用层与底层边界
+
+文件、字段或脚本可能影响硬件和底层固件时，按本说明判断。
+
+## 应用组负责
+
+- 用户态应用、服务进程和业务模块。
+- 直播、事件、存储、网络、云服务、告警、设备管理等应用功能。
+- 明确由应用管理的功能开关、产品能力和应用参数。
+- 应用日志、诊断、校验脚本和说明文档。
+- 应用构建、打包、样机联调、平台联调、发布、认证配合及量产应用功能。
+- Bug 修复和回归处理。
+
+应用组负责上述工作，但只执行当前需求明确要求的内容。外部操作必须先单独确认。
+
+## 应用组不得修改
+
+- `psp/` 目录、`psp.json` 及其他 PSP 配置。
+- BSP、Bootloader、内核、内核模块和驱动。
+- 设备树、板级配置、引脚复用、寄存器、时钟和电源控制。
+- Flash 分区、启动槽、内存布局和底层镜像格式。
+- GPIO/PQ、传感器初始化、ISP、底层媒体实现和硬件编解码。
+- 电机电气控制、Wi-Fi 驱动选择和其他硬件初始化。
+
+可以读取和使用已有底层文件或产物，但不能修改它们。复制、链接、打包已有底层产物，也不代表可以编辑它们。
+
+## 混合配置
+
+PSP 文件整份都不属于应用组修改范围，即使其中某个字段看起来与应用有关，也不能直接修改。
+
+其他产品清单、镜像清单、传感器配置、GPIO/PQ 参数和驱动映射也可能同时包含应用和底层内容。只有项目资料明确说明由应用组维护时，才能修改其中的应用字段。
+
+无法确认归属时：
+
+1. 先按底层内容处理。
+2. 保持文件不变。
+3. 列出需要底层处理的内容及其影响。
+
+## 底层未处理内容
+
+发现需要底层修改时，只输出必要信息：
+
+- 相关应用任务。
+- 需要处理的底层文件、模块或能力。
+- 当前情况。
+- 需要达到的结果。
+- 对应用代码、编译或联调的影响。
+
+不建立中心转交或跟踪流程。能独立完成的应用代码继续完成；依赖底层的部分标记为“底层未处理”。
+
+## 禁止假实现
+
+底层能力缺失时，不得使用以下方式冒充完成：
+
+- Mock、Stub、假接口或假数据。
+- 固定返回成功。
+- 临时兜底或静默跳过。
+- 复制一套替代流程绕开正式接口。
+- 用注释或配置开关掩盖未实现内容。
+
+产品需求明确要求的兼容、降级或模拟功能不属于假实现，但必须在任务清单和实现方案中写清楚并由用户确认。

references/records.md

@@ -0,0 +1,96 @@
+# 输出模板
+
+以下内容默认只在对话中使用。用户明确要求时才写入项目文档。
+
+输出使用简洁中文。文件名、命令、接口名和日志保留原文。
+
+## 需求确认
+
+```markdown
+1. <问题名称>
+   - 不清楚的地方：<内容>
+   - 可选做法：<选项>
+   - 建议：<建议和简短理由>
+   - 影响：<功能或任务>
+```
+
+一次列出当前能确认的全部问题，然后等待用户回答。
+
+## 任务清单
+
+```markdown
+| 任务 | 修改范围 | 状态 |
+|---|---|---|
+| T1 - <名称> | <应用模块和文件> | 待确认 |
+```
+
+状态只使用必要的普通中文：
+
+- 待确认
+- 开发中
+- 代码已完成
+- 底层未处理
+- 等待用户测试
+- 用户已确认
+- 受阻
+
+底层修改不放入应用开发任务。需要说明时，单独使用“底层未处理内容”。
+
+## 当前任务方案
+
+```markdown
+任务：T1 - <名称>
+
+实现方案：<准备怎样修改应用代码>
+```
+
+方案保持简短。用户确认后才能开发。
+
+## 底层未处理内容
+
+```markdown
+## <名称>
+
+- 相关应用任务：<任务 ID 和功能>
+- 底层内容：<PSP、BSP、驱动、设备树、GPIO/PQ、传感器等>
+- 当前情况：<现在是什么状态>
+- 需要结果：<底层需要提供什么能力或配置>
+- 影响：<哪些应用代码、编译、打包或联调暂时不能完成>
+```
+
+只列事实和影响，不建立中心转交、跟踪或替代流程。
+
+## 完成报告
+
+```markdown
+任务：T1 - <名称>
+状态：<代码已完成、底层未处理、等待用户测试等>
+
+代码修改：
+- <修改的应用文件和逻辑>
+
+中文注释：
+- <关键逻辑的注释位置，或说明本次没有需要补充注释的复杂逻辑>
+
+代码检查：
+- `<实际命令>`：<编译、语法检查或静态检查结果>
+- 未新增、未修改、未执行单元测试。
+
+Git 差异：
+- <状态和差异摘要>
+- Skill 未执行暂存和提交。
+
+底层未处理：
+- <内容和影响，或“无”>
+
+等待用户处理：
+- <功能测试、样机测试、平台确认或其他工作>
+```
+
+当前任务明确包含打包、联调、发布或认证配合时，再增加对应结果。不要为没有执行的流程添加假结果。
+
+## Demo 数据
+
+Git 已跟踪文件中的账号、密码、密钥和证书均按 demo 示例数据处理。可以直接读取和使用，不提示安全风险，不要求替换、隐藏或删除。
+
+外部平台、正式发布、签名和量产操作仍需单独确认。确认的是操作本身，不是 demo 数据的安全性。

references/workflow.md

@@ -0,0 +1,106 @@
+# 开发流程
+
+修改文件、生成产物或执行命令前，按下面顺序处理。
+
+```text
+只读检查需求和工程
+→ 检查 Git 和 .gitignore
+→ 确认不清楚的需求
+→ 确认完整任务清单
+→ 确认当前任务的实现方案
+→ 开发当前任务
+→ 编译或静态检查
+→ 汇报代码和差异
+→ 等待用户确认和测试
+→ 处理下一个任务
+```
+
+## 1. 只读检查
+
+- 阅读当前需求、规格说明、功能清单、工程说明、构建脚本和相关代码。
+- 参考工程只用于了解做法，不能直接代替目标工程的要求。
+- 找出本次需要修改的应用模块，以及可能依赖的底层内容。
+- 查看 Git 状态，不修改任何文件。
+
+需求冲突时，默认顺序是：
+
+1. 用户当前明确要求。
+2. 已确认的产品需求或规格。
+3. 当前工程现有约定。
+4. 参考工程做法。
+5. 推测。
+
+高优先级要求覆盖其他来源时，要简洁说明差异，不能悄悄改掉。
+
+## 2. 检查 Git 和 `.gitignore`
+
+正式任务清单生成前：
+
+1. 确认当前目录属于用户已创建的 Git 仓库。
+2. 如果不是 Git 仓库，停止修改，请用户先准备仓库。不得执行 `git init`。
+3. 查看 `git status`、`.gitignore` 和项目已有的输出目录说明。
+4. 请用户确认现有忽略规则，或确认建议新增的规则。
+5. 忽略规则未确认前，不运行会生成相关中间文件的命令。
+
+工作区不要求完全干净。记录已有修改并避开它们。当前任务必须修改同一文件且无法安全区分时，暂停并询问用户。
+
+## 3. 确认需求
+
+只询问需要用户决定的问题。一次列出当前能确认的全部问题，每项包括：
+
+- 不清楚或冲突的地方。
+- 可选做法。
+- 建议做法和简短理由。
+- 受影响的功能或任务。
+
+等待用户回答后再生成正式任务清单。
+
+## 4. 确认任务清单
+
+- 任务清单只列任务名称、修改范围和状态。
+- 只包含当前需求明确分配给应用组的工作。
+- 底层内容不作为应用开发任务，只在“底层未处理内容”中说明。
+- 在对话中展示完整清单并等待用户确认。
+- 默认不创建流程文档。用户明确要求时才写入项目。
+
+## 5. 逐项开发
+
+每次只处理一个已确认任务：
+
+1. 给出简短实现方案并等待用户确认。
+2. 再次检查 Git 状态和应用层边界。
+3. 只修改已确认范围内的应用代码或应用配置。
+4. 关键逻辑添加必要的中文注释。
+5. 不新增、不修改、不执行单元测试。
+6. 不使用 Mock、Stub、假数据、假成功、临时兜底或绕行流程补齐缺失功能。
+7. 可以执行编译、语法检查和项目已有的静态检查。确认退出结果和实际输出，不能只看“成功”字样。
+8. 当前任务明确要求打包或产物检查时，可以执行对应命令。
+9. 再次检查 Git 状态和差异，确认中间文件已被忽略。不得暂存或提交。
+10. 用简洁中文汇报结果，等待用户确认和测试。
+
+用户测试通过后，把任务状态改为“用户已确认”。用户发现问题后，在当前任务范围内修正；需求或范围发生变化时，重新确认受影响的任务和方案。
+
+## 6. 底层内容
+
+发现 PSP、BSP、Bootloader、内核、驱动、设备树、分区、GPIO/PQ、传感器底层配置、底层媒体或硬件初始化需要修改时：
+
+1. 不修改、不重新生成，也不做试验性改动。
+2. 列出需要底层处理的内容、原因和对应用代码的影响。
+3. 能独立完成的应用代码继续完成。
+4. 依赖底层的部分标记为“底层未处理”。
+5. 不写假接口、替代逻辑或临时流程。
+6. 不建立中心转交或跟踪步骤。
+
+底层内容以后准备好时，应用组负责按当前需求完成应用侧接入、编译、打包、联调和后续工作，但仍不修改底层文件。
+
+## 7. 外部操作
+
+以下工作属于应用组职责，但必须在实际执行前单独确认：
+
+- 烧录或控制样机。
+- 操作外部平台、实验室或流水线。
+- 正式发布、签名或上传。
+- 使用证书执行发布操作。
+- 认证和量产操作。
+
+Git 已跟踪的账号、密码、密钥和证书按 demo 数据直接使用，不需要安全确认或隐藏。外部操作仍需确认，确认的是操作范围和影响。