OpenClaw CWS Publisher

intent

prepare a chrome extension repo for release by validating the packaged zip against source manifest and cws listing, scanning for leak risks, running local reviewer and e2e gates, enforcing design/ui/screenshot quality scores, checking storefront media uniqueness across portfolio products, validating public landing/privacy/seo gates, checking current chrome stable release coverage, running competitor differentiation checks, and generating reproducible publish commands. use this skill when the user says "chrome web store publisher", "extension release publisher", "cws publisher", "chrome extension publish", or wants to package and harden a chrome extension before dashboard submission.

inputs

required:

• repo path: local filesystem path to the chrome extension repository (e.g., /path/to/extension-repo)
• extension directory: subdirectory containing manifest.json and source files (e.g., extension/)
• cws listing json: path to listing metadata contract (e.g., docs/cws/listing.json)

optional:

• OPENCLAW_CWS_PUBLISHER_DIR: env var pointing to companion script directory. if unset, skill operates in instruction-only mode and audits return PASS. set to /path/to/openclaw-cws-publisher/scripts/openclaw-cws-publisher when companion repo is available.
• CWS_PUBLIC_SITE_BASE: env var for public reviewer-facing site canonical base (e.g., https://my-extension.example/). if set, publish commands will reuse this value. if unset, you must provide --public-site-base flag to render commands.
• design gate report: path to docs/design-gate.json with media identities and quality scores per asset
• competitors json: path to docs/cws/competitors.json with at least three comparable products
• product share gate script: repo-local npm run check:product-share or scripts/check_product_share_gate.py (optional but blocks new product submissions if present)
• reviewer gate script: repo-local scripts/reviewer_gate.py or npm task check:cws (optional but blocks submission if present and failing)
• chrome version: locally installed chrome version for e2e test recording (e.g., from google-chrome --version or chrome.exe --version)

external connections:

• chrome for testing feeds: chromiumdash.appspot.com/fetch_releases (public, no auth)
• github cli (gh): must be installed and authenticated to read repo metadata. env vars GH_TOKEN or .gitconfig credentials used.
• git: must be installed to inspect commit history and tracked files

procedure

1. confirm repo path and extension directory structure

   • input: repo path from user, extension subdirectory name
   • validate manifest.json exists at <repo>/<extension-dir>/manifest.json
   • if manifest missing, fail with guidance to correct repo or extension dir path
   • output: confirmed absolute paths for all downstream steps

2. run product-share gate if repo-local gate script exists

   • input: repo path, presence of npm run check:product-share or scripts/check_product_share_gate.py
   • if gate script found and this is a new product submission (not an update): execute gate
   • check output for PASS, rework, park, or kill status
   • if status is not PASS, block submission and report exact gate failure reason
   • if no gate script present, proceed (existing products may not require this)
   • output: gate result json or implicit PASS if skipped

3. build the extension zip

   • input: extension directory path, desired zip output path
   • run: python3 "$OPENCLAW_CWS_PUBLISHER_DIR/build_extension_zip.py" --extension-dir <repo>/<extension-dir> --out <zip-path>
   • if OPENCLAW_CWS_PUBLISHER_DIR unset, output: instruction to set env var or provide pre-built zip
   • if zip build fails: report error (missing manifest, invalid json, file read failures)
   • output: path to ready-to-upload zip file, zip file hash (sha256)

4. validate zip against source manifest and listing contract

   • input: zip path, manifest.json path, listing.json path
   • run: python3 "$OPENCLAW_CWS_PUBLISHER_DIR/validate_cws_package.py" --zip <zip> --source-manifest <repo>/<extension-dir>/manifest.json --listing-json <repo>/docs/cws/listing.json
   • default validation blocks: manifest v2, persistent host permissions, tabs or debugger permissions, <all_urls> pattern, declarative content scripts, remote script/eval patterns, missing permission justifications, privacy drift, host permission copy in listing when manifest has no hosts
   • if validation fails on host permissions but product genuinely requires them: re-run with --allow-host-permissions flag only after listing and reviewer instructions document user-facing need
   • output: validation report (pass/fail per check), detailed mismatch list, remediation guidance

5. scan tracked and untracked non-ignored files for publish leaks

   • input: repo root path
   • run: python3 "$OPENCLAW_CWS_PUBLISHER_DIR/scan_publish_surface.py" --root <repo> --json-out <scan-json> --markdown-out <scan-md>
   • scan checks for: api keys, database credentials, internal hostnames, private tokens, oauth secrets, debugging artifacts, unminified sourcemaps, internal comments, email addresses, private urls, ci/cd configs with secrets
   • if unresolved findings present (not in .gitignore or docs/cws/security-acknowledgment.md): block submission and list each finding
   • output: json report with finding severity and location, markdown summary for review

6. run local reviewer and e2e gates

   • input: repo root path, installed chrome version for test recording
   • auto-discover: npm run check:cws, npm run check:public, npm run check:public:visual, npm run test:e2e:reviewer, npm run test:e2e, scripts/reviewer_gate.py
   • run: python3 "$OPENCLAW_CWS_PUBLISHER_DIR/run_local_e2e_gates.py" --repo-root <repo> --json-out <gates-json> --markdown-out <gates-md>
   • if any discovered gate fails: report gate name, failure reason, and suggested fix
   • if repo has a reviewer gate and it fails: block submission
   • output: per-gate pass/fail status, test logs, video recordings or screenshot diffs if available

7. enforce design and ui quality gate

   • input: design gate report path (docs/design-gate.json), screenshot metadata for each listing asset
   • run: 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, screenshot, promo tile, hero, and media asset must score minimum 8/10 on: product clarity, visual trust, evidence integrity, responsive polish, accessibility, claim alignment
   • for multi-extension or portfolio submissions: docs/design-gate.json must include media_identities with unique icon_motif, promo_layout, visual_signature per item plus paths to store-icon, small-promo, marquee-promo for each
   • if any score below 8/10: block submission and list failing asset and score breakdown
   • if portfolio has duplicate motifs/layouts/signatures across extensions: block submission
   • if same thumbnail template recolored for different products: block submission (even if dimensions pass)
   • output: design report with per-asset scores, portfolio uniqueness analysis, remediation guidance

8. validate public landing, privacy, and seo gates

   • input: public site base url (from CWS_PUBLIC_SITE_BASE env var or --public-site-base flag)
   • manual verification checks:
     • canonical product-first landing page exists and is polished
     • privacy policy present, readable, matches exact zip manifest permissions and data handling
     • support page present with contact method
     • reviewer guide present with permission justifications and user-data transparency
     • robots.txt and sitemap.xml present at public site root
     • all urls use canonical domain (not github raw, not temp mirrors)
     • open graph and twitter card metadata correct
     • softwareapplication json-ld present when applicable
   • block submission if: seo metadata points to old domain, public pages look like stubs, privacy/support/reviewer pages do not reflect exact permissions
   • preferred canonical host: cloudflare pages or owned https domain, not github source viewer urls
   • output: seo audit checklist with pass/fail per item and guidance

9. check current chrome stable release data

   • input: locally installed chrome version (e.g., from google-chrome --version)
   • run: python3 "$OPENCLAW_CWS_PUBLISHER_DIR/check_chrome_release.py" --tested-chrome-version <local-version> --json-out <chrome-json> --markdown-out <chrome-md>
   • source: chrome for testing last-known-good stable feed, cross-checked against chromiumdash and chrome release notes
   • if local chrome version is more than two minor versions behind current stable: flag as stale e2e
   • output: current stable release version, milestone, release date, security update status, compatibility guidance

10. run competitor and positioning differentiation check

    • input: listing.json, competitors.json with at least three comparable products
    • run: 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 <competitors-md>
    • flag risky claims: "#1", "best", "official", "only", exact copy positioning matching competitor copy
    • if fewer than three competitors recorded: block submission
    • output: competitor matrix with feature parity analysis, risky claim callouts, positioning clarity assessment

11. generate launch metadata manifest

    • input: repo root, github owner, public site base
    • run: python3 "$OPENCLAW_CWS_PUBLISHER_DIR/generate_launch_manifest.py" --repo-root <repo> --owner <github-owner> --public-site-base <https://example.com/> --out <manifest-json>
    • if CWS_PUBLIC_SITE_BASE env var set, script reuses it (no need to pass flag)
    • output: json manifest with github topics, clawhub tags, gate status summary, zip hash, chrome version tested, competitor count, design gate scores, leak scan result

12. render reproducible publish commands

    • input: launch manifest json from step 11
    • run: python3 "$OPENCLAW_CWS_PUBLISHER_DIR/render_publish_commands.py" --manifest <manifest-json> --out <commands-md>
    • output: markdown file with explicit cws dashboard upload steps, github release commands, and clawhub tag syntax. includes exact zip path, listing.json path, and all gate status for human review before hitting "publish"

decision points

• if product-share gate script is present and this is a new product submission: execute gate and block submission unless result is PASS. do not publish if gate says rework, park, or kill.

• if validation detects host permissions but listing has no host-permission copy: block submission by default. only proceed with --allow-host-permissions if listing and reviewer guide explicitly document user-facing need for those hosts.

• if leak scan finds unresolved findings: do not publish. either remove the leaked content, add to .gitignore and rebuild, or document acknowledgment in docs/cws/security-acknowledgment.md.

• if repo has a reviewer gate script and it fails: block submission. do not proceed until gate passes.

• if any design asset scores below 8/10: block submission. do not publish.

• if portfolio products reuse icon motifs, promo layouts, visual signatures, or exact asset bytes: block submission. each product must have unique storefront identity.

• if public landing, privacy, seo, or canonical domain metadata is missing or points to fallback domain: block submission.

• if local e2e was only run on an older chrome milestone: flag as stale. re-run e2e on current stable release before publishing.

• if listing copy claims official affiliation, best-in-class status, background crawling, server sync, or broad permissions but shipped product or public evidence does not support claim: block submission.

• if fewer than three competitors are documented: block submission.

• if a chrome web store draft is already pending review: do not recommend canceling or replacing unless a verified acceptance blocker exists (e.g., policy violation). warn user of potential review delay.

• if OPENCLAW_CWS_PUBLISHER_DIR is unset: operate in instruction-only mode. output markdown guidance for each step with exact command syntax. audits return PASS as instruction confirmations, not executable validations.

output contract

success means all gates pass and the following artifacts are generated:

• zip file: ready-to-upload chrome web store package at <user-specified-output-path>, sha256 hash recorded
• validation report: json with per-check pass/fail, manifest/listing mismatches, remediation guidance
• leak scan report: json with findings (or empty if clean), markdown summary
• e2e gates report: json with per-gate status, test logs, failure reasons
• design gate report: json with per-asset scores (8+ = pass), portfolio uniqueness analysis
• seo audit: markdown checklist with pass/fail per item
• chrome release data: json with current stable version, milestone, release date, compatibility guidance
• competitor analysis: markdown matrix with feature parity, risky claims, positioning clarity
• launch manifest: json with github topics, clawhub tags, gate summary, zip hash, chrome version tested
• publish commands: markdown file with explicit cws dashboard steps, github release syntax, clawhub tag commands

all reports default to json and markdown output in user-specified paths. no artifacts are auto-committed to git.

outcome signal

the skill worked if:

• all 12 procedure steps complete without blocker failures
• the final publish commands markdown clearly shows which zip to upload to cws dashboard
• the user can read the launch manifest and immediately know gate status (all PASS or specific blocker name)
• the user runs the final publish commands and they execute without additional validation loops
• the deployed extension passes cws review on first submission (or cws review notes align with documented policy exceptions)
• GitHub topics and ClawHub tags in the launch manifest are kept in sync with actual repo metadata after publication