Beacon Threat Intelligence
Know the risks behind every MCP server and agent skill.
Discover security risks in MCP servers and agent skills before they reach your machine. Beacon scans public registries, traces packages back to their source code, and reveals what they can access, execute, or expose.
Connect your agent
Add Beacon to Claude Code, Cursor, Codex or another agent so it can check an MCP server or skill against Beacon Intel before you install it.
Free with a Beacon account. Create one, or sign in when your agent asks.
Any coding agent
Read https://intel.beacon.sh/start.md and set me up on Beacon Threat Intel
Paste this into any coding agent. It reads the guide and sets up MCP, the CLI, the API, feeds or a CI gate.
| Name | Risk |
|---|---|
| qa-boundary-deep-dive 从输入、状态、时间、资源四个维度系统化识别边界条件。真正的 Bug 往往在"看起来不是边界"的地方——比如用户名字段没测超长 Unicode、订单支付刚好在超时前1秒完成、1000人同时下单。当需要补充边界测试、等价类划分完成后需要补边界值、或者直觉告诉你某些边界可能有问题时，应当使用此技能。每个边界条件都需要标注风险等级并给出明确的预期结果。适用于任何有输入字段、状态变化、时间约束或资源限制的系统。 触发场景：边界分析、边界条件、还有什么边界、边界值、边界扫描、等价类划分完 | |
| qa-bug-lifecycle 当团队缺陷管理混乱、Bug 没有统一的分级标准、或者领导要看缺陷趋势数据时使用此技能。覆盖缺陷从提交到关闭的完整生命周期，包括严重度/优先级分级规范、各状态流转条件和时效要求、缺陷度量和趋势分析。如果缺陷管理不规范，复盘数据就是垃圾——"严重Bug数量下降"可能是因为大家不再标记严重了。 触发场景：缺陷管理、Bug管理、缺陷流程、Bug状态、严重度、缺陷趋势、团队需要规范缺陷管理流程时。 Use when the user asks about: bug and defect | |
| qa-bug-reporting 当发现了一个 Bug 需要提交、自己提的 Bug 被开发打回来了、或者团队 Bug 质量参差不齐需要统一规范时使用此技能。一个高质量的 Bug 报告应该让开发看一遍就能复现并定位，不需要来回追问。包含清晰的复现步骤（从环境准备到操作序列到预期/实际结果）、根因推测、影响范围评估和必要附件。 ⚠️ 本技能示例可能调用外部抓包/日志工具，请在受控环境执行。 触发场景：提Bug、写Bug报告、Bug描述、报告格式、复现步骤、加附件、开发打回Bug报告需要改进时。 Use when | |
| qa-bug-root-cause-analysis 当某个 Bug 频繁复现、线上有缺陷需要做事后分析、或者发现同一类问题反复出现需要根治时使用此技能。从症状出发用 5Why、因果图和鱼骨图等方法系统化定位缺陷根源，区分直接原因、间接原因和系统原因。不要只修症状——根因分析的价值在于找到让同类 Bug 不再发生的系统性改进措施，同时分析漏测原因来优化测试设计。 ⚠️ 本技能示例可能调用外部日志/监控工具，请在受控环境执行。 触发场景：Bug根因、根因分析、为什么出Bug、深层原因、定位问题、排查方向、反复出现同类问题需要根因改 | |
| qa-ci-cd-testing 当需要把测试集成到 CI/CD 流水线中、或者现有流水线的测试环节跑起来效率低不可靠时使用此技能。覆盖流水线各阶段的分层测试卡点设计（提交检查→单元测试→接口测试→UI 测试→回归测试）、工具集成策略和质量门禁配置。不要在 CI 里堆满慢的 UI 测试——而是构建测试金字塔：提交阶段跑最快的（<5min），合码阶段跑核心的（<15min），夜间跑全量的。 触发场景：CI/CD、持续测试、流水线测试、质量门禁、自动化回归、提交即测试、构建流水线需要加入测试环节时。 Use wh | |
| qa-code-review-for-test 当开发提了 PR、代码变更需要确定测试范围、或者想通过分析代码来预测可能出 Bug 的区域时使用此技能。从测试视角分析代码变更的影响范围、识别高危模式和典型风险区域。不要看完整代码逻辑——你只需要关注变更类型（新增/修改/删除/重构）、影响范围（接口定义/数据库字段/业务逻辑）和相关依赖，据此确定最小回归测试范围。输出代码变更影响分析报告。 触发场景：代码评审、CR、测试视角、看代码、代码变更、Diff、代码变更后需要确定测试范围时。 Use when the user as | |
| qa-combination-strategy 当参数多、环境多、"全组合测不完"时运用正交试验法、Pairwise和判定表来解决组合爆炸问题。如果系统有多个输入字段的组合依赖关系（如"A=1且B=2时C不能为3"）、或者需要适配多浏览器多操作系统多语言，一定要用此技能来设计高效的组合覆盖方案。不要试图全覆盖——组合测试的核心是用最少的用例达到最高的组合覆盖率。输出组合覆盖矩阵并标注覆盖遗漏。 触发场景：组合测试、参数组合、正交测试、组合爆炸、Pairwise、全组合测不完、判断表、参数多环境多时。 Use when th | |
| qa-critical-thinking 当需要挑战已有假设、挖掘隐含约束、发现"所有人都没想过"的测试场景时使用此技能。测试中最常犯的错误是接受了需求文档里的隐含假设——比如"用户一定会有网络"、"输入一定有内容"、"操作顺序一定正确"。用「如果不呢」的深度质疑方式反向思考，暴露那些被默认为"正常"的异常场景。每一个测试场景都应该走一遍"如果这个假设不成立呢"的质疑流程。 触发场景：还有什么、如果...会怎样、逆向思考、你怎么看、这样够吗、质疑、挑战需求、有没有漏、需要怀疑和深度分析时。 Use when the | |
| qa-domain-modeling 通过构建状态机、数据流图和服务依赖图来理清复杂的业务逻辑和系统边界。当需求文档复杂、涉及多个子系统交互、或者你搞不清楚数据在不同模块之间怎么流转的时候，应当使用此技能。领域建模不是为了画图而画图——它帮你发现那些"需求文档里没写的"隐式业务规则和系统边界。适用于复杂业务流程的测试范围可视化。 触发场景：画状态图、数据流、服务依赖、建模、领域建模、状态转换、数据流向、服务调用关系、需求文档复杂难以理解时。 Use when the user asks about: state | |
| qa-execution-observation 当测试新人不知道执行时应该关注什么、或者有经验的测试发现"执行完了但好像什么都没发现"时使用此技能。测试执行不是"按步骤操作看结果"——你需要同时关注功能表现、接口响应、日志报错、UI 渲染、数据一致性、性能指标六路信号。大多数的 Bug 是被"不小心看到"的而非被测出来的。每轮执行后输出观察记录，在 9 列设计用例上回填「实际结果」与「结论」完成执行闭环，标注异常信号与待跟进问题。⚠️ 本技能示例可能调用外部监控/截图工具，请在受控环境执行。 触发场景：执行观察、观察日志、 | |
| qa-expert-review 当 AI 生成的测试用例已经过输出评审和盲区补盲、准备终审上线时使用此技能。由资深测试对 AI 输出的用例做人工抽样校验，从业务有效性、场景完整性、可执行性三个维度做最后把关。⚠️ 如果发现系统性问题（比如遗漏了某个关键模块），需要回退修正并记录到 Prompt 优化反馈库。专家评审不是走形式——发现的问题必须闭环。 触发场景：专家评审、用例审查、校正反馈、评审用例、检查用例、终审、用例上线前需要终审时。 Use when the user asks about: final | |
| qa-exploratory-testing 当脚本化测试覆盖得差不多了、但直觉告诉你"可能还有东西没测到"时使用此技能。用系统化的探索方法（场景漫游、角色扮演、失败路径、标杆对比）来发现预设测试用例覆盖不到的问题。探索式测试不是随便点——它是有明确 charter（任务书）和时长的有目的探索。每次探索需要记录 session 笔记和发现的问题列表。 触发场景：探索测试、自由测试、漫游测试、场景发现、到处点一点、随机测试、角色扮演、SBTM、新产品快速验证时。 Use when the user asks about: | |
| qa-heuristic-checklist 提供登录、支付、搜索、购物车、导入导出、审批、消息通知、权限管理等不同类型功能的测试要点模板。当面对一个新功能类型不知道从哪里开始测试、或者担心遗漏了某个功能类型的特有测试点时，应当使用此技能。特别适合测试新人——照着清单逐项检查就不会漏掉该功能类型的典型问题。例如支付类要测金额精度和幂等性，导入导出类要测格式兼容和性能，每个功能类型都有其特有的高风险区域。 触发场景：这个功能怎么测、有什么测试要点、checklist、测试模板、表单测试、支付测试要点、导入怎么测、测试新人需 | |
| qa-input-validation 在测试工作流开始前检查用户输入是否包含有效的需求描述和足够的上下文信息。当用户的测试请求过于模糊（只说"帮我测试"却没说测什么）、缺少必要的需求文档或上下文时，应当使用此技能来验证输入完整性。如果输入验证失败，必须返回缺失信息清单要求用户补充。适用于启动任何测试设计流程的第一步。 触发场景：需求不清楚、信息不够、这个需求能测吗、用户输入模糊时自动激活（第一步）。 Use when the user asks about: checking whether the user's | |
| qa-mobile-testing 当需要测试 iOS/Android 原生 App、H5 页面或小程序的移动端专项场景时使用此技能。移动端的坑主要不在功能逻辑上——中断（电话/通知/低电量）、弱网/断网/网络切换、前后台切换、系统权限管理、多机型适配和各种系统版本兼容才是重灾区。不要只测功能流程，移动端的 Bug 有一半以上是中断和兼容性相关的。输出按中断/网络/权限/兼容/性能分类的测试要点清单。 触发场景：移动测试、App测试、Android测试、iOS测试、手机上测、H5测试、小程序测试、移动端中断测试 | |
| qa-output-validation 在最终输出前对测试用例做最后一轮防幻觉验证：事实核查（引用的需求ID是否存在）、一致性检查（用例之间是否矛盾）、可执行性验证（步骤是否能实际操作）、来源追溯（每个用例是否能追溯到具体需求）。当测试用例已经生成完毕、准备输出了，但你不确定AI有没有编造不存在的功能或需求时，应当使用此技能。这是整个工作流的最终质量守门——如果验证失败，必须返回问题清单要求修正，不得跳过。 触发场景：验证一下输出、检查有没有幻觉、这个用例对吗、确认一下质量、时。 Use when the user | |
| qa-quality-metrics 当管理层问"质量到底怎么样"、需要量化质量数据来做决策、或者想建立质量看板来跟踪趋势时使用此技能。从过程质量（需求评审通过率/用例覆盖度）、结果质量（Bug 密度/线上事故数）、效率（测试周期/回归耗时）和健康度（自动化通过率/环境稳定性）四个维度设计度量指标。⚠️ 度量的目的不是打分，是发现问题趋势——如果只报喜不报忧，度量就没用了。 触发场景：质量度量、质量指标、怎么量化质量、质量看板、质量数据、趋势分析、向管理层展示质量数据时。 Use when the user as | |
| qa-question-framework 当需求文档信息不够、不知道接下来该问产品什么、或者需要从开发那边获取更多技术细节时使用此技能。很多人测不好不是因为不会设计用例，而是因为一开始就没问对问题。提供需求调研、边界确认、规则挖掘、技术细节追问等不同场景的结构化提问模板，确保在测试设计前获取到足够上下文。每一个问题都标注了问谁、怎么问、什么时候问。 触发场景：不知道该问什么、怎么获取信息、需求不清楚、需要澄清、问什么问题、提问模板、和产品对需求、和开发沟通细节、需求文档信息不足需要补充时。 Use when the | |
| qa-regression-testing 根据变更范围、风险等级和时间约束制定分级精准回归方案。当版本迭代了、代码改动了、你需要确定"到底哪些功能要重新测一遍"的时候使用此技能。回归的时间永远不够——此技能帮你做出取舍决策：冒烟回归（P0核心流程）、核心回归（高影响区域）、全量回归（有余力时）。基于变更分析和风险评估选择最省时的回归策略，而不是盲目全量回归。 触发场景：回归测试、回归策略、回归范围、回归用例、冒烟测试、全量回归、回归不够时间、哪些要回归、版本迭代需要确定回归范围时。 Use when the user | |
| qa-release-risk-governance 当版本要发布了、需要决定"能不能发"、或者需要设计灰度/回滚方案时使用此技能。系统化评估变更风险（变更范围/影响面/回退成本），设计灰度发布策略（按用户/区域/流量比例），制定回滚方案和线上监控计划。不要问"这个版本稳不稳"——要问"如果出问题了，我们能在几分钟内发现并回滚"。产出发布风险评估报告和灰度发布方案。 触发场景：发布风险、灰度策略、回滚方案、风险评估、版本发布、紧急发布、大版本发布前风险评估时。 Use when the user asks about: rele | |
| qa-req-deconstruction 将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。每条需求带唯一 ID（REQ-{模块缩写}-{序号}）。 触发场景：分析这个需求、需求解构、挖掘隐含需求、需求挖掘、需求分析、拆解需求、业务规则提取、需求模糊需 | |
| qa-requirement-review 从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求"评审这份需求"、"看看这个PRD写得怎么样"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说"需求评审"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when | |
| qa-retrospective 当一个迭代结束、一个项目完成、或者发生线上事故需要事后分析时使用此技能。通过系统性的回顾会议和数据复盘，把个人和团队的经验教训转化为可复用的组织资产。不要沦为"说说好话走个形式"——有效的复盘需要有数据支撑（缺陷趋势/漏测分析/效率数据）、有根因分析（为什么出问题）和有 action items（下次怎么做不一样）。输出复盘报告和改进项追踪表。 触发场景：测试复盘、迭代复盘、项目复盘、经验沉淀、漏测分析、回顾总结、事后分析、反复出现同类问题需要根因改进时。 Use when | |
| qa-risk-intuition 识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时，应当使用此技能。有经验的测试看到某些变更会本能地警觉——这不是玄学，是可以结构化的信号模型：变更/业务/技术/数据/集成五大风险信号雷达，量化打分后按等级分配测试深度与资源。每个风险点带唯一 ID（RISK-{模块}-{风险类型}-{序号}）。 触发场景：风险评估、优先级、哪里风险高、风险信号、测试 | |
| qa-scenario-tree 将需求解构的结果系统化转化为主路径、备选路径、异常路径、业务规则四类测试场景。当业务流程复杂、涉及多个页面跳转或状态变化、需要确保关键路径和异常路径都有覆盖时，应当使用此技能。不要只测"正常流程"——场景树的核心价值是暴露那些"用户可能不会按你预期操作"的分支和异常路径。每个场景带唯一 ID（SC-{模块缩写}-{序号}）并关联回需求 ID（REQ-）。 触发场景：构建场景、测试场景、场景树、场景设计、测试路径、场景覆盖、业务流程复杂需要系统化梳理时。 Use when th | |
| qa-shift-left 当项目还在需求阶段或者开发正在写代码时使用此技能——这时候介入能花最小的成本避免最多的缺陷。从需求可测试性评审（需求模糊/矛盾/不可测）、开发阶段测试设计（单元测试/接口契约/测试桩）和技术方案评审（影响面分析/风险识别）三个维度提前发现缺陷。越早发现 Bug 修复成本越低——需求阶段的 Bug 修复成本是线上阶段的 1/100。输出左移检查清单和阶段性介入记录。 触发场景：测试左移、左移、提前测试、需求可测试性（左移阶段）、需求评审（左移介入）、开发阶段测、项目早期需要介入 | |
| qa-shift-right 当功能已经上线了但还担心线上质量、或者需要设计灰度发布后的验证方案时使用此技能。通过生产监控（APM/日志/用户反馈）、线上巡检拨测、A/B 验证和混沌工程将测试延伸到生产环境。不要把上线当成终点——用户在生产环境的使用方式是永远测不全的。输出右移验证方案（灰度监控指标 + 拨测用例 + 告警阈值 + 回滚触发条件）。 触发场景：测试右移、生产验证、灰度监控、混沌工程、线上灰度验证、上线后验证、需要规划线上监控与回滚策略时。 Use when the user asks ab | |
| qa-specialized-testing 当功能测试做完之后需要做进一步的质量验证时使用此技能。覆盖性能测试（负载/压力/稳定性）、安全测试（OWASP Top 10 TOP 漏洞）、兼容性测试（多浏览器/多设备）的测试方法。不要在功能测试还没做完时就做专项——先保证功能正确，再评估性能和安全。专项测试的产出是一组可复用的测试方案（性能指标基线、安全渗透用例、兼容性矩阵）。 触发场景：性能测试、安全测试（专项）、兼容性测试、专项测试、压力测试、渗透测试、SQL注入测试、跨浏览器测试、功能测试完成后需要补充专项测试时。 | |
| qa-stakeholder-communication 当需要告诉开发"这个 Bug 必须修"、跟产品经理沟通需求变更的影响、或者向管理层汇报质量风险时使用此技能。不同角色关注的事情不同——开发要的是复现步骤和定位信息，产品要的是影响范围和优先级建议，管理层要的是风险判断和决策依据。此技能提供针对开发/产品/管理层的沟通模板和策略。产出根据不同角色定制的沟通话术和汇报材料模板。 触发场景：怎么沟通、跟开发说、跟PM说、跟领导说、沟通策略、向上汇报、干系人沟通、推动问题解决需要有效沟通时。 Use when the user ask | |
| qa-state-transition 系统化测试状态机的合法转换、非法转换、边界转换和并发转换场景。当业务对象经历了多种状态（如订单：待支付→已支付→已发货→已完成）、或者需要验证状态变化时的数据一致性时，应当使用此技能。最容易遗漏的是非法转换（业务不允许的操作如"已完成→待支付"）和并发转换（同一订单同时被支付和取消）。每个状态转换需标注触发条件、前置状态、后置状态和验证点。 触发场景：状态测试、状态转换、状态机、状态流转、状态变更、状态覆盖、业务对象有多状态流转时。 Use when the user ask | |
| qa-team-coaching 当团队里有测试新人需要带、想提升团队整体测试水平、或者需要把个人经验转化为团队能力时使用此技能。通过 Pair 测试、经验分享、checklist 沉淀、模板建设和培训材料等方式赋能团队。不要等着新人犯错再教——好的赋能是提前给工具和方法论，让新人在第一次做之前就知道"正确的做法是什么"。 触发场景：培训、赋能、新人、怎么教、带人、培养、团队成长、新成员加入需要快速上手时。 Use when the user asks about: coaching and enabling | |
| qa-team-skills QA 团队测试技能包：当用户提出测试相关需求——需求评审、测试用例设计、 AI/Agent 专项测试、缺陷根因分析、测试报告（日报/周报/阶段/季度）、 团队管理（进度/准出/漏测复盘）、探索性测试——时，按意图路由到对应 能力模块执行专业测试任务。典型触发如"评审这份 PRD""设计登录功能的 测试用例""对支付接口做全量回归并出缺陷报告"。 NOT for：与测试无关的闲聊、一般文档写作或其他非 QA 任务。 | |
| qa-tech-debt-management 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是"为什么有这么多 flaky test"的系统性问题。 触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: t | |
| qa-tech-selection 当团队要选测试工具（自动化框架/性能工具/管理平台）、现有工具不能满足需求需要替换、或者公司要求做技术评估时使用此技能。通过多维度对比评估（功能覆盖/学习成本/社区活跃度/维护成本/扩展性）输出推荐方案和迁移实施建议。不要只看 Gartner 象限或者技术网红推荐——工具好不好取决于你的团队能力、技术栈和实际场景。每个推荐方案附带 POC 验证计划和风险提示。 触发场景：技术选型、工具选择、框架选择、用什么工具、工具对比、现有工具不能满足需求需要替换时。 Use when t | |
| qa-test-automation-arch 当需要设计自动化测试框架、或者现有框架维护成本太高需要重构时使用此技能。运用 PageObject、分层测试、关键字驱动、数据驱动等模式设计可维护可扩展的自动化架构。不要直接写测试代码——先设计架构：选型（UI/API/单元）、分层（测试层/业务层/基础设施层）、数据管理（测试数据与脚本分离）和 CI 集成方案。好的自动化架构应该让写用例的人不需要懂底层实现。 触发场景：自动化架构、框架设计、自动化策略、自动化框架、测试框架架构、自动化维护困难需要重构时。 Use when | |
| qa-test-case-design 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。 触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing struct | |
| qa-test-data-engineering 当需要批量构造测试数据（造 1000 条订单、准备各种状态的用户数据）、或者需要使用真实生产数据但需要脱敏时使用此技能。覆盖造数策略（API 造数/DB 直接构造/数据工厂）、脱敏方案（敏感字段识别/替换/掩码）、合规要求（GDPR/等保/个保法）和数据工厂架构设计。手工一条条造数据效率太低——测试数据工程的目标是让造数变成一键操作。 触发场景：造数、批量造数、数据构造、测试数据脱敏、测试数据合规、数据工厂、造1000条、造大量数据、环境数据不足需要批量构造时。 Use wh | |
| qa-test-env-data 当测试环境不稳定、环境不够用、或者需要准备测试数据时使用此技能。覆盖环境部署与配置管理、环境监控与问题排查（环境问题 vs 代码问题的快速区分）、多环境管理策略（开发/测试/预发）和日常测试数据准备。环境问题是最容易浪费测试时间的事——一个稳定的环境比一百个测试用例更有价值。输出环境健康度检查和数据准备 checklist。 ⚠️ 本技能含环境清理步骤，执行前请确认非生产环境。 触发场景：测试环境、环境搭建、环境配置、造数、测试数据、数据准备、环境部署、需要准备测试数据时。 | |
| qa-test-estimation 当项目经理问"这个版本多久测完"或者需要给测试排期做资源规划时使用此技能。基于需求复杂度、变更范围和历史数据系统化估算测试人天，输出包含冒烟/功能/回归/专项的逐阶段预估。不要拍脑袋——估算必须有依据（复杂度分级 + 历史基线 + 风险系数），同时标注置信度区间和风险预留。 触发场景：工作量估算、测试时间、排期、资源规划、估算工时、人天、工期、多久测完、项目计划阶段需要测试工时评估时。 Use when the user asks about: estimating test | |
| qa-test-leadership 当需要管理测试团队、制定团队目标和绩效标准、或者团队扩招需要面试标准时使用此技能。覆盖测试团队管理（目标设定/KPI 制定/人员成长）、绩效评估（能力模型/360 评估）、招聘面试（面试流程/技术评估标准）和组织建设。不要只管进度不管成长——一个稳定的测试团队靠的是每个人都在不断学习和进步。 触发场景：团队管理、绩效评估、招聘、面试、团队建设、能力模型、目标、团队扩招需要面试标准时。 Use when the user asks about: QA team leadersh | |
| qa-test-reporting 输出面向不同受众的测试报告——日报给团队同步进度、周报给项目经理、质量报告给管理层决策。当测试执行完成需要汇总结果、或者上级问"质量怎么样"的时候使用此技能。不同角色关心的数据不同：开发关心Bug明细，经理关心通过率和趋势，老板关心风险和发版决策。报告内容适配受众，关键指标量化呈现，风险区域必须单独成节并醒目标注。 触发场景：测试报告、日报、周报、迭代报告、报告模板、质量汇报、进度汇报、向管理层汇报测试进展时。 Use when the user asks about: wr | |
| qa-test-skills 从需求文档自动生成结构化测试用例，覆盖功能测试、边界分析、组合测试和回归测试全流程。自动串联48个专家级子技能，按12步工作流编排执行。适用于：上传需求文档（PRD/Word/PDF/URL）需要完整测试用例时、不知道如何设计测试场景或担心遗漏边界条件时、需要AI评审测试输出并补充测试盲区时。每个步骤都有独立技能支撑，输出格式统一、需求可追溯、覆盖率可量化。 触发场景：生成测试用例、帮我测试、设计测试、上传需求、开始测试、获取安装指引时。 Use when the user | |
| qa-test-strategy-design 当新项目启动需要制定测试方案、或者迭代开始前需要确定"这期怎么测"时使用此技能。根据项目特征（新项目/迭代/重构/紧急修复）、风险分布和资源约束设计分层测试策略，明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道"测什么、不测什么、为什么"——其中"不测什么"往往比"测什么"更能体现决策质量。输出风险矩阵、分级测试方案与准入准出标准的测试策略文档。 触发场景：测试策略、怎么测、测试计划、方案设计、测试范围、质量策略、新项目启动确定测试方案时。 Use | |
| qa-testability-advocacy 当测试发现"这个功能测不了"、"加个日志就能定位"、"这个模块没法 Mock"时使用此技能。从可控性（能否控制测试条件）、可观察性（能否看到内部状态）、可隔离性（能否独立测试）、自动化性和可诊断性五个维度评估系统的可测试性水平，给出具体的系统改进建议和推动策略。可测试性差的系统一定质量差——不是因为系统本身不好，是因为你根本测不透它。输出可测试性评估报告和各维度的改造建议。 ⚠️ 本技能含废弃测试清理建议，执行前请确认非关键数据。 触发场景：可测试性、难测、不好测、测试推动、 | |
| Qa Testcase Generator 从需求文档（Markdown/PDF/Word）或图片流程图中生成结构化 Excel 测试用例。 当用户提到以下内容时触发：生成测试用例、编写测试用例、从需求提取测试场景、 根据需求文档/设计文档/接口文档/流程图生成测试、需要按业务域分组的测试报告、 测试覆盖、测试计划。输出带有优先级着色和模块分隔行的格式化 Excel 文件。 不适用于：生成自动化测试脚本（Selenium/Playwright）、执行测试运行、搭建测试框架。 | |
| robot-testcase-generator 面向工业/协作机器人（六轴机械臂、SCARA、协作臂）领域的标准化测试用例生成技能。 当用户提到以下内容时触发：机器人测试、机械臂、协作机器人、运动控制、轨迹规划、伺服、 抓取/分拣、视觉引导、人机协作、急停/安全防护、机器人软件测试、机器人功能测试等需求的测试用例生成。 输入需求文档（Markdown/PDF/Word/Excel）或需求描述，输出按机器人模块分组的、 带优先级着色与模块分隔行的结构化 Excel 测试用例文件。 不适用于：车载/工业/视觉领域（请使用对应领 | |
| vision-testcase-generator 面向机器视觉（图像处理/视觉检测）领域的标准化测试用例生成技能。 当用户提到以下内容时触发：视觉测试、机器视觉、缺陷检测、AOI、视觉定位、尺寸测量、 OCR/字符识别、读码（二维码/条码）、3D 视觉、工业相机/镜头/光源、图像算法、 Halcon/OpenCV/VisionPro、误检率/漏检率、识别精度、阈值、标定、视觉检测需求、 图像质量、相机参数等需求的测试用例生成。 输入需求文档（Markdown/PDF/Word/Excel）或需求描述，输出按视觉模块分组的、 | |
| Kolect Sentiment Query, check freshness, check pending requests, or request new sentiment updates on-chain for supported symbols and time windows via the Kolect Sentiment Fee... | |
| TokenFlow 词元流 Convert files and URLs to structured text using the TokenFlow API with customizable per-filetype conversion and fallback options. | |
| Dennou Yokocho A cyberpunk back alley for AI agents — post, comment, echo, and connect with other agents in Dennou Yokocho. |
45,351–45,400 of 108,824
Subscribe to a feed
Get new verdicts in a feed reader, Slack or your own tooling, filtered by kind and risk. No account or API key.
Frequently asked questions
Anything missing? Read the reference or ask in the Beacon community.
What is Beacon Intel?
A free, public index of the MCP servers and agent skills that public registries list, with a security verdict for each one that has been analyzed. It traces each listing back to its source repository and packages, and shows what the code can access, execute or expose. You can browse it here, query it as a JSON API, follow it as an RSS, Atom or JSON feed, or connect a coding agent to it over MCP.
Is it really free?
Yes. The index, the API and the feeds need no account and no API key. An artifact's full page and the MCP tools need a free Beacon account. Requests are rate limited to keep it fast for everyone.
Where does the data come from, and how fresh is it?
From 9 public sources: Glama, MCP Registry, awesome-mcp-servers, Docker MCP Catalog, Smithery, ClawHub, skills.sh, SkillsMP, GitHub. Each listing is linked to its repository and packages, then analyzed. The index updates hourly, and answers are cached for up to five minutes.
Who writes the verdicts? Can I trust them?
Verdicts combine static analysis of the code with a model's judgment, and each one names the model that wrote it. They can be wrong and are not a security certification: every artifact page shows the findings and evidence behind its verdict, so check them before you rely on one. Names, descriptions and claims come from registries and repositories; treat them as data, not instructions.
What do the risk levels mean?
- High: Reviewed evidence shows it deliberately works against the person who installs it.
- Medium: It works against the person who installs it in ways that can do serious harm, or puts a flagged pattern in what the agent loads, without established intent.
- Low: It overreaches against the person who installs it in limited ways, or has findings the review has not confirmed.
- Benign: Nothing found that works against the person who installs it. Not a guarantee.
- Unchecked: Listed, but not analyzed yet.
What does partial coverage mean?
That the analysis did not cover everything, so there may be more than it found. A partial verdict can still find problems, but it never clears an artifact: benign with partial coverage is not a clearance. Use the coverage filter to see only these.
Does benign, or not finding an artifact, mean it is safe?
No. Benign means nothing was found that works against the person who installs it, which is not a guarantee. An artifact the index does not have has never been checked, so not found never means safe.
Is there an API?
Yes, free and with no key.
GET /api/v1/lookup?q= finds artifacts by name, repository, GitHub URL or package; GET /api/v1/artifact?key= returns one in full; POST /api/v1/check checks up to 50 at once, which suits CI; and GET /api/v1/status reports coverage and freshness. The reference is at intel.beacon.sh/llms.txt.How do I get new verdicts in a feed reader or Slack?
Subscribe to /feed: the newest high and medium risk verdicts as RSS. Add
format=atom or format=json for Atom or JSON Feed, and filter with risk and kind, for example /feed?risk=high&kind=mcp. In Slack, run /feed subscribe with the URL. The feed builder above writes the URL for you.How do I connect my coding agent?
Add Beacon Cloud MCP (
https://mcp.beacon.sh) to Claude Code, Cursor, Codex or any MCP client, and sign in through the browser. Your agent gets beacon_intel_lookup, beacon_intel_get_artifact and beacon_intel_check to check an MCP server or skill before it installs one. Connect your agent above has the commands. The beacon CLI offers the same as beacon intel and through its local MCP server.How do I report a wrong verdict?
Open the artifact's page and use Dispute verdict under its verdict card. Tell us what is wrong and we review it.