claw-score

claw-score は何をしますか？

このスキルは、このリポジトリ内のOpenClaw成熟度スコアカードを扱う際に使用します。 これはメンテナー claw-score ワークフローのopenclaw-localバージョンです。 分類体系とスコアカードの概念は維持しますが、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 エントリが正確に1つ存在します。その証拠IDは機能に対して一意に保ってください。より広範な多対多の証拠マッピングは、現在の分類体系スキーマの一部ではありません。
• カバレッジIDは、小文字の英数字/ダッシュのセグメントで構成される namespace.behavior 形式を使用します。プロファイル、サーフェス、カテゴリIDは、ダッシュまたはドット区切りを維持しても構いません。
• カテゴリと機能名は一意で、製品としての形状を保ち、生のカバレッジIDよりも広範にしてください。汎用的なIDを独立した機能名に昇格させないでください。
• 1つのカテゴリ内で、異なる機能名の下に重複したカバレッジ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リポジトリルートから実行します。

ソース編集後にtaxonomy 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 解決を使用します。

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. このスキルのスキーマ検証コマンドを実行します。
7. ドキュメントの散文が変更された場合は pnpm check:docs を、カバレッジIDまたはプロファイルメンバーシップが変更された場合はフォーカスされたQAカバレッジチェックを実行します。

主観的なスコア変更の場合は、最小限の防御可能な編集を行い、証拠のパスをPRまたはタスクのサマリーに残してください。現在のドキュメントには手動の散文を保持し、スコアデータは qa/maturity-scores.yaml に保持してください。

デフォルトの完全性プロセス

完全性は、テストの幅や実装品質ではなく、各カテゴリの意図されたオペレーターから見えるワークフローに対してスコアリングされます。references/completeness/ の下の完全性リファレンスファイルは、カテゴリスコープと、このデフォルトプロセスからのサーフェス固有のバリエーションを定義します。

デフォルトでは、完全性はOpenClawがそのサーフェスに対して意図されたサーフェス機能セットをユーザー、オペレーター、作成者、またはメンテナーペルソナにどの程度完全に公開しているかを測定します。各カテゴリが期待される完全なワークフロー（セットアップ、通常使用、ステータスまたは検査、リカバリ、および該当する重要なプラットフォーム、プロバイダー、チャネル、セキュリティ、ライフサイクルのバリアントを含む）を提供しているかどうかをスコアリングします。

Surface-Specific Scoring Questions および Surface-Specific Guidance を、そのサーフェスにとって優先度の高い指示として扱います。サーフェス指示は、ここでのデフォルトのアイデアを肉付け、狭め、または意図的に矛盾する場合があります。その場合は、サーフェス指示に従い、スコアの根拠がそのサーフェス固有の指示を反映するようにしてください。リファレンスファイルにサーフェス固有の質問やガイダンスが含まれていない場合は、このデフォルトプロセスをサーフェスの Category Scope に適用します。

各カテゴリについて、以下の点を確認します。

• 意図されたユーザーまたはオペレーターは、カテゴリのワークフローを最初から最後まで完了できますか？
• 分類体系の機能は、孤立した実装の断片ではなく、サポートされている機能として存在していますか？
• 重要なライフサイクルステージ（セットアップ、通常操作、ステータス/検査、リカバリ、および関連する場合はアップグレードまたは削除）が表現されていますか？
• このサーフェスにとって重要な環境、プロバイダー、プラットフォーム、チャネル、またはセキュリティの分岐が存在していますか？
• 既知のギャップにより、主要なユーザーから見える機能ブランチが欠落していませんか？

デフォルトのガイダンス：

• カテゴリが分類体系とカテゴリ証拠によって記述された完全なオペレーターから見えるワークフローをサポートしている場合は、より高い完全性を優先します。
• ハッピーパスのみが存在する場合、重要なバリアントが文書化されていないか実装されていない場合、またはリカバリ/ステータスパスが欠落している場合は、完全性を低くします。
• テストが薄いからといって完全性を低くしないでください。それはカバレッジです。
• 実装品質が脆弱だからといって完全性を低くしないでください。それは品質です。

デフォルトの完全性バンド：

• Clawesome (95-100): 期待されるワークフロー、バリアント、リカバリブランチにわたって完全であり、軽微な磨き上げのギャップのみがある。
• Stable (80-95): 期待されるワークフローセットが概ね存在し、限定的な欠落ブランチのみがある。
• Beta (70-80): メインワークフローは存在するが、意味のあるブランチやリカバリパスがまだ欠落している。
• Alpha (50-70): 部分的な機能セットのみが存在し、ユーザーはいくつかのコアタスクを完了できるが、期待される完全なワークフローは完了できない。
• Experimental (0-50): カテゴリは意図された機能の断片のみを公開している。

決定コンテキスト

サーフェスおよびカテゴリの品質/完全性に対しては score と label の横に、カテゴリのLTSに対しては supported の横に、オプションの decision を記録します。taxonomy.yaml では、正規のサーフェス level の横にオプションの level_decision を使用します。

各レコードには value、rationale、reviewer、evidence_refs、revalidate_when が含まれます。品質/完全性には0～100の整数、LTSにはブール値、level_decision には宣言された分類レベルIDを使用します。空でないテキストフィールドと少なくとも1つの証拠参照を指定してください。実際のレビュー担当者と、別のレビューをトリガーすべき条件を名前で指定します。

利用できない履歴は存在しないものとして扱います。それは不明であり、レビュー担当者、根拠、証拠を捏造する誘因ではありません。レコードは現在のスコア、サポートフラグ、または正規のレベルを上書きしません。値が異なる場合は両方を保持し、生成されたドキュメントは厳格な入力検証下でも、ゲーティングされない不一致を表示します。

決定をカバレッジ、計算されたロールアップ、サーフェスLTSサマリー、またはスコア集計内のコピーされたレベルに添付しないでください。決定コンテキストは、カバレッジの同一性、スコア計算、サポートコミットメント、またはリリースゲートを変更しません。

スコアのセマンティクス

• カバレッジ：リリースプロファイル qa-evidence.json.scorecard の機能充足データから導出される、決定論的なリリース検証カバレッジ。
• 品質：カテゴリの信頼性、保守性、オペレーターの安全性、回帰に対する確信度。
• 完全性：カテゴリに対して意図されたオペレーターから見えるワークフローのうち、どの程度存在するか。このスコアを変更する前に、デフォルトの完全性プロセスとサーフェス固有のバリエーションを使用してください。
• LTS：品質、リリース証拠カバレッジ、human_lts_override から導出されます。LTSステータスを変更するために、生成されたMarkdownを手動で編集しないでください。

バンド：

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

アーティファクト

メンテナーリポジトリの docs/kevinslin/maturity-scorecard/inventory/ ツリーをopenclawに追加しないでください。証拠を充実させたスコアカード出力は、このリポジトリが最初に明示的なレンダラー/チェックワークフローを追加しない限り、コミットされた生成ドキュメントではなく、短期間のアーティファクトに属します。