claw-score skill

claw-score

Use this skill when working on the OpenClaw maturity scorecard in this repo. This is the openclaw-local version of the maintainer claw-score workflow: it keeps the taxonomy and scorecard concepts, but excludes discrawl and the old committed inventory/ report tree.

Authority

This skill owns the operational workflow for:

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

Keep person-specific, maintainer-private, Discord archive, and discrawl facts out of this repo. If a score needs private evidence, use the redacted qa-evidence.json artifact shape generated by OpenClaw QA workflows.

Source Model

QA profiles, categories, feature coverage IDs, docs refs, LTS overrides, and completeness-instruction paths.

• taxonomy.yaml is the hand-edited source of truth for surfaces, levels,

unique to the feature; broader many-to-many evidence mapping is not part of the current taxonomy schema.

• Each feature has exactly one coverageIds entry. Keep that evidence ID

alphanumeric/dash segments. Profile, surface, and category IDs may remain dashed or dotted.

• Coverage IDs use dotted namespace.behavior form, with lowercase

coverage IDs. Do not promote generic IDs into standalone feature names.

• Keep categories and feature names unique, product-shaped, and broader than raw

category.

• Avoid duplicate coverage-ID bundles under different feature names in one

Completeness, and LTS review state.

• qa/maturity-scores.yaml is the committed aggregate source for Quality,

readValidatedQaMaturityScoreSources; use it to validate score output.

• extensions/qa-lab/src/scorecard-taxonomy.ts exports

docs/maturity/taxonomy.md; both come from pnpm maturity:render. Do not hand-edit generated Markdown to change score results.

• Generated public docs are docs/maturity/scorecard.md and

profile artifacts are the source of truth for Coverage. They can enrich generated artifact docs, but they are not committed as inventory.

• qa-evidence.json artifacts provide per-run QA scorecard evidence. Release

Commands

Run from the openclaw repo root.

Validate taxonomy YAML structure and the maturity score schema after source edits:

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

Check docs when touching docs prose:

pnpm check:docs

Run focused QA/profile checks when changing coverage IDs or profile membership:

pnpm openclaw qa coverage --json

Full Generation Runs

For a direct full scorecard run that publishes the generated-doc pull request, use floating main resolution by default:

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

Do not resolve main locally and pass that commit as both ref and expected_sha for an ordinary manual generation run. OpenClaw's main moves quickly, so the caller-selected commit can become stale before validation. The workflow then correctly rejects publication when the pull request base contains newer maturity inputs, and QA never starts.

With ref=main and a blank expectedsha, the workflow's floatingdefault_branch path fetches and freezes the current remote default branch inside validation before handing an immutable revision to downstream jobs. Use an explicit SHA only when the requested evidence must remain bound to that exact revision, such as a release-candidate workflow call or an artifact-only historical reproduction. If that exact-revision run also requests publication and main has changed relevant inputs, expect validation to fail and dispatch again from floating main instead.

Scoring Workflow

When asked to score or refresh a surface:

.agents/skills/claw-score/references/completeness/.

1. Read the surface in taxonomy.yaml.
2. Read the surface completeness rubric under

metadata.

1. Gather public repo evidence from docs, source, tests, and QA scenario

proof.

1. Prefer existing release profile qa-evidence.json artifacts for executed

review state backed by public or redacted artifact evidence.

1. Update qa/maturity-scores.yaml only for Quality, Completeness, and LTS

if coverage IDs or profile membership changed.

1. Run the schema validation command from this skill.
2. Run pnpm check:docs if docs prose changed, and focused QA coverage checks

For subjective score changes, make the smallest defensible edit and leave the evidence path in the PR or task summary. Keep manual prose in current docs and keep score data in qa/maturity-scores.yaml.

Default Completeness Process

Completeness is scored against the intended operator-visible workflow for each category, not against test breadth or implementation quality. The completeness reference files under references/completeness/ define the category scope and any surface-specific variation from this default process.

By default, Completeness measures how fully OpenClaw exposes the intended surface capability set to the user, operator, author, or maintainer persona for that surface. Score whether each category delivers the full expected workflow, including setup, normal use, status or inspection, recovery, and important platform, provider, channel, security, or lifecycle variants where they apply.

Treat Surface-Specific Scoring Questions and Surface-Specific Guidance as higher-priority instructions for that surface. The surface instructions may flesh out, narrow, or intentionally conflict with the default ideas here; when they do, follow the surface instructions and make the score rationale reflect that surface-specific instruction. If a reference file does not include surface-specific questions or guidance, apply this default process to the surface's Category Scope.

For each category, ask:

isolated implementation fragments?

• Can the intended user or operator complete the category workflow end to end?
• Are the taxonomy features present as supported capabilities rather than

status/inspection, recovery, and upgrade or removal where relevant?

• Are the important lifecycle stages represented: setup, normal operation,