So you found a skill.

Check these sources, in order

• Host and installer documentation: Confirm install location, visibility, precedence, sandboxing, permissions, secret handling, install hooks, update behavior, and rollback from the current primary documentation.
• Registry listing and security details: Check publisher identity, ownership changes, versions, changelogs, moderation, user reports, and the exact version and date covered by every scan result.
• Original source repository: Follow the registry provenance link. Compare owners, tags or commits, contents, and hashes; then inspect maintenance, security issues, license, and release history.
• Complete skill package: Read SKILL.md and every referenced file, script, configuration, active asset, hook, and nested archive. Inventory commands, files, tools, credentials, downloads, and network destinations.
• Dependencies and artifacts: Resolve direct and transitive dependencies, check official registries and advisories, verify downloaded binaries, and flag unversioned or runtime-fetched code and instructions.
• Independent security analysis: Scan the exact staged version with a reputable skill scanner. For higher-risk skills, use different scanner approaches and reconcile their findings rather than trusting a score.
• Primary product and API documentation: Verify each claimed command, permission, and workflow with the providers the skill controls. Reject broader access or infrastructure that the actual task does not need.
• Organizational evidence: Check internal policy, approved endpoints, data classification, prior reviews, and required approvals. Name an owner for updates, incidents, re-review, and removal.

Pass security and reliability gates

A listing badge, install count, official-looking name, or clean scanner result is one signal—not a certificate.

• The purpose is recurring and useful enough to justify another trust boundary.
• Publisher, source, artifact, version, and hashes form a consistent provenance chain.
• Files, tools, network access, credentials, and scopes follow least privilege.
• Data destinations, retention, logging, and telemetry are understood and acceptable.
• Actual instructions, scripts, dependencies, and network behavior match the listing.
• Failure, retries, cancellation, and malformed input do not create broader actions or data loss.
• Compatibility and observable tests cover the intended host, runtime, operating system, and scope.
• Independent scans and human review are resolved for the exact approved version.

Will it update automatically?

Verify every update layer. Read the host and installer docs; identify whether this is a managed marketplace install, registry install, Git source, or copied folder; inspect origin records, lockfiles, versions, hashes, channels, and pin state; then search scheduled tasks, CI, startup hooks, and agent instructions for update commands.

Also check runtime fetches. A skill can remain unchanged on disk while downloading new instructions or code whenever it runs.

Current OpenClaw documentation uses an explicit openclaw skills update --all command for registry-managed skills and records their origin for later updates. Git and local skills are refreshed by reinstalling them. That package layer is command-triggered unless a person, agent, startup hook, CI workflow, or scheduler runs the command automatically.

Before every update, diff the complete old and new packages, permissions, dependencies, and destinations; re-run review and scans; and preserve the approved artifact and rollback path.