用途
best-practices-researcher 是一个 meta-skill（元技能），用于动态研究并落地（ground）任意技术栈的最佳实践。它的设计目标是：与其安装几十个技术专用技能，不如用这一个技能做实时研究，返回有权威依据、且能感知版本的建议。
资料明确：该技能需要联网搜索访问权限。如果不可用，必须显式说明这一限制，并仅回退到官方文档作为唯一事实来源——绝不用训练数据猜测来填补空白。
主要能力
第 0 步：检测模式
在其它一切之前，先判断适用哪种模式：
- 模式 1 —— 决策模式：用户正在技术之间做选择，尚未定案。信号包括对比性问题、“我应该用 X 还是 Y”“Z 有什么好用的库”“帮我选个数据库”。
- 模式 2 —— 落地模式：用户已经选定某项具体技术，或项目中已存在该技术。信号包括“Vue 的最佳实践”“X 应该怎么组织”，或提到具体技术但没有比较。
- 模式 3 —— 审计模式：用户已有代码，想对照最佳实践做审查。信号包括“这样对吗”“审查我的代码”“我做得对不对”，或贴出代码并提问。
- 混合模式：现有技术栈已定，用户要新增东西 → 先对现有技术栈运行模式 2 获取上下文，再对新增加的部分运行模式 1。两者都完成后，先处理交叉关注点（Cross-Cutting Concerns），再生成任何输出。
不激活该技能的情形
资料列出以下不应激活的情况：
- 用户在调试具体错误（他们需要修复，而不是说教）
- 用户在问纯语法/API 问题（如“useEffect 怎么用”）
- 用户已做出决定，正在寻求实现帮助
- 问题是关于一次性脚本或废弃代码
使用方式
第 1 步：校准深度
研究前先确定要深入到哪里：
- 快速问题（单一模式/API 选择，如“该用 ref 还是 reactive”）：2–3 次定向搜索，简洁回答，跳过范围协商。
- 架构决策（重大库选择、项目结构）：执行完整研究流程。
- 全栈审计（“审查我整套配置”“我的 Next.js 应用最佳实践”）：先做范围协商——在搜索任何内容前，让用户先排优先级。
- 范围协商（当话题可能横跨 3 个以上类别时使用）：例如“我可以覆盖[检测到的领域：状态管理、路由、数据获取、鉴权、测试、样式、部署……]。你想让我深入讲几个，还是对全部做一次高层概览？”
模式 1：决策模式
目标：帮助用户基于当前社区现实，做出有依据的技术选择。
- 理解约束：搜索前从对话中提取或询问——现有技术栈/语言是什么（扫描 package.json、go.mod、requirements.txt、Cargo.toml、pyproject.toml 等）；用例/规模/团队规模；硬性约束（自托管、仅开源、预算、特定语言）。
- 搜索当前格局：运行定向网络搜索，优先级依次为——采用度与势头信号（开发者调查、A vs B 当年讨论、reddit/HN 真实从业者意见）、维护健康度（GitHub 最近提交、未决 issue、发布节奏、维护者响应）、生态适配（选项与现有技术栈的搭配）。
- 加权与排序：社区势头（高权重）、维护健康度（高权重）、生态适配（高权重）、教程/博客流行度（低权重，落后现实 1–2 年）、来源年龄（超过 18 个月的来源降低权重，除非是官方文档）。
- 输出格式：最多呈现 3–4 个选项。若更多，简要列为“也考虑过”并各一行。输出包含决策矩阵表格（选项、势头、维护、生态适配、最适合），以及每个选项的突出原因、权衡/注意点、适用条件，还有“我的解读”（仅用条件式表述，绝不写“直接用 X”）和来源列表。资料提到会询问是否保存为 ADR（架构决策记录）。
模式 2：落地模式
目标：产出具体、能感知版本、可执行的最佳实践，供 agent 实际遵循。
- 检测确切版本与现有约定：版本（必做，不可跳过）——按顺序检查 package.json、lock 文件、go.mod、Cargo.toml、pyproject.toml 等；monorepo 需逐包检查。若无项目文件，则询问版本。现有约定——目录结构、已用状态管理、样式方案、测试设置、lint/format 配置。不得推荐与项目既有约定冲突的做法，除非显式标注冲突与迁移成本。例外：若既有约定本身就是反模式（如 God 组件、客户端包中泄露密钥、无错误处理），须作为发现项显式标出。
- 搜索版本特定实践：先官方来源（官方域名、迁移指南/changelog、RFC/roadmap），再从业者实际做法（GitHub、反模式、团队博客），再社区信号（reddit、HN）；降低教程博客、Medium、YouTube 标题的优先级。
- 解决冲突：优先级——该确切版本的官方文档 > 核心团队/维护者声明 > 近期社区共识（< 18 个月，多来源一致）> 较旧的社区指导（> 18 个月）。版本相关的内容须显式标注。
- 低信号回退：若搜索只返回过时垃圾、SEO 垃圾或没有有用内容，明确说明“我在这点上没能找到有力的近期信号”，回退到该版本官方文档；若官方文档也无，如实说明，绝不用训练数据猜测填补。建议直接查看 GitHub Discussions 或社区 Discord。不要在单点上无限循环——3–4 次搜索后即综合现有信息并注明模糊性。
- 类别清单（agent 指令，不直接输出）：项目结构、错误处理、测试策略、安全、性能、无障碍、CI/CD 与部署、日志与可观测性。只包含与用户问题和协商范围相关的类别。
- 输出格式：包含简短代码片段（开发者会略读文本但会读代码），结构包括确认的版本、检测到的既有约定、研究时间戳、来源，以及每个类别的 ✅ DO / ❌ AVOID 与版本特定说明。
交叉关注点（混合模式）
在混合模式完成模式 2 + 模式 1 研究后，或当用户询问多技术集成时，显式研究集成模式：搜索 [技术 A] 与 [技术 B] [当年]、项目结构、已知问题/不兼容。资料提醒：集成摩擦点往往藏有最难的决定。
模式 3：审计模式
目标：把现有代码与研究所的最佳实践对比，标出差距。模式 2 的研究在内部进行——不先输出完整落地文档。流程：静默运行模式 2 第 1–4 步，把研究出的实践作为内部评分标准，仅输出审计结果，每条发现内联引用相关规则，之后询问是否需要输出所用完整最佳实践参考。严重级别按严重性排序：🔴 严重（安全漏洞、数据丢失风险、正确性 bug）、🟡 警告（性能问题、废弃 API、可维护性问题）、🔵 建议（风格改进、更新模式、小幅优化）。
保存输出（可选）
绝不自动保存，等待明确指令。模式 2 输出保存到项目根目录 GROUNDED_PRACTICES.md；模式 1 输出可提供保存为 docs/decisions/ADR-[topic].md 的 ADR。陈旧性检查：若已有产物超过 90 天或有重大版本升级，建议刷新；若较新则提示是否刷新或直接基于它工作。
适用场景
- 在多个库/框架之间做技术选型
- 针对已确定（含具体版本）的技术获取可执行的最佳实践
- 对现有代码做对照最佳实践的审查
- 多技术集成模式研究
限制
- 需要联网搜索访问；不可用时须说明并仅回退官方文档，不用训练数据猜测
- 不用于调试具体错误、纯语法/API 提问、已定方案的实现求助、一次性脚本
- 未确定版本时需向用户询问
- 单点研究若 3–4 次搜索无果，须说明模糊性而非继续循环
- 不在决策模式中选“唯一赢家”，仅用条件式表述
- 未经协商不覆盖超过约 3 个类别
- 不推荐与现有项目约定冲突的模式（除非标注迁移成本）
- 不幻觉即将发布版本的功能
- 不安装或建议安装额外技能——该技能自我包含
暂未提供
资料未说明收费、价格、具体平台支持范围等信息。