embedded-project-initializer

Embedded Project Initializer

操作说明：首次使用请阅读 references/usage-guide.md，涵盖安装、输入格式、产物说明、典型场景与常见问题。

职责

本 Skill 是嵌入式项目初始化的编排器。收到用户输入的硬件信息（芯片、引脚、外设）+ 固件需求（行为、协议栈、RTOS）+ 项目规范（架构、工具链、目录约定），产出：

支持单程序（一个芯片一个固件）和多程序（多个独立固件通过 UART/I2C/SPI/BLE 等互连）两种模式。

何时使用本 Skill

• •用户说「帮我初始化一个 XXX 芯片的嵌入式项目」
• •用户粘贴引脚表 + 需求描述，希望生成项目级 Skill
• •用户希望从零搭建带硬件事实源的嵌入式开发者 Skill
• •不适用：仅分析单一寄存器、仅查手册片段（用 chip-skill 生成器）

五步工作流（多程序模式为六步）

步骤 0：判断项目类型（新增）

Agent 从用户自然语言中识别程序实体：

1. 提取所有芯片型号和功能角色
2. 判断单程序还是多程序
3. 若是多程序，识别互连关系（接口类型、协议）
4. 回显识别结果给用户确认
5. 用户确认后，进入对应分支

多程序向导问题顺序（先拓扑后填充）：

Q1: "这个产品由几个独立的固件程序组成？"
    → 1 个 → 走单程序流程（跳过 Q2-Q4）
    → N 个 → 列出已识别的程序清单让用户确认

Q2: "程序之间怎么通信的？"
    → 逐个询问 from→to 的接口和协议
    → 写入 interconnects[]

Q3-N: 对每个程序：
    → 芯片型号 + 封装
    → 核心功能简述
    → 关键外设概览
    → 工具链（与前面程序相同时复用）
    → 与哪些其他程序通信

确认信息后 → 生成骨架 manifest 回显 → 用户确认

步骤 1：校验输入

1. 加载 references/input-grading.md，检查用户输入是否覆盖 P0 必填项

- 单程序：检查 P0-1~P0-3 - 多程序：检查 P0-1~P0-5

1. 若 P0 不全：输出「待补信息清单」（注明哪个程序缺哪些项）+ 可附带最小 SKILL.md 骨架
2. 若 P0 齐全：继续步骤 2

步骤 2：抽取与确定范围

1. 读取 references/input-template.yaml，将用户输入规范为 project_manifest
2. 将抽取结果回显给用户确认，未确认项标为 [待确认]

- 多程序时逐个程序回显，最后回显互连关系

1. 读 references/modules-catalog.md，按 manifest 自动选取模块组合
2. 读 references/scope-contract.md，生成五项范围约束草稿

- 多程序时按 scope-contract.md 的多程序模板生成

1. 写入 `project-manifest.yaml`：将确认后的 manifest 写入产物目录根

步骤 3：生成产物

1. 按 references/output-spec.md 产出全部文件
2. 命名规则：

- 单程序：<芯片型号小写>-<项目名小写>/ - 多程序：<项目名小写>/（不含芯片前缀）

1. 首先生成 `project-manifest.yaml`，再产出 references/scope.md，然后其他 references/，最后写 SKILL.md
2. 多程序时：

- references/pin-maps/、references/chip-summaries/ 按程序生成独立文件 - 生成 references/interconnects.md - 共享文档引用放入 docs/resources/

1. 每个产出文件末尾自动追加 ## 变更记录 表格

步骤 4：校验产物

1. 加载 references/modules-catalog.md 中 A5 校验模块规格
2. 按 references/output-spec.md C 类校验层产出 references/validation-checklist.md
3. 逐项检查状态：

- P0 字段覆盖全 PASS → 产物完整，交付 - 任一 P0 FAIL → 退回步骤 2

1. 多程序时额外校验：

- 每个程序的 P0 字段是否齐全 - interconnects 中的 name 是否都对应到 programs

增量更新（对话或脚本均可）

当用户基于已有项目 skill 提出更新需求时：

1. 读取产物目录中的 project-manifest.yaml
2. 对比用户新需求，识别变更字段（可涉及单个或多个程序）
3. 仅更新受影响文件的对应章节（非全量重生成）
4. 保持不变章节的用户手动编辑
5. 遇到冲突 → 输出冲突报告
6. 更新完成为所有受影响文件追加 CHANGELOG 条目

核心约束

• •范围锁死：任何代码、寄存器、引脚复用只能来自用户材料或 scope.md 中标记的 Assumptions；禁止从模型记忆中补充
• •P0 不全不填细节：缺料号、引脚源、需求行为中任一项，不得写入具体寄存器地址、复用表、外设实例编号
• •生成物可核对：每项 Evidence 须标注来源（用户哪段输入/哪页手册）；无法追溯的标为「未提供」
• •SKILL.md 保持 <200 行：详细规范全在 references/ 中按需加载

References 索引