spec-probes 用于在写代码之前编写或审查规格、需求、验收标准、用户故事或工单。其核心思路是：验证器只能检查已存在的断言，对规格未声明的边界会自信地出错；解决办法不是更好的验证器，而是规格完整性。
用法分两轮，按顺序对每条需求执行。第一轮为边缘探测：先判断需求的数据形态（numeric-range、collection、text、stateful、io），只对与形态相交的类别提问。类别包括边界值（numeric-range，问最小、最大或阈值处及两侧一步发生什么）、相邻性（collection，两个元素完全相等或刚好接触时是合并、碰撞还是分开）、空或退化（collection、text，空、单元素或 null 输入的结果）、编码（text，长度与相等按字节、码点、字素簇还是规范化形式）、顺序与稳定性（collection，元素相等时输出顺序是否指定且稳定）、精度与溢出（numeric-range，舍入、平局处理、精度损失或溢出的确切约定）、幂等性（stateful，同一输入运行两次会怎样）、并发或影响顺序（stateful、io，被中断或并行运行时保证什么）。分类是封闭的，纯文本需求不会问溢出；有文字但不匹配形态的需求会得到一条“未分类，需人工审查”的软提示。
第二轮为禁止项探测：对每条需求发问，这个功能可能悄悄变成什么作者不想要、但规格未禁止的样子。先广泛列举，每条需求十个原始候选属预期；再做精简：剔除常규工程项（如不得修改输入、不得对空抛错、不得泄漏句柄），保留价值观、公平、隐私、透明和安全项（如不得使用羞辱性措辞、不得代理受保护属性、不得明文存储原始 PII），对专门工具已负责的内容（注入、路径穿越、数据留存法律、通用偏见规范）只留一条指向安全或合规步骤的线索。每个功能通常产出两三条定制项，纯工具产出零条即正确。
每个提出项须落到一种状态：resolved（验收标准给出答案，或用留出测试、属性测试作为 backstop，或需人类判断的 judgment）；dismissed 并附理由（理由即审计线索，沉默不算）；unresolved 作为计划必须暴露的显式缺口向前传递，不得静默丢弃。backstop 与 judgment 标签要写进规格本身，以便后续审查者对其弃权而非误判通过。
局限与说明：资料未提供安装命令、平台、收费或价格信息，暂未提供。