ClawScan response

Turn an alert or scan complaint into an evidence-backed disposition, an authorized repair, or a report to the component owner. Run from a ClawHub checkout. This skill grants no deployment, moderation, publication, or communication authority; use the authority supplied with the task and the applicable repository skills.

Intake and delegation

Admin owns intake and the final notification. Delegate substantial investigation through the existing runtime so its main session stays available. Read the active workspace's delegation guidance and discover its actual session tools before choosing parameters. Delegating substantial work is instruction/prompt guidance, shaped by workspace policy and runtime defaults; it is not enforced by the spawn engine. Session creation, tool access, and delivery are runtime behavior.

Pass the alert permalink, firing time/window, environment, query/run links, known job or artifact identity, this skill's path, allowed actions, and required return destination to the worker. Include already-active investigation context to avoid duplicate repairs. Use native child status and completion handling; follow the accepted spawn receipt for result delivery. Do not invent a delegation API, impose a worker cap, add a progress database, or schedule another health job.

Workers return evidence and decisions to the requesting Admin session. Admin reviews the result and posts the notification in its established thread. A worker completion establishes neither deployment nor production acceptance.

If the request is an account-ban appeal, route it to clawhub-ban-appeals. That skill may supply a scanner inaccuracy for the upstream-reporting branch below; it retains ownership of the appeal decision.

Establish what happened

Read evidence and tools for the applicable read surface. Correlate the alert window with the exact run/job/attempt and a fresh observation of the same environment. Record observation times, observed impact, completed versus failed attempts, and current queue/run state when relevant. Report unavailable coverage explicitly; missing data is not health.

Choose the supported disposition before changing anything:

Record alert validity at firing time separately from actionability now. A real failure that later recovered remains a true historical failure; describe it as currently recovered/non-actionable only to the extent fresh evidence supports.

A completed malicious or suspicious verdict can be operationally healthy. An orchestrator that exited successfully can still contain a failed scanner or unusable judge result. Check the relevant stage and consumer validation, not just the workflow conclusion. Preserve concurrent valid security findings when one finding is wrong.

Attribute the defect

Trace the first failing boundary, using exact input/output evidence and deployed versions. Separate a confirmed cause from an unverified candidate.

An external provider or host dependency can be the operational cause; keep its attribution explicit rather than forcing it into a scanner verdict defect. If evidence spans components, name the primary failing boundary and contributing components. Do not guess an upstream repository from a report's display label.

Repair or route

For a confirmed repairable defect, use an isolated checkout and the existing code/test seams. Demonstrate the failure and changed behavior with the same input or a faithful sanitized regression. Run the touched repository's relevant checks. For Convex changes, first read clawhub-convex; production deployment follows clawhub-production-release.

Operational actions such as dispatching workers, rescanning, changing config, deploying, or restoring content require the task's corresponding authority. A repair task does not permit new release gates, model/provider changes, broader security exceptions, or retries until a preferred verdict appears. If another owner is already repairing the incident, return relevant new evidence to that owner instead of starting a competing recovery.

Validated scanner inaccuracies

Read upstream reporting. Every validated accuracy complaint is deduplicated and tracked in openclaw/clawscan, including SkillSpector/AIG findings and ClawHub-only verdict mapping defects. For the latter, tag the report as ClawHub integration and link the primary ClawHub repair; do not misattribute it to a scanner. Pure operational failures do not require an accuracy report. Link an existing issue or prepare a new report with component attribution, exact versions, reproduction, and analysis. Further reporting to NVIDIA/Tencent follows the component's contribution/security policy and task authority; preserve the ClawScan tracking link.

Accuracy repair should generalize to the observed failure mechanism. Do not add per-package verdict exceptions, suppress valid findings, or bypass scanning to settle a complaint. Account or listing restoration remains a separate moderation decision.

Return to Admin

Return a concise result through the runtime's existing parent/session path:

• Disposition, environment, alert/source link, and observation time.
• Confirmed impact and component owner, with evidence links and any uncertainty.
• Repair or report outcome: exact changes/commits, regression before/after, checks, existing upstream link or a ready-to-publish draft.
• Actions actually executed versus prepared, current verification limits, and any exact missing input or decision needed.

Admin verifies the evidence and uses its normal notification path. Keep private authority, account identifiers, and deployment configuration in the active workspace; public skill content is reusable procedure.