OpenClaw CWS Publisher

IT 运维与安全

OpenClaw CWS Publisher 是一个公开的 ClawHub Chrome Web Store 发布技能，用于用户提及“chrome web store publisher”“extension release publishing”等场景。

DevOps

791

下载量

安装量

收藏量

★ 5.0

综合评分ⓘ

概述

更多信息

OpenClaw CWS Publisher#

Search intent: chrome web store publisher, extension release publisher, cws publisher, chrome extension publish

Goal#

Prepare a Chrome extension repo for release with less metadata drift:

package the extension
validate the exact ZIP intended for upload against source manifest and CWS listing copy
scan tracked and untracked non-ignored files for obvious leak risks
run local reviewer/E2E gates
enforce design, UI, screenshot, and claim-alignment score gates
enforce storefront media uniqueness so portfolio waves do not reuse the same icon motif, promo layout, visual signature, thumbnail template, or exact asset
enforce public landing, privacy, support, reviewer, SEO, and Cloudflare canonical-page gates before dashboard submission
check current Chrome Stable release data before declaring E2E coverage fresh
run a lightweight competitor and positioning differentiation check
require a repo-local product-share/traffic-source gate when present, before treating a new extension as submission-ready
detect repo-local reviewer gates
generate GitHub metadata
generate optional ClawHub metadata and explicit tags
render reproducible publish commands

Use This Skill When#

the user wants a Chrome extension repo prepared for GitHub release
the user wants CWS ZIP/listing/privacy/design/E2E readiness checked before dashboard submission
the user wants ClawHub tags and GitHub topics kept in sync
the user wants a leakage check before public release
the user already has a specific repo path to release

Companion Scripts#

The public ClawHub artifact is instruction-only so install-gate audits can return PASS. When the companion repository is available, set:

bash

export OPENCLAW_CWS_PUBLISHER_DIR=/path/to/openclaw-cws-publisher/scripts/openclaw-cws-publisher

Then use $OPENCLAW_CWS_PUBLISHER_DIR/<script>.py in the commands below.

Operating Order#

Run the repo-local product-share gate when present.
- Example: npm run check:product-share or python3 scripts/check_product_share_gate.py --product <slug>
- Block submission when the first traffic source, trust reason, share moment, free MVP window, 30-60 day kill criteria, or ecosystem path is missing.
Build the extension ZIP intended for upload.
- python3 "$OPENCLAW_CWS_PUBLISHER_DIR/build_extension_zip.py" --extension-dir <repo>/extension --out <zip>
Validate the exact ZIP, source manifest, and listing contract.
- python3 "$OPENCLAW_CWS_PUBLISHER_DIR/validate_cws_package.py" --zip <zip> --source-manifest <repo>/extension/manifest.json --listing-json <repo>/docs/cws/listing.json
- Default posture blocks stale ZIPs, Manifest V2, tabs, debugger, <all_urls>, persistent host permissions, declarative content scripts, remote script/eval patterns, missing permission justifications, privacy-practice drift, and no-host ZIPs whose listing still carries host-permission copy.
- If a product genuinely needs host permissions, use --allow-host-permissions only after the listing and reviewer instructions explain the shipped user-facing need.
Scan tracked and untracked non-ignored files for obvious publish leaks.
- python3 "$OPENCLAW_CWS_PUBLISHER_DIR/scan_publish_surface.py" --root <repo> --json-out <json> --markdown-out <md>
Run local reviewer/E2E gates.
- python3 "$OPENCLAW_CWS_PUBLISHER_DIR/run_local_e2e_gates.py" --repo-root <repo> --json-out <json> --markdown-out <md>
- The script discovers check:cws, check:public, check:public:visual, test:e2e:reviewer, test:e2e, and scripts/reviewer_gate.py when present.
Enforce the design/UI/UX evidence gate.
- python3 "$OPENCLAW_CWS_PUBLISHER_DIR/check_design_gate.py" --design-report <repo>/docs/design-gate.json --screenshot-metadata <repo>/assets/listing/screenshot-1.png.source.json
- Every changed public page, popup, CWS screenshot, promo tile, hero, and media asset must score at least 8/10 for product clarity, visual trust, evidence integrity, responsive polish, accessibility, and claim alignment.
- For multi-extension or portfolio submissions, docs/design-gate.json must include media_identities with unique icon_motif, promo_layout, and visual_signature values plus store-icon, small-promo, and marquee-promo asset paths for each item. Recolored copies of the same thumbnail template are a blocker even when dimensions and basic scores pass.
Enforce public landing and SEO gates.
- The CWS-facing site must have a polished product-first landing page, a readable privacy policy, support page, reviewer guide, robots.txt, sitemap.xml, canonical URLs, Open Graph/Twitter metadata, and factual SoftwareApplication JSON-LD when applicable.
- Prefer Cloudflare Pages or another owned HTTPS host as the canonical CWS listing surface. GitHub source-viewer URLs and temporary fallback mirrors must not remain in active listing metadata.
- Block submission when SEO metadata points to an old domain, when public pages look like policy stubs, or when privacy/support/reviewer pages do not reflect the exact package permissions and user-data behavior.
Check current Chrome Stable release data.
- python3 "$OPENCLAW_CWS_PUBLISHER_DIR/check_chrome_release.py" --tested-chrome-version <local chrome version> --json-out <json> --markdown-out <md>
- Source: Chrome for Testing last-known-good Stable feed, cross-checked with ChromiumDash, Chrome Releases, and Chrome for Developers release notes when making decisions.
Run a competitor/differentiation check.
- python3 "$OPENCLAW_CWS_PUBLISHER_DIR/check_competitors.py" --listing-json <repo>/docs/cws/listing.json --competitors-json <repo>/docs/cws/competitors.json --min-competitors 3 --markdown-out <md>
- Record at least three comparable products or explicit substitutes; flag risky claims like #1, best, official, and close-copy positioning.
Generate launch metadata.

python3 "$OPENCLAW_CWS_PUBLISHER_DIR/generate_launch_manifest.py" --repo-root <repo> --owner <github-owner> --public-site-base <https://public-site.example/> --out <json>
If you already export CWS_PUBLIC_SITE_BASE, you can omit --public-site-base and the script will reuse that public reviewer-facing base.

Render publish commands.

python3 "$OPENCLAW_CWS_PUBLISHER_DIR/render_publish_commands.py" --manifest <json> --out <md>

Rules#

Operate on the repo path the user named, not on arbitrary sibling directories.
Inspect the ZIP intended for upload, not only the source tree, before calling a Chrome Web Store package ready.
Prefer activeTab plus scripting after an explicit user gesture over persistent host permissions.
Do not publish when the leak scan has unresolved findings.
Do not publish a new product when a repo-local product-share gate is missing, failing, or says rework, park, or kill.
Do not publish when the target repo has a reviewer gate and it fails.
Do not publish when package/listing/privacy claims disagree with the ZIP manifest.
Do not publish when the design/UI gate is missing or any score is below 8/10.
Do not publish when a store icon, small promo tile, marquee promo tile, or portfolio thumbnail reuses another product's motif/layout/signature or exact asset bytes.
Do not publish when public SEO/canonical metadata is missing, points at a fallback domain, or contradicts the CWS listing contract.
Do not publish when local E2E was only run on an older Chrome milestone without recording the current Stable release check.
Do not publish listing copy that claims official affiliation, best-in-class status, background crawling, server sync, or broad permissions unless the shipped product and public evidence prove it.
Keep GitHub topics and ClawHub tags explicit in the generated manifest.
Use a dedicated public site base for support, privacy-policy, and reviewer-instructions links when the extension has one.
If a Chrome Web Store draft is already pending review, do not recommend canceling or replacing it unless a verified acceptance blocker exists.
Do not assume generated artifacts should be committed.