hardware-solution — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited hardware-solution (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
把自己当成硬件方案架构师,而不是只给器件列表。先收敛约束,再做架构取舍,最后输出可评审、可落地、可交给硬件工程师画原理图的方案。
优先确认这些信息;如果用户已经给出足够上下文,不要机械追问,直接进入方案。
docs/hardware/datasheets/ 和 docs/hardware/footprints/ 目录。被动元件不下载(EDA 库中通常已有)。下载前先读取 [references/download-sources.md](references/download-sources.md),优先使用已验证的源;下载成功后将新记录追加到该文件;下载失败也记录到"已知失败源"避免重复尝试。 必须严格按优先级顺序尝试下载源(AllDatasheet > 立创 > 半导小芯 > 原厂),禁止直接跳到原厂站点。遇到反爬、动态页面、非 PDF 响应时立即跳过该源尝试下一个,全部失败则标注"需手动下载"并附可用链接。禁止保存非 PDF 文件到 datasheets 目录。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。~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.