面向规划、GitHub 工作流、代码评审、测试、文档和交付运营的高优先级开发技能。
当软件交付在规划、评审、测试、文档或运营跟进上存在明显缺口时，使用这个合集。
围绕需求规划、代码评审、测试验证、文档清晰度和交付运营的开发型技能集。
适合工程团队、技术负责人和独立开发者，用更短的闭环推进从需求到上线的交付。
先跑通主路径，再按需加入替代项，避免一次性引入太多能力。
团队希望把功能需求更快转成可跟踪、可执行的开发任务。
按能力模块分组，数字标注推荐安装顺序。先跑通主选技能，再按需添加替代项。
把模糊需求整理成可讨论、可拆分、可交付的需求文档与实施计划。
更快发现缺陷、缩小排查范围，并让 review 意见更可执行。
作为代码质量模块主选，它能把高成本的安全问题提前暴露出来，而不是等到上线后补救。
当问题复杂或反复回归时，它能强制团队先定位根因，而不是靠猜测式修复推进。
当团队不想让一个大流程完全接管开发，但又希望 Claude Code、Codex 等 agent 在真实工程项目里更少跑偏时，这个 pack 比单个提示词更有复用价值。它适合先用 `setup-matt-pocock-skills` 记录 issue tracker、triage 标签和 domain docs，再按任务选择 `/tdd`、`/diagnose`、`/to-issues` 或 `/improve-codebase-architecture`。
当团队开始安装或自建 Agent Skills 时，真正的缺口通常不是缺少提示词，而是缺少采用前审查。这个 pack 里的 `skill-scanner` 会检查 prompt injection、恶意脚本、过宽权限、secret 暴露和供应链风险；`agents-md`、`claude-settings-audit`、`skill-writer` 则把工程约定、权限配置和 skill 维护变成更可复查的流程。
在上线前补强自动化测试和真实浏览器回归验证。
它提供的是可复用的 E2E 测试套路，而不是一次性生成几段测试代码。
当问题卡在交互式 UI 复现、页面检查或手工 QA 流程，而不是测试架构设计时，它是 E2E testing 的实用补充。起步应走官方 `npx skills add vercel-labs/agent-browser` 安装路径，并先用 `agent-browser --help` 熟悉命令范围。
当你需要 Claude Code 先侦察页面结构、再执行具体 UI 检查，并把证据转成可复查的测试发现时，它比一次性的手动点击更稳。适合在把流程沉淀为正式 E2E 测试前使用。
当团队已经信任 Playwright，又希望把浏览器操作接入 agent 标准工具层时，它比临时脚本更容易复用，也比纯视觉浏览更适合可审查的页面交互。
当团队想验证浏览器 agent 能否被限制在批准域名内，或者要演示 prompt injection、外链跳转和抓取任务的边界控制时，它比直接给 agent 原始浏览器权限更适合做第一步。
让 API、架构和代码说明随着实现同步更新，而不是事后补救。
当你更关心接口边界、可扩展性和一致性时，这个主选比通用文档 skill 更合适。
当开发任务不是单纯写 API 文档，而是要让工具真正进入 Claude Code、OpenClaw 或其他 agent 工作流时，它比通用 API 设计建议更贴近落地。
当实现依赖 Next.js、Supabase、Prisma、Tailwind 等变化较快的框架或库时，它能把查文档变成 agent 工作流的一步；可走 CLI + Skills，也可接 MCP server。
当 agent 需要查 schema、执行受控查询，或把数据库操作沉淀成可复用 skill 时，它比直接粘贴连接串、临时写 SQL 脚本或让 agent 自由访问数据库更容易审查。
当团队已经有稳定的操作流程，但还停留在散落提示词、口头规范或个人习惯里时，它能把流程转成更明确的 skill、示例和测试提示。
当文字说明不够直观时，它能用图表补足 API 和系统设计的沟通成本。
覆盖发布、基础设施和交付阻塞点，在问题不再只是代码时补位。
当团队已经在用或准备采用 Claude Code，但还不清楚该先配置哪一类自动化能力时，它比泛泛收集插件更能落到具体代码库。
当团队不是只想写一个 demo agent，而是要把 agent 放进 Cloudflare Workers、Durable Objects、MCP transport、队列、重试、审批和 observability 这些真实运行边界里时，这个官方 skill 比零散查文档更稳。它适合先用 `npx skills add https://github.com/cloudflare/skills --skill agents-sdk` 安装，再按任务检索 Cloudflare docs，而不是依赖模型记忆。
当团队要把 coding agent 接入 Microsoft 云和 agent 平台时，它比临时查 SDK 文档更适合做交付入口：仓库把 SDK 语言技能、Foundry orchestrator、Azure 部署流程、MCP 配置和测试场景放在同一套可审查结构里，适合先用 `npx skills add microsoft/skills` 拉取，再只启用当前项目需要的语言或服务技能。
当团队已经在用 Codex，并希望把常见工作沉淀成可复查的重复流程时，它比临时复制社区 SKILL.md 更适合做入口。仓库目前覆盖 GitHub PR 评论处理、CI 修复、部署、Playwright、截图、OpenAI docs、安全最佳实践、Notion、Figma 和语音/转写等工作流；起步可以先用官方示例 `$skill-installer gh-address-comments` 验证安装链路，再只启用当前项目真正需要的 curated skill。
当 agent 需要用 ES|QL 排查日志、分析 LLM/agentic app observability、管理 Kibana alert/SLO/dashboard、处理 Elastic Security case，或配置 Elastic Cloud 项目时，这个库比通用运维提示词更具体。它的价值在于把 Elastic API、数据流、权限和排查步骤写进可审查的 SKILL.md，而不是让模型凭记忆猜字段和操作顺序。
当团队已经采用 Browserbase，并希望把浏览器 agent 的基础设施操作留在官方 CLI 路径里时，它比临时写脚本或只靠页面级点击更稳。
围绕 issue、PR 和执行状态，保持产品、工程与交付节奏的一致。
它覆盖 issue、PR 到 CI 的整条 GitHub 交付链，比只管单一步骤的 skill 更完整。
每个合集都应该能回答：适合谁、解决什么问题、先安装什么。这个区域让用户在安装前快速确认判断依据。
团队希望把功能需求更快转成可跟踪、可执行的开发任务。
维护者需要在合并前加强代码评审、回归验证和问题定位。
产品与工程团队需要让文档、发布和交付跟上研发节奏，而不是总在事后补救。