claw-score

claw-score 是做什麼的？

當你需要在此儲存庫中處理 OpenClaw 成熟度評分卡時，使用此技能。 這是 openclaw 本地版本的維護者 claw-score 工作流程： 它保留了分類法和評分卡的概念，但排除了 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 結構和成熟度分數 schema：

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 解析：

gh 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. 僅當品質、完整性和 LTS 審查狀態有公開或編輯過的工件證據支援時，才更新 qa/maturity-scores.yaml。
6. 執行此技能的 schema 驗證命令。
7. 如果文件內容有更改，執行 pnpm check:docs；如果涵蓋率 ID 或設定檔成員資格有更改，則執行焦點式 QA 涵蓋率檢查。

對於主觀的分數更改，進行最小且可辯護的編輯，並在 PR 或任務摘要中留下證據路徑。將手動內容保留在當前文件中，並將分數資料保留在 qa/maturity-scores.yaml 中。

預設完整性流程

完整性是根據每個類別的預期操作者可見工作流程進行評分，而不是根據測試廣度或實作品質。references/completeness/ 下的完整性參考檔案定義了類別的範圍，以及此預設流程的任何表面特定變異。

預設情況下，完整性衡量 OpenClaw 向該表面的使用者、操作員、作者或維護者角色暴露預期表面能力集的程度。評分時要檢查每個類別是否提供了完整的預期工作流程，包括設定、正常使用、狀態或檢查、恢復，以及（適用的）重要的平台、提供者、通道、安全性或生命週期變異。

將「表面特定評分問題」和「表面特定指南」視為該表面的更高優先級指令。表面指令可能闡述、縮小或故意與此處的預設想法衝突；當這種情況發生時，請遵循表面指令，並使評分理由反映該表面特定指令。如果參考檔案不包含表面特定的問題或指南，則對該表面的「類別範圍」套用此預設流程。

對於每個類別，問：

• 預期的使用者或操作者能否端到端地完成類別工作流程？
• 分類法功能是否以受支援的能力存在，而不是孤立的實作片段？
• 重要的生命週期階段是否都已呈現：設定、正常操作、狀態/檢查、恢復，以及（適用的）升級或移除？
• 對於此表面，重要的環境、提供者、平台、通道或安全性分支是否都已存在？
• 已知的差距是否導致主要的使用者可見能力分支缺失？

預設指南：

• 當類別支援分類法和類別證據所描述的完整操作者可見工作流程時，優先給予較高的完整性評分。
• 當僅存在快樂路徑、重要的變異沒有文件記錄或未實作、或者恢復/狀態路徑缺失時，給予較低的完整性評分。
• 不要因為測試薄弱而降低完整性評分；那是涵蓋率的事。
• 不要因為實作品質脆弱而降低完整性評分；那是品質的事。

預設完整性等級：

• Clawesome (95-100)：在預期的工作流程、變異和恢復分支中完整，僅有次要的打磨缺口。
• Stable (80-95)：預期的工作流程集廣泛存在，僅有有限度的缺失分支。
• Beta (70-80)：主要工作流程存在，但有意義的分支或恢復路徑仍然缺失。
• Alpha (50-70)：僅存在部分能力集；使用者可以完成一些核心任務，但無法完成完整的預期工作流程。
• Experimental (0-50)：類別僅暴露了預期能力的片段。

決策上下文

在表面的品質/完整性分數旁邊記錄一個可選的 decision，或者在類別層級記錄。在類別的 LTS 中，記錄在 supported 旁邊。在 taxonomy.yaml 中，在標準的表面 level 旁邊使用可選的 level_decision。

每個記錄包含 value、rationale、reviewer、evidence_refs 和 revalidate_when。對於品質/完整性使用 0-100 的整數，對於 LTS 使用布林值，對於 level_decision 使用已宣告的分類法層級 ID。提供非空的文字欄位和至少一個證據參考。指明實際的審查者以及應觸發另一次審查的條件。

將不可用的歷史記錄省略：它是未知的，而不是邀請發明審查者、理由或證據。記錄不會覆蓋當前的分數、支援標記或標準層級。如果其值不同，則兩者都保留；生成的文檔會顯示非閘控的不匹配，包括在嚴格的輸入驗證下。

不要將決策附加到涵蓋率、計算的彙總、表面 LTS 摘要或分數彙總中複製的層級。決策上下文不會更改涵蓋率身份、分數計算、支援承諾或發布閘控。

分數語義

• 涵蓋率：從版本設定檔 qa-evidence.json.scorecard 功能履行資料派生的確定性版本驗證涵蓋率。
• 品質：類別的可靠性、可維護性、操作員安全性和回歸信心。
• 完整性：類別中預期的操作者可見工作流程存在多少。在更改此分數之前，使用預設完整性流程以及任何表面特定的變異。
• LTS：從品質、版本證據涵蓋率和 human_lts_override 派生；不要手動編輯生成的 Markdown 來更改 LTS 狀態。

等級：

• Clawesome：95-100
• Stable：80-95
• Beta：70-80
• Alpha：50-70
• Experimental：0-50

工件

不要將維護者儲存庫的 docs/kevinslin/maturity-scorecard/inventory/ 樹添加到 openclaw。證據豐富的評分卡輸出屬於短暫的工件，而不是已提交的生成文件，除非此儲存庫首先添加了明確的渲染器/檢查工作流程。