360 Secure SkillHub
360 安全技能中心

Chrome Extension Studio

该工具覆盖Chrome扩展从设计、原型、开发到发布的全流程,采用插件、模板、产品三仓库分离架构,提供本地原型、私有Beta、公开应用商店等多发布渠道。适用于需要规范开发流程、避免仓库混乱的开发者/团队,可通过配置文件定义发布规则,自动生成各类文档,完成扩展打包、验证与发布。

zack-dev-cm
zack-dev-cm
热度 23.68
最近更新 2026-05-15 18:11:47
分类:开发依赖:代码执行 / 读写文件应用场景:代码生成 / 自动化脚本 / DevOps / 工作流 ...

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add chrome-extension-studio
Metadata
name
chrome-extension-studio
description
Design, prototype, build, QA, and ship Chrome extensions across separate plugin, template, and product repos with explicit publish lanes.

Chrome Extension Studio

Use this skill when the task is to design, prototype, build, package, QA, or ship a Chrome extension and the workflow needs to stay clean across multiple repositories.

Core model

  • Plugin repo: workflow instructions, validation, and orchestration only
  • Template repo: reusable MV3 starter and release contract
  • Product repo: one extension per repo

Do not collapse those roles into one repo.

Publish lanes

  • prototype-local
  • beta-private
  • cws-public
  • source-release

Every product repo must declare exactly one lane in extension.release.json. Every product repo should keep structured design metadata in extension.release.json as the source of truth for the brief. Every product repo should also keep docs/release-plan.md generated from that profile. Every product repo should keep docs/extension-brief.md product-specific, not as a generic template. Every product repo should keep docs/store-listing.md generated from structured listing metadata in the profile.

Required files in each product repo

  • extension.release.json
  • docs/extension-brief.md
  • docs/store-listing.md
  • docs/qa-checklist.md
  • docs/release-plan.md

Workflow

  1. Confirm the target product repo and its current publish lane.
  2. If the repo does not exist yet, create it from the separate template repo:
python3 ../../scripts/create_product_repo.py "My Extension" --publish-type prototype-local --git-init
  1. Write or update the product brief before changing code.
  2. Keep permissions, host matches, and store copy intentionally narrow.
  3. Build the extension package inside the product repo, not inside the plugin repo.
  4. Regenerate docs/store-listing.md and docs/release-plan.md after release-profile changes.
  5. Run the local release cycle before recommending any ship step.
  6. Validate the release contract before recommending any ship step.

Validation

Run the validator from the plugin repo against the product repo profile:

python3 ../../scripts/validate_release_profile.py /path/to/product-repo/extension.release.json

Generate or refresh the release plan:

python3 ../../scripts/generate_release_plan.py /path/to/product-repo/extension.release.json

Generate or refresh the store-listing draft:

python3 ../../scripts/generate_store_listing.py /path/to/product-repo/extension.release.json

Generate or refresh the design brief:

python3 ../../scripts/generate_design_brief.py /path/to/product-repo/extension.release.json

Run the local release-preparation cycle:

python3 ../../scripts/execute_release_cycle.py /path/to/product-repo/extension.release.json

Guardrails

  • Do not publish a local prototype through the public lane.
  • Do not store Chrome Web Store metadata only in chat; keep it in repo docs.
  • Do not reuse one product repo for multiple unrelated extensions.
  • Do not change publish type silently; update extension.release.json first.