wp-project-triage

wp-project-triage 技能概览

wp-project-triage 的作用

wp-project-triage 技能是一个快速、确定性的 WordPress 仓库首轮检查器。它会识别项目的大致类型，检测工具链和测试，提取版本线索，并输出结构化报告，让你不用猜就能选对后续工作流。如果你需要把 wp-project-triage 用在 Workflow Automation 里，这类技能的价值就在于：在真正修改任何内容之前，先帮助 agent 判断下一步该做什么。

适合谁使用

当你进入一个 WordPress 代码库，需要判断它是 plugin、theme、block theme、site、WP core 还是 Gutenberg 相关仓库时，就该用 wp-project-triage skill。它尤其适合希望在实现、评审或测试之前，先做一层可重复 triage 的 agent 和维护者。

它为什么不一样

wp-project-triage 的核心价值不在于写总结，而在于支持决策。它会读取仓库信号，套用约束条件，输出一份比通用 prompt 更值得信赖的 JSON 报告。这也让它比直接让 LLM 根据几个文件名去“自己判断这个仓库是什么”更合适。

如何使用 wp-project-triage 技能

安装并指向仓库根目录

对于 wp-project-triage install，先用标准 skills 命令把技能加到你的 agent workspace，然后一定要从仓库根目录运行，这样 detector 才能检查真实的项目结构。该技能需要基于文件系统的环境，并提供 bash 和 Node；有些工作流还会依赖 WP-CLI。

先读这几个文件

先看 skills/wp-project-triage/SKILL.md，再看 references/triage.schema.json，这样你能先理解报告的结构。仓库里还有 scripts/detect_wp_project.mjs，如果你想弄清分类和信号检测是怎么工作的，这个文件最关键。比起粗略扫一眼目录树，这三个文件能告诉你的更多。

把模糊目标变成有用的 prompt

一个高质量的 wp-project-triage usage prompt，应该说明你想做什么判断，而不只是说你想扫一遍仓库。比如：“在这个仓库上运行 wp-project-triage，告诉我它更像 plugin 还是 block theme，当前有哪些工具链，以及在改代码前我应该遵守哪些 guardrails。”这样能给技能足够明确的意图，产出可执行的 triage 报告。

用报告决定下一步工作流

检测器跑完后，利用输出决定接下来该看 build 配置、测试设置、版本约束，还是内容结构。如果报告显示 unknown，把它当成一个信号：要么你不在正确的根目录，要么这个仓库需要更好的检测规则，而不是硬猜。等你做了结构性修改，比如新增 theme.json、block.json 或 build tooling 之后，再跑一次 detector。

wp-project-triage 技能常见问题

wp-project-triage 只适用于 WordPress 仓库吗？

是的，它的定位就是这个。wp-project-triage guide 主要面向 WordPress 项目形态，例如 plugins、themes、block themes、site 仓库、core 和 Gutenberg。如果你不在这个生态里，通常用通用文件系统扫描器或别的仓库分类器会更合适。

使用它需要 WP-CLI 吗？

不一定。即使是在只有文件系统的环境里，这个技能仍然有用，但某些下游工作流可能会预期有 WP-CLI 或 WordPress 周边工具链。wp-project-triage 的意义就在于先告诉你现有条件是什么，这样你才能判断后续步骤是否现实。

它比直接让 AI 检查仓库更好吗？

在首轮 triage 场景下，通常是的。普通 prompt 可能漏掉版本线索、忽略信号，或者在目录结构模糊时凭空推断。wp-project-triage 给你的是可重复的安装和运行路径、明确的输出契约，以及更窄的任务范围：先分类，再行动。

什么时候不该用它？

不要把它当成 code review、安全审计或深层架构分析的替代品。它是 triage 层，不是完整诊断。如果你已经明确知道项目类型，而且需要的是一个针对性的代码任务，那这一步可能并不需要。

如何改进 wp-project-triage 技能

给它更干净的起始条件

提升 wp-project-triage 结果最有效的方法，是从真正的仓库根目录运行，并避免 partial checkout 或嵌套的工作目录。如果 detector 扫到了错误的文件夹，报告的可用性会立刻下降。这一点比复杂的 prompt 更重要。

提供会改变判断的上下文

如果你想让 wp-project-triage usage 更准确，就直接说明你需要判断的结果：比如 plugin 还是 theme 的分类、build 工具检测，或者测试就绪度。这样你更容易判断报告是否足够支撑下一步。比起“总结所有内容”，一个更好的后续 prompt 可能会要求“最小安全修改路径”。

注意常见失败模式

最常见的失败模式，是因为信号不足、仓库布局异常，或者忽略了某些目录，导致分类变成 unknown 或过于笼统。另一种情况是：仓库里虽然有生成文件，但源代码线索很弱，却过度相信了第一份报告。如果发生这种情况，应该改进 detector 输入或扩展 ignore 规则，而不是凭感觉补答案。

运行一次后继续迭代

先用第一份报告找出缺口，然后在补上缺失线索之后再跑一次 wp-project-triage，比如添加 theme.json、block.json、测试配置或版本元数据。这个技能最适合作为迭代式 guardrail：检测、验证、调整，再检测一次。