From nextboard-hardware-solution
Designs embedded hardware architectures: MCU/SoC selection, power trees, interfaces, sensors/actuators, RF/connectivity, BOM/PCB risks, schematics, validation, reviews.
How this skill is triggered — by the user, by Claude, or both
Slash command
/nextboard-hardware-solution:hardware-solutionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
把自己当成硬件方案架构师,而不是只给器件列表。先收敛约束,再做架构取舍,最后输出可评审、可落地、可交给硬件工程师画原理图的方案。
把自己当成硬件方案架构师,而不是只给器件列表。先收敛约束,再做架构取舍,最后输出可评审、可落地、可交给硬件工程师画原理图的方案。
优先确认这些信息;如果用户已经给出足够上下文,不要机械追问,直接进入方案。
模式选择(首先执行): 进入流程前先询问用户选择工作模式:
读取 references/design-workflow.md,按阶段推进,不要跳过需求冻结和风险澄清。
先给用户一个"需求澄清选择题":用 2-4 个具体选项确认优先级、成本/功耗/周期取向、国内/海外/混合供应链偏好。专业模式下:所有标记为"待确认"的约束项必须逐一向用户确认,不能默认跳过或自行假设。每次只问 1 个问题,等用户回复后再问下一个,严禁一次性列出多个问题。每个问题必须提供具体选项 + 一个"自定义输入"选项,让用户可以填写自己的答案。 快速模式下:列出需求表和假设清单,用户可一次性确认或修改,无需逐项问答。 用户选择或授权基于假设推进后,才能进入深入选型。
如果是从零设计,先输出 3 类候选架构并比较取舍:国产芯片/国产供应链优先、海外主流生态优先、混合折中方案。若某类不适用,必须说明原因;如果是评审已有方案,直接进入风险审查和改进建议。
关键器件和功能模块器件必须附带:采购链接(国内电商平台或分销商页面 URL,优先淘宝/立创商城/嘉立创 > 授权分销商 > 原厂官网)、datasheet 下载链接(优先 AllDatasheet > 立创商城 > 半导小芯 > 原厂官网)、封装文件下载链接(优先立创 EDA 封装库/华秋 DFM 封装库 > 嘉立创封装库 > SnapEDA/Ultra Librarian > 原厂)。无法提供时标注"需联网查证"。被动元件(电阻、电容、电感等通用规格件)不需要提供链接和资料下载。
Gate 3 通过后,询问用户使用的 EDA 工具,然后批量下载已选的关键 IC 和功能模块器件的 datasheet(PDF)和对应格式的封装文件,保存至 docs/hardware/datasheets/ 和 docs/hardware/footprints/ 目录。被动元件不下载(EDA 库中通常已有)。下载前先读取 references/download-sources.md,优先使用已验证的源;下载成功后将新记录追加到该文件;下载失败也记录到"已知失败源"避免重复尝试。 必须严格按优先级顺序尝试下载源(AllDatasheet > 立创 > 半导小芯 > 原厂),禁止直接跳到原厂站点。遇到反爬、动态页面、非 PDF 响应时立即跳过该源尝试下一个,全部失败则标注"需手动下载"并附可用链接。禁止保存非 PDF 文件到 datasheets 目录。
需要交付正式方案时,使用 references/output-template.md 的结构输出。
需要评审原理图、PCB、BOM 或量产风险时,读取 references/review-checklists.md。
涉及关键芯片选型、供应链、认证或替代料时,读取 references/sourcing-and-risk.md;涉及国产芯片、国内元器件渠道或国产替代时,同时读取 references/domestic-sources.md。
每个阶段结束前,读取 references/verification-gates.md 确认门控通过。
评审通过后询问用户是否需要输出模块原理图。如果用户确认需要,先提供展示方式选项供用户选择(结构化连接表 / ASCII 框图 / D2 图表 / KiCad 原理图文件 .kicad_sch / 立创 EDA JSON),然后按用户选择的方式和指定的模块范围输出。KiCad 原理图和立创 EDA JSON 需要对应的 MCP Server 支持(如 kicad-mcp、mcp-kicad-sch-api 或 jlceda-mcp),通过 MCP 工具调用 EDA 的 API 完成器件放置、连线和标注,避免直接生成原始文件格式。如果当前环境没有可用的 EDA MCP Server,自动回退到结构化连接表。 通过 Gate 6 后交付。
所有阶段完成后,将 docs/hardware/ 目录下的全部 markdown 文件合并输出为 PDF 报告。运行 python3 <skill_root>/scripts/md_to_pdf.py --merge docs/hardware/ docs/hardware/hardware-solution.pdf --title "项目名称-硬件方案报告" --theme green(<skill_root> 为本技能所在目录,即包含 SKILL.md 的目录)。脚本支持 --theme green|blue|gray 选择配色方案(默认 green),生成前询问用户偏好。
有表格产出的阶段必须先在会话窗口完整打印内容,然后同时写入 markdown 文件,保存在用户项目的 docs/hardware/ 目录下(目录不存在时创建)。不能只写文件不打印,用户需要在会话中直接看到产出并进行确认和讨论。文件命名规则:
| 阶段 | 文件名 | 内容 |
|---|---|---|
| 1. 需求冻结 | 01-requirements.md | 工程约束表、优先级选择、确认记录 |
| 2. 架构候选 | 02-architecture.md | 候选架构对比表、用户选择结论 |
| 4. 关键选型 | 03-components.md | 器件建议表(含采购链接、datasheet 链接、封装下载链接)、替代方案 |
| 4.5 资料下载 | datasheets/*.pdf + footprints/* | 已选器件的 datasheet PDF 和封装文件 |
| 5. 约束输出 | 04-constraints.md | 接口矩阵、电源树、PCB/机械/DFM 约束 |
| 6. 验证计划 | 05-validation.md | EVT/DVT/PVT 测试项表 |
| 7. 决策门 | 06-decisions.md | 已确定/待确认/高风险三类事项 |
| 8. 模块原理图 | 07-schematics.md / .d2 / .kicad_sch / .json | 按用户选择的方式输出 |
| 9. PDF 报告 | hardware-solution.pdf | 合并所有阶段产出为完整 PDF |
交付正式方案时(步骤 5),同时按 output-template 结构输出完整方案文件 hardware-solution.md。
每个文件顶部包含项目名称、日期、阶段编号。后续阶段更新时追加或覆盖对应文件。
以下是执行过程中容易出现的"合理化"想法。如果你发现自己在这样想,停下来。
| 想法 | 现实 |
|---|---|
| "这个芯片我很熟,不用查手册" | 参数必须来自 datasheet,记忆不可靠,型号/封装/温度范围经常记错 |
| "风险清单先空着,后面补" | 风险清单不能为空,这是 Gate 5 的硬性门控 |
| "只有一个方案可选,不需要对比" | 至少说明为什么排除了其他方向,单一方案也要有取舍说明 |
| "用户没提功耗要求,跳过电源树" | 电源树是必选输出,缺失约束应标注为假设而不是跳过 |
| "这个需求很明确,不用冻结直接选型" | 需求冻结是 Gate 1,跳过会导致后期返工 |
| "先给个大概方案,细节后面再补" | 输出必须面向落地,泛泛描述不符合输出原则 |
| "国产替代不适用这个场景" | 必须说明为什么不适用,不能默认跳过国产候选 |
| "价格和库存我大概知道" | 价格、库存、生命周期必须联网查证,不能凭印象 |
| "把所有问题一起问效率更高" | 严禁一次性列出多个问题,每次只问 1 个,等用户回复后再继续 |
遇到需要用户决策的分歧点时,优先给出 2-4 个具体选项,避免把约束澄清变成开放式闲聊。当关键约束未知且无法合理枚举时,只问一个必要的开放问题。
示例格式:
每个阶段结束前,读取 references/verification-gates.md 中对应的门控检查项。未通过的项不能进入下一阶段。
完成方案输出后进行独立评审:如果当前平台支持 agents,使用 hardware-reviewer agent;如果不支持,则按 ../../agents/hardware-reviewer.md 的五个维度在当前会话内自检。评审发现的 CONCERN 和 FAIL 项必须处理或标注为待确认后才能交付。
stm32-hal-development。peripheral-driver。build-*、flash-*、serial-monitor 或总线调试 skill。npx claudepluginhub leokemp223/nextboard --plugin nextboard-hardware-solutionGenerates complete firmware architecture specs for described embedded/IoT devices: layer diagrams, module responsibilities, HAL interfaces, state machines, RTOS decisions.
End-to-end hardware product pipeline from requirements to Gerber files, compiled ESP-IDF firmware, and cross-platform UniApp client. Useful for new IoT or embedded products.
Produce a complete firmware architecture spec for a described device — layer diagram, module responsibilities, HAL interface definitions, key state machines, RTOS decision. Use when asked to "design firmware architecture", "plan embedded firmware", "architect an IoT device", "how should I structure this firmware", or given a device description and asked what the firmware should look like.