judge（bro）是一个面向智能体循环的校准决策判定技能，托管于 https://www.skills.sh/theplenkov/bro/judge，来源为 theplenkov/bro。其核心定位是“策略层”：所有实际机制位于 bro CLI 中，该技能只负责策略。
用途 用于在智能体循环中对决策进行判定与标注，典型用途包括 act 分诊标注（triage annotation）和回退升级（fallback escalation）。它针对紧凑状态提出类型化问题（choice/score/noul），返回带置信度的类型化答案，速度在亚秒级，成本为美分的一小部分。
前置条件 需要 bro 在 PATH 中，或通过 npx -y @broject/bro@0 运行。
主要后端与回退 主后端是 systemone，即 TypeSafe 的 System One API（POST {judge.baseUrl}/v1/systemone，Authorization: Bearer $<judge.apiKeyEnv>，其中变量名由 judge.apiKeyEnv 指定，默认 TYPESAFE_API_KEY；TYPESAFE_BASE_URL 仅重定向默认 base，不会覆盖已配置的 host）。judge.fallback 可指定升级连接器（llm-judge，任意 OpenAI 兼容聊天端点），对未答问题以及低于 judge.confidence 的答案重新询问。
主要命令
bro self judge decide --state <file|-> --questions <file>：在解析后的链上执行一次 decide()，打印答案、decidedBy、model、latency、usage。--connector <name> 可固定主连接器，--json 打印原始 DecideResult。bro self judge stats [--since <iso>] [--json] [--replay]：对判定日志评分，包含一致矩阵（action 与记录结果、总体）、每个决策者的一致率、blocks_correctness 代理单独评分、校准分桶、p50/p95 延迟、按 provider+model 的均值/总成本，以及 dogfood 阈值（一致率≥85%、p50<1s、均值<$0.01）。--replay 对 dogfood 判定评分而非实时判定。bro self judge replay [--pr <n>[,<n>…]…] [--merged-since <iso>] [--limit <n>] [--connector <name>] [--json]：对已合并 PR 的归档评审线程在实时链上重新判定，每条判定以 replay: true 记入日志，结果从记录推断（act disposition → defer bead → 以过时锚点解决；仅一次 push 不算证据，无法恢复结果的线程会被剔除；存在 disposition 或 defer bead 的未解决线程仍可分类），然后打印 replay 范围统计报告。该操作幂等，已回放的 subject 不会重复判定。
配置（bro.config.json 的 judge 段） mode（off|shadow，v1 无 acting 模式）、model（生产环境应固定）、baseUrl、apiKeyEnv（环境变量“名称”，绝不放值）、confidence（默认 0.6）、fallback、timeoutMs（约束整个链式调用）、maxDecisionsPerRun（默认 50，每次调用新鲜 decide() 的数量）、llm（{baseUrl, model, apiKeyEnv}）。
shadow 模式行为 在 shadow 模式下，bro 命令 decide() 返回的每个判定都会追加到 <git-common>/bro/judge/verdicts.jsonl（只追加，跨链接工作树共享，不进入 git）：act/drive 线程标注为 kind: 'act-thread' 行，bro self judge decide 冒烟调用为 kind: 'judge-decide'（不进入分诊一致集），以及 bro review act resolve/reply 或 act plan 应用判定时的 kind: 'act-disposition' 行。日志记录需要 git 仓库，否则追加静默无操作。bro review act threads 与 drive fixer 提示会在每个未解决线程旁渲染 judge: 行（blocks_correctness、severity、action），使用同一去重键（threadId, commentSha, headSha）：已有记录的 subject 重复轮询时免费读取；已移动或无判定的 subject 会重新 decide()，受每次调用 maxDecisionsPerRun 限制（整个 drive 过程共享）。
策略要点
- shadow 是边界而非心情：判定只做标注，绝不执行动作；线程解决仍需 bro review act resolve/reply，退出闸门仍读取确定性状态，fixer 生成保持确定性。判定通过实测 dogfood 一致率获得建议权重，绝不能把判定接入闸门决策。
- 始终 fail-open：后端卡住时抛出 JudgeUnavailable，消费者将“无判定”视为“无标注”，绝不作为闸门输入。
- 一次调用，多个问题：将同一 subject 的问题批量放入一次 decide()，逐题循环调用是成本缺陷。
- decidedBy 诚实：升级答案标记为 llm-judge，stats 按各自记录对每个后端评分。
- 密钥只经环境变量：apiKeyEnv 命名变量，配置中绝不保存密钥值。
适用场景与限制 适用于需要低成本、带置信度的智能体循环决策标注与分诊，以及通过回放和统计衡量判定质量。限制包括：v1 无 acting 模式；shadow 日志需 git 仓库；无 git 仓库时追加静默失败；judge 判定不能作为闸门输入；未在资料中提及的功能、收费或平台支持暂未提供。