claw-score

claw-score 是做什么的？

在处理此仓库中的 OpenClaw 成熟度评分卡时使用此技能。 这是维护者 claw-score 工作流程的 openclaw 本地版本： 它保留了分类法和评分卡概念，但排除了 discrawl 和旧的已提交 inventory/ 报告树。

权限

此技能拥有以下内容的操作工作流程：

• taxonomy.yaml
• qa/maturity-scores.yaml
• docs/concepts/qa-e2e-automation.md
• qa/scenarios/index.yaml

将个人特定、维护者私有、Discord 存档和 discrawl 事实排除在此仓库之外。如果某个分数需要私有证据，请使用由 OpenClaw QA 工作流程生成的脱敏 qa-evidence.json 工件形状。

源模型

• taxonomy.yaml 是人工编辑的真实来源，包含表面、级别、QA 配置文件、类别、功能覆盖率 ID、文档参考、LTS 覆盖和完整性指令路径。
• 每个功能只有一个 coverageIds 条目。保持该证据 ID 对功能的唯一性；更广泛的多对多证据映射不属于当前分类法架构。
• 覆盖率 ID 使用点分 namespace.behavior 形式，包含小写字母数字/破折号段。配置文件、表面和类别 ID 可以保留破折号或点分形式。
• 保持类别和功能名称唯一、以产品为导向，且比原始覆盖率 ID 更广泛。不要将通用 ID 提升为独立的功能名称。
• 避免在一个类别下使用不同功能名称重复的覆盖率 ID 包。
• qa/maturity-scores.yaml 是质量、完整性和 LTS 审查状态的已提交聚合来源。
• extensions/qa-lab/src/scorecard-taxonomy.ts 导出 readValidatedQaMaturityScoreSources；使用它来验证分数输出。
• 生成的公共文档是 docs/maturity/scorecard.md 和 docs/maturity/taxonomy.md；两者都来自 pnpm maturity:render。不要手动编辑生成的 Markdown 来更改分数结果。
• qa-evidence.json 工件提供每次运行的 QA 评分卡证据。发布配置文件工件是覆盖率的真实来源。它们可以丰富生成的工件文档，但不会作为库存提交。

命令

从 openclaw 仓库根目录运行。

在源编辑后验证分类法 YAML 结构和成熟度分数架构：

node --import tsx --input-type=module <<'NODE'
import fs from "node:fs";
import YAML from "yaml";
import { readValidatedQaMaturityScoreSources } from "./extensions/qa-lab/src/scorecard-taxonomy.ts";

for (const file of ["taxonomy.yaml", "qa/scenarios/index.yaml"]) {
  YAML.parse(fs.readFileSync(file, "utf8"));
}
readValidatedQaMaturityScoreSources();
NODE

在修改文档内容时检查文档：

pnpm check:docs

在更改覆盖率 ID 或配置文件成员资格时运行有针对性的 QA/配置文件检查：

pnpm openclaw qa coverage --json

完整生成运行

对于直接进行完整评分卡运行并发布生成的文档拉取请求，默认使用浮动的 main 解析：

gn workflow run maturity-scorecard.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f ref=main \
  -f expected_sha='' \
  -f publish_pull_request=true \
  -f allow_failures=true

对于普通的手动生成运行，不要本地解析 main 并将该提交作为 ref 和 expected_sha 传递。OpenClaw 的 main 分支移动很快，因此调用者选择的提交可能在验证之前就变得过时。然后，当拉取请求基础包含更新的成熟度输入时，工作流程会正确拒绝发布，并且 QA 永远不会启动。

使用 ref=main 和空白的 expected_sha，工作流程的 floating_default_branch 路径会在验证内部获取并冻结当前的远程默认分支，然后将不可变的修订版本传递给下游作业。仅当请求的证据必须绑定到该确切版本时（例如发布候选工作流程调用或仅工件的历史重现），才使用显式 SHA。如果该确切版本运行也请求发布并且 main 已更改相关输入，预计验证将失败，并改为从浮动的 main 重新调度。

评分工作流程

当被要求评分或刷新某个表面时：

1. 读取 taxonomy.yaml 中的表面。
2. 读取 .agents/skills/claw-score/references/completeness/ 下的表面完整性规则。
3. 从文档、源代码、测试和 QA 场景元数据中收集公共仓库证据。
4. 优先使用现有的发布配置文件 qa-evidence.json 工件作为已执行的证明。
5. 仅更新 qa/maturity-scores.yaml 中质量、完整性和 LTS 审查状态，这些状态需有公开或脱敏工件证据支持。
6. 运行此技能中的架构验证命令。
7. 如果文档内容发生更改，则运行 pnpm check:docs；如果覆盖率 ID 或配置文件成员资格发生更改，则运行有针对性的 QA 覆盖率检查。

对于主观的分数更改，进行最小防御性编辑，并在 PR 或任务摘要中保留证据路径。将手动内容保留在当前文档中，并将分数数据保留在 qa/maturity-scores.yaml 中。

默认完整性流程

完整性是根据每个类别的预期操作者可见工作流程来评分的，而不是根据测试范围或实现质量。references/completeness/ 下的完整性参考文件定义了类别范围以及任何偏离此默认流程的表面特定变体。

默认情况下，完整性衡量 OpenClaw 向该表面的用户、操作者、作者或维护者角色公开预期表面能力集的程度。对每个类别评分，评估是否交付了完整预期工作流程，包括设置、正常使用、状态或检查、恢复以及适用的重要平台、提供商、渠道、安全性或生命周期变体。

将 表面特定评分问题 和 表面特定指南 视为该表面的更高优先级指令。表面指令可以充实、缩小或有意与此处的默认想法冲突；当冲突时，遵循表面指令并使评分理由反映该表面特定指令。如果参考文件不包含表面特定问题或指南，则将此默认流程应用于表面的 类别范围。

对于每个类别，询问：

• 预期的用户或操作者能否端到端完成类别工作流程？
• 分类法功能是否作为受支持的功能存在，而不是孤立的实现片段？
• 重要的生命周期阶段是否得到体现：设置、正常操作、状态/检查、恢复以及在相关情况下的升级或移除？
• 此表面是否存在重要的环境、提供商、平台、渠道或安全性分支？
• 已知的差距是否留下重要的用户可见能力分支缺失？

默认指南：

• 当类别支持由分类法和类别证据描述的完整操作者可见工作流程时，倾向于更高的完整性。
• 当仅存在快乐路径，重要的变体未记录或未实现，或者恢复/状态路径缺失时，降低完整性。
• 不要因为测试不足而降低完整性；那是覆盖率。
• 不要因为实现质量脆弱而降低完整性；那是质量。

默认完整性等级：

• 极好 (95-100)：跨预期工作流程、变体和恢复分支完整，仅有微小润色差距。
• 稳定 (80-95)：预期工作流程集广泛存在，仅有有限缺失分支。
• Beta (70-80)：主要工作流程存在，但有意义的分支或恢复路径仍然缺失。
• Alpha (50-70)：仅存在部分能力集；用户可以完成一些核心任务，但无法完成完整的预期工作流程。
• 实验性 (0-50)：该类别仅暴露了预期能力的片段。

决策上下文

在表面和类别的质量/完整性中，在 score 和 label 旁边记录一个可选的 decision；或在类别 LTS 的 supported 旁边记录。在 taxonomy.yaml 中，在规范性表面 level 旁边使用可选的 level_decision。

每个记录包含 value、rationale、reviewer、evidence_refs 和 revalidate_when。使用 0–100 的整数表示质量/完整性，布尔值表示 LTS，以及声明的分类法级别 ID 表示 level_decision。提供非空的文本字段和至少一个证据引用。命名实际的审查者以及应触发另一次审查的条件。

让不可用的历史记录保持缺失状态：它是未知的，而不是邀请发明审查者、理由或证据。记录不会覆盖当前分数、支持标志或规范性级别。如果其值不同，则同时保留两者；生成的文档会显示非门控的不匹配，包括在严格输入验证下。

不要将决策附加到覆盖率、计算出的汇总、表面 LTS 摘要或分数聚合中的复制级别。决策上下文不会更改覆盖率身份、分数计算、支持承诺或发布门控。

分数语义

• 覆盖率：来自发布配置文件 qa-evidence.json.scorecard 特征满足数据的确定性发布验证覆盖率。
• 质量：该类别的可靠性、可维护性、操作者安全性和回归置信度。
• 完整性：该类别的预期操作者可见工作流程存在程度。在更改此分数之前，请使用默认完整性流程加上任何表面特定变体。
• LTS：源自质量、发布证据覆盖率和 human_lts_override；不要手动编辑生成的 Markdown 来更改 LTS 状态。

等级：

• 极好：95-100
• 稳定：80-95
• Beta：70-80
• Alpha：50-70
• 实验性：0-50

工件

不要将维护者仓库的 docs/kevinslin/maturity-scorecard/inventory/ 树添加到 openclaw 中。证据丰富的评分卡输出属于短期工件，而不是已提交的生成文档，除非此仓库首先添加了显式的渲染器/检查工作流程。