feat: 添加 rtthread-bsp-builder 与 rtconfig-kconfig-sync 技能

[silencebadwolf]

变更内容

新增技能

• rtthread-bsp-builder — 查找官方 RT-Thread BSP 并按 BSP README 推动构建（支持 GCC/MDK/IAR/RT-Studio）
• rtconfig-kconfig-sync — .config / rtconfig.h / Kconfig 同步检查

遵循 RT-Thread 风格

• 以官方 BSP 布局和 BSP README 为主要依据
• 不发明默认项目结构
• 不把 CMake/VS Code/编号分层设为强制项
• 根据 BSP README 推荐的构建目标选择，不默认假设 GCC

文件清单

LICENSE
README.md
skills/rtthread-bsp-builder/  (SKILL.md + scripts + references)
skills/rtconfig-kconfig-sync/ (SKILL.md)

[BernardXiong]

好像很复杂，并且并不是RT-Thread的风格？有很多cmake相关的，工程模板也是带编号的方式？

[BernardXiong]

感谢PR，以下是AI这边详细review后给出的建议：

PR #1 Review：RT-Thread Skills

PR：#1

总体结论

建议：暂时不要直接合入，建议维护者先 Request changes。

这个 PR 当前并不是 merge conflict 层面的阻塞，而是范围控制和 RT-Thread 风格适配问题。PR 标题说明新增 3 个 RT-Thread 相关 skill，但实际补丁还包含 GitHub PR 工作流 skill、大型 CMake 与编号分层工程模板、FNA1000 项目经验，以及 Windows Env 辅助脚本。

按当前形态看，它更像某个项目团队的工程模板知识库，而不是通用的 RT-Thread skill 集合。

主要问题

1. PR 范围过宽

README.md 中只列出了：

• rtthread-bsp-builder
• rtthread-project-generator
• rtconfig-kconfig-sync

但 PR 实际还新增了 skills/github-fork-and-pr/SKILL.md。这个 skill 与 RT-Thread 没有直接关系，应从本 PR 中移除，或单独提交。

2. rtthread-project-generator 不符合通用 RT-Thread 风格

该 skill 把 01_applications、02_services、03_components、04_drivers、05_port / 05_Implementation、06_platform、99_external 这类编号工程布局作为核心规则。

这不是 RT-Thread 官方 BSP 的常见风格。通用 RT-Thread 工作流应从官方 rt-thread 仓库、BSP 目录、BSP README、Env、SCons、Kconfig、.config、rtconfig.h、pkgs --update 以及 scons --target=mdk5、scons --target=iar 等导出目标出发。

CMake、VS Code、clangd、CTest、host tests 和编号分层对某些项目化应用模板可能有价值，但不应被呈现为 RT-Thread 的默认工程风格。

3. 项目模板内部存在不一致

项目生成器和校验脚本仍在引用旧层名：

• tools/new_project.py 要求 05_Implementation
• scaffold/tools/check_numbered_scons_layout.py 要求 05_Implementation
• manifest.yaml 描述的是旧的 02_components、03_drivers、05_board 路径

但 PR 实际提交的 scaffold 文件树包含的是 05_port。这会导致生成或校验结果不可靠。

4. rtconfig-kconfig-sync 把通用配置同步和项目化 CMake 案例混在一起

这个 skill 的核心主题是有价值的，但当前内容混合了：

• .config
• rtconfig.h
• Kconfig
• SConscript
• 生成的 CMakeLists.txt
• LVGL / HAL 链接问题
• FNA1000 专属导出闭环记录

作为通用 RT-Thread skill，CMake 和 FNA1000 相关内容应移动到独立的项目化 CMake 参考中，或从默认流程中删除。

5. github-fork-and-pr 存在安全性和相关性问题

这个 skill 超出了 RT-Thread skill PR 的范围，并且包含一些有风险的指导：

• 使用 git add -A
• 引导用户处理 GitHub token
• 建议通过浏览器 page.evaluate 调用 GitHub API
• 修改全局 Git proxy 设置

它不应作为本 RT-Thread skills PR 的一部分合入。

6. setup-rtthread-env.ps1 包含损坏的 PowerShell 文本

脚本在 profile helper 附近包含损坏的控制字符文本，例如变量片段被渲染成类似 �4EnvRoot 的内容。如果写入 PowerShell profile，生成的 helper 很可能不可用。

脚本还默认使用特定的 C:\env-windows 布局，并支持安装 scons、修改 PowerShell profile。除非有非常清晰的用户确认和边界说明，否则这类行为对通用 skill 来说过于激进。

RT-Thread 风格判断

一个更符合 RT-Thread 风格的通用 skill 应该：

• 以官方 RT-Thread BSP 布局和 BSP README 作为主要依据
• 把 SCons 和 Kconfig 作为主要构建与配置流程
• 支持 menuconfig、.config、rtconfig.h、pkgs --update 以及常见 SCons 导出目标
• 避免发明另一套默认项目结构
• 避免把 CMake、VS Code、clangd、host tests 或编号分层设为强制项
• 避免把产品专属案例作为默认指导

这个 PR 在 rtthread-bsp-builder 中部分符合上述方向，但在 rtthread-project-generator 以及 rtconfig-kconfig-sync 的部分内容中偏离较大。

分 Skill 建议

rtthread-bsp-builder

建议保留这个 skill，但需要收敛和修正。

建议修改：

• 范围继续聚焦官方 RT-Thread/rt-thread BSP。
• 保留“不支持的芯片或板卡不能虚构”的规则。
• 更好地支持 Windows 用户；纯 Bash helper 脚本对很多 RT-Thread Env 用户不够。
• 不要假设 GCC 永远是优先目标。应根据 BSP README 和用户目标决定使用 GCC、MDK、IAR、RT-Studio 或其他导出目标。
• pkgs 检测应支持 Env 下的显式路径，例如 pkgs.exe，不能只依赖 command -v pkgs。
• 模糊 BSP 搜索只能作为候选发现，不能作为“官方支持”的证明。
• 增加基础验证：Python 语法检查、脚本 help 输出，以及至少一个公开 BSP 的 dry-run 或 preflight。

rtconfig-kconfig-sync

建议保留这个主题，但缩小范围。

建议修改：

• 聚焦 .config、rtconfig.h、Kconfig、SConscript 和 package 选择。
• 删除或下沉 CMake / LVGL / FNA1000 内容，只作为可选参考。
• 不要硬编码项目化路径，例如 05_platform/Kconfig。
• 谨慎处理 .config 和 rtconfig.h 的直接 diff 指导；两者的宏映射不是简单一一对应。
• 对目标 RT-Thread 版本中是否存在某些 SCons 命令，需要先说明前提，不能默认所有 BSP 都支持。

rtthread-project-generator

建议从当前 PR 中移除，或者重命名后作为实验性的项目化模板单独提交。

建议修改：

• 如果该模板要保留，建议重命名为类似 rtthread-cmake-app-template。
• 不要把编号分层呈现为 RT-Thread 默认风格。
• review 前先修复所有层名不一致问题。
• 从默认指导中移除 FNA1000 专属参考。
• 将 CMake / VS Code / clangd 定位为可选的项目化应用支持，而不是 RT-Thread BSP 的必选工作流。
• 使用公开 RT-Thread BSP 做验证，不要只依赖私有或产品专属示例。

github-fork-and-pr

建议从本 PR 中删除。

如果后续作为独立的通用 GitHub workflow skill 提交：

• 避免使用 git add -A
• 避免在浏览器脚本中处理 token
• 默认不要修改全局 Git proxy 设置
• 优先使用 GitHub CLI、GitHub App 或正常 fork-and-PR 工作流
• 任何全局配置或凭据相关操作前都必须明确征得用户确认

README.md

建议在 PR 拆分后再更新 README。

建议修改：

• 只列出本 PR 实际包含的 skill。
• 为每个 skill 增加简短的适用范围说明。
• 增加贡献规则：一个 PR 应只新增或修改一个 skill 主题。
• 增加风格规则：通用 RT-Thread skill 不应把产品专属模板或编号项目布局作为默认行为。
• 增加验证规则：frontmatter 校验、Python 语法检查、helper 脚本 help 输出，以及适用场景下的模板 smoke test。

建议合入策略

1. 第一阶段：只合入精简后的 rtthread-bsp-builder。
2. 第二阶段：合入简化后的 rtconfig-kconfig-sync。
3. 单独实验性 PR：在修复内部不一致后，再提交项目化 CMake / 编号分层模板。
4. 不要在这个 RT-Thread skill PR 中包含 github-fork-and-pr。

[BernardXiong]

请做简化，谢谢

[silencebadwolf]

请做简化，谢谢

同意。