Openprd Benchmark Router

<!-- OPENPRD:GENERATED
adapter=codex
source=openprd-benchmark-router
version=0.1.19
checksum=1cbd70dcfc3a1acc
-->

OpenPrd Benchmark Router

当用户要求最佳实践、benchmark、对标、参考设计、产品优化、CLI 优化、Agent harness 优化、AI code review / PR review harness、上下文工程、提示词工程或图标资源时，先使用这份 skill。

核心原则

• 不把对标当成固定关键词匹配。结合用户目标判断参考源是否真的能提升设计、实现、排查、评审、规划或文档质量。
• 不强行对标。环境、权限、账号、普通脚本报错、一次性短问答或与产品/领域设计无关的问题，继续当前任务即可。
• 不默认下载全文、仓库或整站。先保留轻量链接、来源 ID 和适用边界；真正需要事实时再读取。
• 通常只选 1-3 个最相关来源；不要为了显得全面而扩大上下文。
• 不把索引、来源目录或记忆当事实来源；未经核验的外部内容不能作为已确认事实输出。

触发信号

• 用户提到 OpenPrd、OpenSpec、Superpowers、Anthropic Skills、Lark CLI、Agent harness、AI code review、PR review、review lane、long-running agents、context engineering、prompt engineering、最佳实践、对标、参考、复刻或优化设计。
• 用户提到图标、icon、图标站、图标库、图标资源、UI 图标、AI 图标、技术图标、3D 图标、功能图标、iconfont 或视觉资产参考。
• 用户提到界面审美、设计框架、主题库、模板库、组件骨架、视觉资产库、前端体验风格或页面参考方法。
• 用户要求解释某个 Codex / Claude / Cursor agent 为什么没有发现 skill，或希望提升 skill 自动识别、路由、生成、安装和持续执行能力。
• 用户没有显式说 skill 名也要触发；不要要求用户记住 $openprd-benchmark-router。

路由流程

1. 先识别优化对象：OpenPrd 产品/PRD 流程、CLI、skill 体系、长程任务、通用 harness、AI code review / PR review harness、context engineering、prompt engineering、图标资源或图标实现库。
2. 读取当前工作区证据：.openprd/、.openprd/benchmarks/index.md、.openprd/benchmarks/sources.yaml、AGENTS.md、repo-local skills、生成的 .codex/.claude/.cursor 引导和相关源码。
3. 选择最小足够的外部证据源：公开 GitHub 仓库走 DeepWiki；第三方工具、SDK、CLI 或官方 API 用 Context7；产品官方文档、工程博客和一手资料用官方来源。
4. 形成 OpenPrd 设计判断时，明确区分已证实事实、从来源归纳出的设计原则，以及对本项目的推断。
5. 用分析维度提炼可迁移原则，避免照搬表面功能。
6. 如果任务变成大量参考项目行为挖掘、长时间覆盖或需求补全，再路由到 $openprd-discovery-loop 承接持续调研。

Project Registry

• 项目自己的 .openprd/benchmarks/ 优先于 OpenPrd 内置 Source Map。
• sources.yaml 里的 approved source 是长期可复用参考；inbox/ 里的 candidate 只表示待确认线索。
• 用 openprd benchmark add <url|repo|file> 写入 candidate，用 openprd benchmark approve <id> 纳入 approved registry。
• 执行或复盘中发现被用户采纳的优质信源时，用 openprd benchmark observe <url|repo|file> --notes <text> 累计 evidence；达到阈值后只推荐 approve，不自动晋级。
• 用 openprd benchmark verify 检查重复来源、失效链接、缺失本地文件和过宽触发规则。

Source Policy

• GitHub 仓库：需要理解架构、核心模块、关键流程或对标结论时，先用 DeepWiki。默认顺序是 read_wiki_structure 1 次，再 ask_question 1-2 次；只有在本地源码和已有结论仍不足时才追加。DeepWiki 不可用或覆盖不足时，再回退到 GitHub README、源码和官方文档。
• 官方技术文档：涉及第三方库、框架、API、SDK、MCP、CLI 工具的用法、配置、限制、版本差异或迁移路径时，先检查本地代码、锁文件、README、类型定义；本地不足时再用 Context7，默认顺序是 resolve_library_id 1 次，再 query_docs 1-2 次。Context7 不足时说明缺口，再补官方文档、源码或其他一手资料。
• 工程文章和产品文档：优先读取当前线上一手页面，只抽取和当前任务相关的观点与设计原则，不复制长文；如果内容可能过时，要说明时效风险。
• 视觉与设计参考：优先吸收结构、节奏、信息组织、资产策略和质量门，不照搬品牌表层风格。需要官方品牌或产品事实时，优先官方站点、官方媒体包、官方设计系统和项目自身 approved benchmark。
• 本地源码优先：当前工作区已经有相关源码时，常规修 bug、查实现、改功能优先读本地代码；DeepWiki 主要用于外部仓库架构理解和对标分析。
• 停止调研：找到足以支持当前决策的 1-3 个高相关来源后停止扩展；候选来源重复时保留更权威、更新或更贴近当前任务的来源。
• 追加调用前先写清“已确认什么、还缺什么”；不要为了同一问题只换个说法反复查询。

Source Map

• Fission-AI/OpenSpec：适合对标 spec 驱动变更流程、change lifecycle、spec 与 execution artifact 分层、动态 agent 指令组装和验证门禁。
• obra/superpowers：适合对标 mandatory skill routing、多平台适配、轻量 bootstrap、worktree/subagent 协作和 skill 深浅分层。
• slavingia/skills：适合对标 0 到 1 验证、community-first、10 specific people、current workaround、manual-first delivery、Magic Piece of Paper、spreadsheet / no-code first、automate-one-step-at-a-time、forms and lists / CRUD first、build for today's customers not hypothetical future ones、avoid irreversible decisions、one-thing MVP、weekend test、3-of-10 payment proof、10+ paying before productize、first-customer circles、100 paying before launch、charge-from-day-one、customer-1 profitability、spend time before money、minimalist review 和 default alive 思路，并把这些原则回写到 requirement-intake、brainstorm 和 PRD 结构。
• CLI 与 skill 体系对标：larksuite/cli、anthropics/skills、Claude Skills 官方文档、Claude Code Skills 官方文档。
• 长程 Agent 任务：Anthropic long-running agents harness 工程文章。
• 通用 harness：OpenAI harness engineering、LangChain agent harness anatomy。
• AI code review / PR review harness：Nolan Lawson 的 “Using AI to write better code more slowly”、Milvus 关于多模型代码审查辩论/交叉验证的实验文章。
• Context engineering：Manus context engineering、Anthropic context engineering。
• Prompt engineering：OpenAI prompt engineering / prompt guidance、Claude prompt engineering、Gemini prompting strategies。
• 图标资源站一级最佳实践：UI 图标优先看 Phosphor Icons（https://phosphoricons.com/）；AI 公司与产品图标看 LobeHub Icons（https://lobehub.com/icons）；技术栈图标看 Tech Icons（https://techicons.dev/）；透明底 3D 图标看 Thiings（https://www.thiings.co/things）；功能图标、矢量插画、3D 插画和字体资源看 iconfont（https://www.iconfont.cn/）。
• 图标实现库二级最佳实践：Lucide、Tabler、React Icons。需要落到前端代码时，再结合当前项目框架、包管理器、bundle 体积和导入方式选择具体库。