360 Secure SkillHub
360 安全技能中心

Chrome Extension Studio

该 Skill 规定 Chrome 扩展在插件仓库、模板仓库与产品仓库间的分工,定义四种发布通道,并提供创建产品仓库、生成设计简报、商店文案与发布计划、执行本地发布准备及校验发布配置的脚本调用流程。

zack-dev-cm
zack-dev-cm
热度 23.67
最近更新 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.