Skill: zack-dev-cm/chrome-extension-studio (version 1.0.0)

--- 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: ```bash python3 ../../scripts/create_product_repo.py "My Extension" --publish-type prototype-local --git-init ``` 3. Write or update the product brief before changing code. 4. Keep permissions, host matches, and store copy intentionally narrow. 5. Build the extension package inside the product repo, not inside the plugin repo. 6. Regenerate `docs/store-listing.md` and `docs/release-plan.md` after release-profile changes. 7. Run the local release cycle before recommending any ship step. 8. Validate the release contract before recommending any ship step. ## Validation Run the validator from the plugin repo against the product repo profile: ```bash python3 ../../scripts/validate_release_profile.py /path/to/product-repo/extension.release.json ``` Generate or refresh the release plan: ```bash python3 ../../scripts/generate_release_plan.py /path/to/product-repo/extension.release.json ``` Generate or refresh the store-listing draft: ```bash python3 ../../scripts/generate_store_listing.py /path/to/product-repo/extension.release.json ``` Generate or refresh the design brief: ```bash python3 ../../scripts/generate_design_brief.py /path/to/product-repo/extension.release.json ``` Run the local release-preparation cycle: ```bash 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.

path: agents/openai.yaml
content: interface:
  display_name: "Chrome Extension Studio"
  short_description: "Build and ship lane-specific extensions"
  default_prompt: "Use $chrome-extension-studio to design, prototype, validate, package, and prepare a Chrome extension while keeping plugin, template, and product repositories in their separate publish lanes."


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)