Agent的Skills（TODO）

如果你说的 Agent 是类似 Roo Code / Cline / Claude Code 这种"能读代码、执行命令、修改工程"的 Coding Agent，那么对嵌入式开发来说，Skill 的价值其实比普通软件开发更大。

因为嵌入式开发有大量"固定流程 + 平台知识 + 调试套路"，非常适合把人的经验固化成 Skill，让 Agent 从"通用代码生成器"变成一个懂 Qualcomm BSP / Linux Driver / Camera Bring-up 的工程助手。

我建议你不要一开始做很多 Skill，而是建立下面这种体系。

1. Skill 到底解决什么问题？

可以把 Agent 看成：

LLM + 工具 + Skill + 工程上下文

其中：

LLM：负责推理
Tools：grep、find、git、编译、adb、fastboot、串口等
工程代码：当前项目的事实
Skill：告诉 Agent "遇到这类问题应该怎么做"

例如你问：

"新增一个 SPI 设备。"

普通 Agent 可能直接：

复制代码

修改 DTS
写 driver
编译

但一个好的 spi-device-bringup Skill 会让它按照：

复制代码

1. 确认 SPI Controller
2. 确认 QUP instance / SE
3. 确认 pinctrl
4. 确认 CS
5. 确认 IRQ
6. 确认 DTS node
7. 判断 spidev / 自定义 driver
8. 检查 probe
9. 检查 /sys/bus/spi/devices
10. 检查 /dev/spidev*
11. 最后才进入用户态测试

这就完全不一样了。

2. 对嵌入式开发，我建议 Skill 分成 4 层

你的 Qualcomm BSP 工作尤其适合这种结构：

复制代码

skills/
│
├── platform/
│   ├── qualcomm-bsp/
│   ├── android-bsp/
│   ├── linux-kernel/
│   └── zephyr/
│
├── driver/
│   ├── gpio/
│   ├── i2c/
│   ├── spi/
│   ├── uart/
│   ├── v4l2/
│   ├── display/
│   └── sensor/
│
├── bringup/
│   ├── boot/
│   ├── camera/
│   ├── display/
│   ├── audio/
│   ├── connectivity/
│   └── power/
│
└── debug/
    ├── kernel-panic/
    ├── probe-failure/
    ├── suspend-resume/
    ├── performance/
    └── log-analysis/

但不要真的一开始建立这么多目录。

第一阶段只做 5～8 个高价值 Skill。

3. 第一优先级：把"你的经验"做成 Skill

这是最有价值的。

比如你现在已经比较熟悉：

Qualcomm BSP

复制代码

qualcomm-bsp-debug

里面告诉 Agent：

复制代码

# Qualcomm BSP Debug Skill

## Goal

分析 Qualcomm Android BSP bring-up 问题。

## First principles

遇到问题首先确定属于：

1. Boot
2. Kernel
3. Device Tree
4. Driver
5. HAL
6. Framework
7. Application
8. Firmware / DSP

## Required workflow

不要直接修改代码。

首先：

1. 获取 log
2. 定位 subsystem
3. 确认运行阶段
4. 找对应 driver
5. 找 DTS node
6. 找 probe
7. 找 runtime error
8. 再提出修改方案

## Qualcomm specific checks

检查：

- dmesg
- vendor log
- Android logcat
- DTB
- vendor_boot
- boot.img
- modules
- firmware
- SELinux
- power domain
- clocks
- regulators
- pinctrl

这个 Skill 的作用不是告诉 LLM 什么是 Linux。

而是：

规定 Agent 应该怎么思考。

这点非常重要。

4. 第二优先级：把 Bring-up 流程做成 Skill

这个对你现在的方向尤其重要。

例如：

复制代码

camera-bringup

Agent 接到：

"新增一个 camera sensor"

不要让它直接写代码。

Skill 可以规定：

复制代码

Camera Bring-up

Phase 1: Hardware
    ↓
Sensor
    ↓
Power
    ↓
Reset
    ↓
MCLK
    ↓
I2C
    ↓
MIPI CSI
    ↓
GPIO

Phase 2: Kernel
    ↓
I2C detection
    ↓
sensor driver probe
    ↓
media entity
    ↓
V4L2 subdev
    ↓
CSI receiver
    ↓
media graph

Phase 3: Android
    ↓
Camera HAL
    ↓
provider
    ↓
framework
    ↓
CameraService
    ↓
Camera2 API

Phase 4: Validation
    ↓
I2C
    ↓
stream
    ↓
frame
    ↓
FPS
    ↓
format
    ↓
resolution

这样 Agent 就不会出现：

"摄像头不能打开，我先修改 HAL。"

这种典型的乱修。

5. 第三优先级：建立"Debug Skill"

这个可能是ROI最高的 Skill。

因为嵌入式开发大量时间不是写代码，而是：

分析为什么不能工作。

比如：

复制代码

kernel-driver-debug

规定 Agent：

复制代码

当 driver 不工作时：

Step 1
确认 device 是否存在

Step 2
确认 driver 是否加载

Step 3
确认 probe 是否执行

Step 4
确认 probe 返回值

Step 5
确认依赖资源

- regulator
- clock
- reset
- gpio
- pinctrl
- irq
- dma

Step 6
检查 runtime PM

Step 7
检查 suspend/resume

Step 8
检查硬件通信

I2C:
    i2cdetect
    reg read

SPI:
    spidev_test

GPIO:
    gpioget/gpioset

Camera:
    media-ctl
    v4l2-ctl

这会让 Agent 的行为非常稳定。

6. 更进一步：Skill + Command

这是嵌入式 Agent 真正厉害的地方。

例如：

复制代码

camera-bringup

不仅告诉 Agent：

"使用 v4l2-ctl"

还可以规定：

复制代码

先执行：

v4l2-ctl --list-devices

然后：

media-ctl -p

然后：

v4l2-ctl --list-formats-ext

然后：

dmesg | grep -i camera

于是 Agent 就从：

"告诉你应该怎么查"

变成：

自己查，然后根据结果继续推理。

这才是 Agent。

7. Skill 最好不要写成"知识百科"

这是很多人做 Skill 最大的问题。

例如不要写：

复制代码

# SPI Skill

SPI is a synchronous serial communication protocol...

SPI has:
- SCLK
- MOSI
- MISO
- CS
...

这种东西 LLM 本来就知道。

Skill 应该写：

复制代码

# SPI Bring-up

When user asks to add or debug an SPI device:

## Step 1
Identify SPI controller.

Search:
drivers/spi/
arch/arm64/boot/dts/

## Step 2
Identify QUP / SE instance.

## Step 3
Check pinctrl.

## Step 4
Check CS.

## Step 5
Check DTS node.

## Step 6
Determine driver type:

- spidev
- spi_driver
- platform_driver

## Step 7
Verify device registration:

/sys/bus/spi/devices/

## Step 8
Verify userspace interface:

/dev/spidev*

## Do not

Do not write a new driver before determining whether
an existing driver already exists.

Skill 应该是"操作规程"，而不是"教科书"。

8. 你的 Qualcomm 环境特别适合做"分层 Skill"

比如：

复制代码

qualcomm/
│
├── boot.md
├── dt.md
├── qup.md
├── pinctrl.md
├── power.md
├── dma-buf.md
├── camera.md
├── display.md
└── audio.md

然后再建立一个：

复制代码

qualcomm-debug.md

作为总入口。

例如：

复制代码

User:
camera sensor probe failed

Agent：

复制代码

qualcomm-debug
        ↓
camera-bringup
        ↓
i2c
        ↓
pinctrl
        ↓
power

这实际上形成了一个 Skill Graph。

9. 再往前一步：把 Qualcomm 文档变成"知识库"，不要全部塞进 Skill

这个非常重要。

你之前考虑过把 Qualcomm PDF 放进 Roo Code 的 .roo/rules。

我的建议是：

Skill

放：

怎么工作

Documentation

放：

具体事实

例如：

复制代码

Skill:

"检查 QUP SPI 的流程"

Documentation:

SM8550 QUPv3 register
SE3 base address
clock name
GCC configuration
TLMM configuration

不要把几十页 PDF 全写进 Skill。

应该让 Agent：

复制代码

Skill
 ↓
需要 Qualcomm SE3 信息
 ↓
搜索 Qualcomm docs
 ↓
找到相关章节
 ↓
再进行判断

这样 token 消耗会低很多。

10. 一个非常实用的 Skill：代码修改前先"调查"

我非常建议你建立：

复制代码

investigate-before-modify

内容大概：

复制代码

# Investigate Before Modify

Never modify code immediately.

Before changing code:

1. Identify affected subsystem.
2. Search existing implementation.
3. Find caller.
4. Find callee.
5. Find DTS node.
6. Find driver registration.
7. Find related configuration.
8. Check similar implementation.
9. Check build dependency.
10. Explain root cause.

Only then modify code.

After modification:

1. Show changed files.
2. Explain why each change is required.
3. Build affected target.
4. Report build result.
5. Suggest hardware validation.

这个 Skill 对嵌入式尤其有效。

因为嵌入式最怕 Agent：

找到一个 .c → 改 → 编译 → 再报错 → 再改。

最后把代码改得一团糟。

11. 可以进一步做"项目级 Skill"

比如你现在做 AR1。

完全可以建立：

复制代码

ar1-project/
│
├── architecture.md
├── boot-flow.md
├── camera-flow.md
├── display-flow.md
├── audio-flow.md
├── sensor-flow.md
├── power-flow.md
└── debug-flow.md

然后：

复制代码

AR1 Skill

告诉 Agent：

复制代码

Project:

Snapdragon AR1
Android
Qualcomm BSP

Important repositories:
...

Build system:
...

Image structure:
...

Boot chain:
...

Known hardware:
...

Known issues:
...

Do not assume:
...

这时候 Agent 对你的项目的理解就会非常接近一个：

刚加入项目、但已经读过大量项目资料的高级 BSP 工程师。

12. 我认为你最应该做的 6 个 Skill

结合你现在的工作和你正在学习的方向，我会这样排优先级：

优先级	Skill	ROI
⭐⭐⭐⭐⭐	`investigate-before-modify`	极高
⭐⭐⭐⭐⭐	`qualcomm-bsp-debug`	极高
⭐⭐⭐⭐⭐	`linux-driver-debug`	极高
⭐⭐⭐⭐	`camera-bringup`	很高
⭐⭐⭐⭐	`power-debug`	很高
⭐⭐⭐	`android-bsp-build`	高

以后再增加：

复制代码

display-bringup
audio-bringup
sensor-bringup
dma-buf-debug
suspend-resume-debug
performance-debug

13. 最终你想达到的效果

理想状态不是：

"我有 50 个 Skill。"

而是：

复制代码

                     User
                       │
                       ▼
                    Agent
                       │
             ┌─────────┴─────────┐
             │                   │
           Skill              Project
             │                 Context
             │                   │
             ▼                   ▼
       工作流程/方法          当前代码/DTS
             │                   │
             └─────────┬─────────┘
                       ▼
                    Tools
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
      grep           build           adb
        │              │              │
        ▼              ▼              ▼
      source         compile          log
                       │
                       ▼
                    Debug
                       │
                       ▼
                  Modify Code
                       │
                       ▼
                    Verify

也就是说：

Skill 不负责替 Agent 干活，而是负责规定 Agent 干活的方法。

这对于嵌入式尤其有价值，因为嵌入式开发的核心经验本来就是：

"出了问题，我知道应该先查哪里、再查哪里、什么现象意味着什么。"

把这个东西固化成 Skill，才是真正把你的 BSP 经验"复制"给 Agent。

如果你现在主要使用 Roo Code ，我建议下一步直接给你设计一套 .roo/skills 的 Qualcomm BSP + Linux Driver + Camera Bring-up 实际目录和 SKILL.md 模板，而不是停留在概念层面。

在 OpenCode 里，`skill` 是按需加载的复用指令：每个 skill 就是一个目录下的 `SKILL.md`。

Agent 会先看到 `name + description`，需要时才调用 `skill({name:"xxx"})` 加载全文。对嵌入式很合适，因为工具链碎、约束多、重复流程多。

1. 放哪里

```

项目级(推荐,跟代码走): .opencode/skills/<name>/SKILL.md

全局(跨项目): ~/.config/opencode/skills/<name>/SKILL.md

兼容: .claude/skills/, .agents/skills/

```

`name` 必须和目录名一致，小写+`-`，如 `stm32-hal-init`。

最小模板：

```md

name: stm32-hal-init

description: STM32CubeMX/HAL外设初始化,时钟树,GPIO,中断优先级检查

What I do

按给定MCU生成初始化顺序
检查时钟/HAL调用顺序
给出可粘贴的代码片段

When to use me

当用户说初始化USART/I2C/SPI/TIM/DMA时使用。

```

`description` 1-1024字符，是触发关键，要写具体关键词。

2. 嵌入式提效的 skill 清单

按你的平台拆 5-7 个小 skill，不要做大而全：

`toolchain-build-flash`: `arm-none-eabi-gcc + cmake + OpenOCD/JLink` 编译烧录流程，常用命令、`.cfg`选择、报错对照。
`mcu-init`: STM32/ESP32/NRF52 的时钟、GPIO、NVIC、中断优先级，HAL/LL/IDF/Arduino 规范。
`driver-template`: UART/I2C/SPI/DMA 中断+DMA双模式驱动模板，含超时、重入保护。
`misra-c-check`: MISRA-C关键规则、静态检查清单、`cppcheck --enable=all`配置。
`memory-optimize`: `.ld`链接脚本、Flash/RAM占用分析`arm-none-eabi-size`，`attribute((section))`用法。
`low-power-debug`: Sleep/Stop模式、HardFault解析、RTT/SWO日志、逻辑分析仪抓包步骤。
`host-unit-test`: 在PC上用 `cmocka/cpputest` mock寄存器做单元测试。

3. 用法

你不用手动调，描述里命中关键词 Agent 会自动加载。比如你说"初始化 STM32F4 USART2 + DMA"，它会加载 `mcu-init` + `driver-template`。

权限控制在 `opencode.json`：

```json

{ "permission": { "skill": { "*": "allow", "experimental-*": "ask" } } }

```

4. 建议

* 一个 skill 只做一件事，`SKILL.md` 控制在 100-200行。

* 把寄存器手册链接、实测过的命令、坑点写进去，别写空话。

* 项目级放跟硬件相关的，全局放 `misra-c-check` 这种通用的。

你现在用哪款 MCU + 工具链？比如 `STM32 + HAL + GCC + OpenOCD` 还是 `ESP-IDF`？我可以直接帮你生成前 2-3 个 `SKILL.md` 脚手架。

对。结合你现在的情况------Roo Code + Qualcomm BSP + Linux Driver + Android + Camera Bring-up ------我不会给你一个泛泛的"Skill 排行榜"，而是按对嵌入式开发的实际 ROI来排。

现在 Agent Skills 已经是一个比较明确的开放规范，Roo Code 原生支持 .roo/skills 和跨 Agent 的 .agents/skills；很多 GitHub Skill 可以直接复用。(Roocode Inc.)

我给你的 TOP 10

排名	Skill	对你	主要用途
🥇 1	systematic-debugging	⭐⭐⭐⭐⭐	BSP/Driver/Kernel 调试
🥈 2	root-cause-tracing	⭐⭐⭐⭐⭐	从现象反向追根因
🥉 3	verification-before-completion	⭐⭐⭐⭐⭐	防止 Agent "改完就说好了"
4	writing-plans	⭐⭐⭐⭐⭐	大型 BSP 修改前规划
5	code-review	⭐⭐⭐⭐	Driver/DTS/Kernel 修改审查
6	test-driven-development	⭐⭐⭐⭐	可测试的 C/C++/Linux 代码
7	Android Skills	⭐⭐⭐⭐	Android/BSP/framework
8	harness-engineering	⭐⭐⭐⭐	建立你自己的 Agent 工作规范
9	agentic-eval	⭐⭐⭐	测试 Skill/Agent 是否真的有效
10	skill-creator	⭐⭐⭐	后面自己制作 Qualcomm Skill

但这里面有一个关键点：

前 6 个我强烈建议装；7~10 根据你的工作方式再装。

1. 🥇 systematic-debugging

这是我认为你最值得装的一个。

来自 obra/superpowers：

obra/superpowers --- systematic-debugging

它的核心原则就是：

不要看到现象马上改代码，先找 root cause。

它要求 Agent：

复制代码

1. Read error
2. Reproduce
3. Check recent changes
4. Gather evidence
5. Find working example
6. Form hypothesis
7. Test hypothesis
8. Fix
9. Verify

这对 Qualcomm BSP 简直太合适。

比如：

复制代码

Camera probe failed

普通 Agent：

复制代码

修改 DTS
↓
编译
↓
失败
↓
改 driver
↓
编译
↓
失败

systematic-debugging 会强制它先：

复制代码

dmesg
 ↓
probe error
 ↓
return code
 ↓
regulator?
 ↓
clock?
 ↓
GPIO?
 ↓
I2C?
 ↓
driver?
 ↓
DTS?

这个 Skill 明确要求在 root cause investigation 完成前不要提出修复方案。(GitHub)

你做 BSP，我认为这是第一名。

2. 🥈 root-cause-tracing

同一个 Superpowers 体系。

root-cause-tracing

它特别适合：

复制代码

kernel crash
driver probe failure
NULL pointer
wrong GPIO state
camera frame timeout
suspend/resume failure

例如：

复制代码

camera stream timeout
        ↓
CSI timeout
        ↓
CSI 没收到 frame
        ↓
sensor 没输出
        ↓
sensor streaming command?
        ↓
I2C?
        ↓
power?
        ↓
MCLK?

这其实就是一个 BSP 工程师平时脑子里的：

"沿着错误链往上游追。"

所以它和第一个组合起来非常强。

3. 🥉 verification-before-completion

这个对于 Coding Agent 特别重要。

verification-before-completion

防止 Agent 出现这种情况：

复制代码

Agent:
"已经修复了问题。"

实际上：

复制代码

没编译
没测试
没刷机
没看 log

这个 Skill 的目的就是：

在 Agent 宣称"完成"之前必须验证。

对嵌入式尤其重要，因为很多问题：

复制代码

compile OK
≠
boot OK

boot OK
≠
driver probe OK

probe OK
≠
hardware communication OK

communication OK
≠
functional OK

比如 Camera：

复制代码

kernel build
 ↓
boot
 ↓
sensor probe
 ↓
media graph
 ↓
stream
 ↓
frame
 ↓
FPS
 ↓
image quality

Agent 不能只做到第一层就说完成。

4. writing-plans

writing-plans

这个对 Qualcomm BSP 也很有用。

比如你说：

"增加一个新的 camera sensor。"

不要直接让 Agent 改代码。

先让它产生：

复制代码

Plan

1. DTS
2. GPIO
3. regulator
4. clock
5. I2C
6. sensor driver
7. V4L2
8. media graph
9. CSI
10. build
11. flash
12. validation

然后再执行。

大型 BSP 修改非常适合这种模式。

5. Code Review Skill

这个可以从 GitHub 的 awesome-copilot 体系里挑。

github/awesome-copilot Skills

这里的 Skills 数量很多，不建议你全部安装。

对于你主要找：

复制代码

code-review
quality
security
testing

尤其适合：

复制代码

修改 DTS
修改 kernel driver
修改 HAL
修改 Camera code
修改 power management

让第二个 Agent / 第二轮 Agent 做：

"Review my changes as a senior Linux kernel engineer."

而不是让同一个 Agent 自己说自己写得没问题。

6. test-driven-development

Superpowers 里面也有：

test-driven-development

对纯 Linux/embedded 软件非常有用。

但是我要特别提醒：

不要把 TDD 当成嵌入式开发的万能技能。

对于：

复制代码

DTS
GPIO
I2C
SPI
Camera sensor
PMIC
MIPI CSI

很多东西无法传统 TDD。

但是对于：

复制代码

HAL
userspace daemon
protocol parser
sensor algorithm
configuration
utility
IPC

就很有价值。

所以我给它第四梯队，而不是第一梯队。

7. Android Skills

这个反而是你目前非常值得关注的。

Google 的官方：

android/skills

这个不是普通社区项目，而是 Android 官方维护的 Agent Skills 仓库 。目前已经有专门针对 Android 开发的模块化 Skill。(GitHub)

对你：

复制代码

Qualcomm
   ↓
Android
   ↓
HAL
   ↓
Framework
   ↓
Service
   ↓
Application

这一层特别有价值。

尤其以后你做：

复制代码

Camera HAL
Audio HAL
Sensor HAL
Android Service
JNI/NDK
AIDL
Framework

会比普通 Coding Skill 有意义得多。

8. harness-engineering

这个来自 awesome-copilot：

harness-engineering

这个比较"高级"。

它不是帮你写代码，而是帮你：

把整个 Repo 改造成更适合 Agent 工作的环境。

例如：

复制代码

AGENTS.md
项目规则
build instructions
test instructions
known issues
architecture
verification

它强调：

inspect before editing

preserve existing architecture

add smallest useful harness

make important rules enforceable

(GitHub)

这个对你以后把：

复制代码

AR1 project
Qualcomm BSP
公司代码
build system
DTS
kernel
vendor
HAL

整个交给 Agent 管理非常有用。

9. agentic-eval

也是 awesome-copilot 的：

agentic-eval

它解决的是一个更高级的问题：

怎么知道一个 Skill 到底有没有用？

比如你自己写：

复制代码

qualcomm-camera-bringup

你不能只是：

复制代码

感觉 Agent 好像聪明了

而应该测试：

复制代码

Case 1:
I2C probe failure

Case 2:
MCLK missing

Case 3:
CSI timeout

Case 4:
wrong regulator

Case 5:
suspend/resume failure

然后：

复制代码

Without Skill
     VS
With Skill

比较 Agent 是否真的改善。

这也是 Agent Skills 开始走向工程化的重要一步。

10. skill-creator

最后这个我建议你现在先不急着用。

官方 Anthropic：

anthropics/skills

其中有：

复制代码

skills/skill-creator

(GitHub)

它专门教你怎么设计、测试 Skill。

等你真正发现：

"现有 Skill 对 Qualcomm BSP 不够。"

再用它。

但是有一个非常重要的结论

你可能会发现一个问题：

现在真正针对 Qualcomm BSP / Linux Kernel / Camera Bring-up 的成熟 Skill 并没有想象中那么多。

这很正常。

现在 Skill 生态大量集中在：

复制代码

Web
Python
React
DevOps
Cloud
Documentation
Testing
AI
Android

而：

复制代码

Qualcomm BSP
Linux kernel
Device Tree
MIPI CSI
QUP
TLMM
ADSP
CDSP
CAMSS
PMIC

这种高度专业领域，目前公开 Skill 远没有那么成熟。

所以对你来说，我认为最好的路线不是：

找 100 个 Embedded Skill。

而是：

复制代码

              Superpowers
                  │
        ┌─────────┼──────────┐
        ▼         ▼          ▼
    Debugging   Planning   Verification
        │
        ▼
   Linux / Android Skills
        │
        ▼
    Qualcomm BSP
        │
        ▼
 ┌──────┼───────┐
 ▼      ▼       ▼
Camera  Power   Driver

前面用成熟 Skill，后面自己补 Qualcomm 专业 Skill。

如果是你，我现在只装这 6 个

不要贪多：

复制代码

1. systematic-debugging
2. root-cause-tracing
3. verification-before-completion
4. writing-plans
5. Android Skills
6. code-review

其中 1~4 直接来自 Superpowers ；它本身就是一套比较完整的 Agent 工程方法论，包含 debugging、testing、planning、code review、git/worktree 等一整套技能。(GitHub)

然后用：

Vercel skills CLI

来管理跨 Agent Skill。它目前明确支持 Roo Code，而且同一套 Agent Skills 可以安装到很多不同的 Coding Agent。(GitHub)

对你的 Roo Code

Roo 官方已经支持：

复制代码

%USERPROFILE%\.roo\skills\

以及跨 Agent：

复制代码

%USERPROFILE%\.agents\skills\

所以你完全可以把这些 Skill 放进去。(Roocode Inc.)

不过我不建议你现在一次装 50 个。

Skill 太多虽然不会全部塞进基础 prompt------Roo 是按任务动态加载相关 Skill 的------但大量重叠 Skill 会增加触发冲突和行为不确定性。(Roocode Inc.)

如果你愿意，我下一步可以直接给你整理成一个 "Roo Code 嵌入式开发 Skill Pack" ：把上面 6 个的具体 GitHub 地址 + Roo 安装命令 + 哪些值得装、哪些不要装列成可以直接照着执行的清单。

你的最佳方案其实是：

先装 5 个通用 Skill

复制代码

systematic-debugging
root-cause-tracing
verification-before-completion
writing-plans
code-review

然后建立：

复制代码

~/.codex/skills/

├── systematic-debugging/
├── root-cause-tracing/
├── verification-before-completion/
├── writing-plans/
├── code-review/
│
└── qualcomm-bsp/

其中前五个来自成熟生态。

而：

复制代码

qualcomm-bsp/

是你自己逐渐积累的。

为什么我反而建议你自己做 Qualcomm Skill？

因为你的情况和普通开发者不一样。

你已经碰过：

复制代码

Qualcomm BSP
QSSI
GKI
vendor_boot
DTS
QUP
TLMM
SPI
I2C
GPIO
DMA-BUF
Camera
V4L2
Android
ADSP
CDSP
Power

所以你实际上已经具备一个很好的 Skill 数据源：

你平时排查 Qualcomm BSP 问题的思维过程。

比如你以后把：

复制代码

Camera probe failed

整理成：

复制代码

qualcomm-camera-debug

Codex 就可以形成：

复制代码

Camera error
     ↓
identify layer
     ↓
I2C
     ↓
power
     ↓
reset
     ↓
MCLK
     ↓
sensor probe
     ↓
V4L2
     ↓
CSI
     ↓
media graph
     ↓
Android HAL

这个 Skill 的价值可能比你从 GitHub 找 20 个普通 Skill 都高。

而且 Codex 官方现在本身就提供 $skill-creator，可以帮助创建/更新 Skill；Skill 本质上就是 SKILL.md 加上可选的 scripts/references/assets。

还有一个对你特别有用的点

Codex 支持 显式调用 和隐式调用。

比如：

复制代码

$systematic-debugging

可以明确要求使用某个 Skill；

也可以让 Codex 根据 Skill 的 description 自动判断：

复制代码

camera probe failed

→ 自动选择 qualcomm-camera-debug。

所以最终你甚至可以做到：

复制代码

你：
Camera suspend 后恢复不了

Codex：
    ↓
qualcomm-camera-debug
    ↓
power-debug
    ↓
suspend-resume-debug
    ↓
systematic-debugging
    ↓
开始检查

这才是我认为 Skill 对你这种嵌入式/BSP 工程师真正有价值的地方。

如果只让我给你一个建议：Codex 不要装 50 个 Skill。先装 5 个通用 Skill，然后专门做一套 Qualcomm BSP Skill Pack。这会比单纯下载别人 Skill 的收益大得多。