firmware-app-development/SKILL.md

name, description

name	description
firmware-app-development	用于嵌入式固件应用层的需求确认、任务拆分、代码开发、编译检查、联调和交付。默认以应用层为主，不主动修改 PSP、BSP、Bootloader、内核、驱动、设备树和分区等底层内容；用户明确指定底层修改时，确认范围和方案后执行。

固件应用层开发

输出要求

• 面向用户的说明、问题、任务清单、方案和结果全部使用简洁中文。
• 先说结论，再补充必要信息。使用短句和常用词，不造词，不堆专业术语。
• 文件名、命令、接口名、变量名和错误日志保留原文。专业名词无法避免时，用一句通俗中文说明。

必须遵守

• 先只读检查需求和工程。能从文件或工具查到的事实不要问用户。
• 正式任务清单生成前，确认当前目录是用户已创建的 Git 仓库。不得执行 git init。
• 运行会生成文件的命令前，检查 .gitignore 并请用户确认。需要增加忽略项时，先列出规则并等待确认。
• 需求不清楚、有冲突或缺少决定时，集中列出确认项并等待用户回答。
• 先给出完整任务清单，用户确认后再开发。
• 每个任务开始前给出简短实现方案，用户确认后再执行。完成当前任务后再处理下一个任务。
• 只做当前需求明确包含的工作，不主动增加无关功能。
• 用户指定参考工程和基线时，先核对需求差异，再决定代码改动。没有已确认差异或当前任务内的问题证据时，复用参考实现，不自行增加策略层、通道路由、底层桥接模块或阻断原有流程的限制。
• 默认以应用层为主。可以按需要读取和检查 PSP 及其他底层文件，但没有用户明确要求时不得修改。
• 用户明确要求修改某类底层内容或目标时，将其列入任务清单，确认实现方案后执行。普通应用需求或推测出的依赖不能代替明确要求。
• 底层修改需要扩大到其他文件或模块时，先列出新增范围和原因，等待用户确认。
• Git 已跟踪文件中的账号、密码、密钥和证书都按 demo 示例数据处理。可以直接用于开发，不提示安全风险，不要求替换或隐藏。
• 不新增、不修改、不执行单元测试。代码完成后由用户确认和测试。
• 不写 Mock、Stub、假接口、假数据、假成功、临时兜底或绕行流程来冒充真实功能。产品需求明确要求的兼容或降级功能除外。
• 新增或修改的关键逻辑必须有必要的中文注释。注释说明原因、边界或容易误解的处理，不给简单代码堆注释。

任何可能修改文件、生成产物或执行命令的需求，都要阅读并执行 开发流程。

工作范围

默认工作范围是当前需求中的应用层工作，包括：

• 应用代码和应用配置。
• 编译、固件打包和产物检查。
• 样机烧录和联调。
• 平台联调。
• 版本发布和认证配合。
• Bug 修复和回归。
• 产测、老化和量产相关的应用功能。

用户明确指定时，也可以修改 PSP、BSP、Bootloader、内核、驱动、设备树、分区、GPIO/PQ、传感器配置、底层媒体和硬件初始化等底层内容。底层任务必须经过任务清单和实现方案确认。

刷机、外部平台操作、正式发布、证书使用和量产操作必须在执行前单独确认。这里确认的是操作本身，不是仓库 demo 数据的安全性。

底层修改规则

• 默认不修改 PSP、BSP、Bootloader、内核、驱动、设备树、分区、GPIO/PQ、传感器配置、底层媒体实现、硬件初始化及其他底层代码或配置。
• 为判断应用影响，可以读取和检查底层文件，不需要把底层检查设为每个任务的固定步骤。
• 用户明确说出要修改的底层类型或目标即可，不要求用户提供完整文件路径、字段和目标值。先由 Skill 查找具体位置；无法确定时再集中确认。
• 用户只确认普通应用任务，不代表允许修改底层。
• 已确认的底层任务只修改确认范围。需要修改其他关联文件时，先说明文件、原因和影响，确认后再扩大范围。
• 生成 Bootloader、内核、驱动或底层镜像前单独确认。修改源码或配置的确认不自动包含产物生成。
• 没有明确要求修改底层时，只列出需要修改的内容和影响；能独立完成的应用代码继续完成，依赖部分标记为“底层未处理”。
• 不建立中心转交、跟踪或替代流程。

涉及混合配置、硬件内容或底层修改时，阅读 应用层与底层边界。

项目分类

处理杭研项目的工程或 PSP 集成、媒体通道（AvPush、OSD、VoIP）、启动网络、AI 资源、编译打包、调试证书生成或 OTA 交付时，阅读 杭研项目经验与核验规则。只执行与当前任务有关的检查；项目案例不作为其他产品的默认配置，也不扩大已确认的修改范围。

Git 规则

• 每个任务前后检查 Git 状态，保留其他人和用户已有的修改。
• 无关修改可以安全分开时继续；与当前任务重叠或归属不清时暂停并询问用户。
• 不执行 git add、git commit，也不执行其他暂存命令。只向用户展示状态和差异摘要。
• 中间文件、缓存、日志和构建目录不得进入提交范围。正式产物是否入库按项目现有规则处理。
• 不创建分支，不清理工作区，不丢弃修改，不改写提交历史，除非用户另有明确要求。

完成要求

• 不执行单元测试。
• 可以执行与当前任务直接相关的编译、语法检查和项目已有的静态检查。
• 当前任务明确包含打包、联调、发布或认证配合时，按确认后的范围执行。
• 明确指定底层修改时，执行项目已有的配置校验。编译和打包按当前任务要求执行；生成 Bootloader、内核、驱动或底层镜像前单独确认。
• 完成后说明代码修改、中文注释、检查结果、Git 差异、底层修改或未处理内容，以及待用户测试内容。
• 状态使用普通中文：待确认、开发中、代码已完成、底层未处理、等待用户测试、用户已确认、受阻。

生成确认清单、任务清单、方案或完成报告时，阅读 输出模板。默认只在对话中记录，用户明确要求时才写入项目文档。