Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add sutchan/Agent-Skills-Hub --skill chrome-webstore-release-blueprintgit clone --depth 1 https://github.com/sutchan/Agent-Skills-HubWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/sutchan/agent-skills-hub/chrome-webstore-release-blueprint)<a href="https://agentmods.dev/skills/sutchan/agent-skills-hub/chrome-webstore-release-blueprint"><img src="https://agentmods.dev/badge/skills/sutchan/agent-skills-hub/chrome-webstore-release-blueprint/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/sutchan/agent-skills-hub/chrome-webstore-release-blueprint"><img src="https://agentmods.dev/badge/skills/sutchan/agent-skills-hub/chrome-webstore-release-blueprint.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00062 | $0.02072 |
| Opus 5 | $0.00031 | $0.01036 |
| Sonnet 5 | $0.00012 | $0.00414 |
| Haiku 4.5 | $0.00006 | $0.00207 |
Grade A, and why
chrome-webstore-release-blueprint scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
97% identical to chrome-webstore-release-blueprint — 7 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 267 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Chrome Web Store Release Blueprint
Use this skill as a hands-on setup guide. The agent should lead the user step-by-step, ask for confirmations, and only automate the parts that can be done locally/in CI.
What This Skill Is For
- Helping a user set up Chrome Web Store release automation from scratch.
- Giving clear manual instructions for Google/CWS dashboard steps.
- Implementing repo-side scripts/workflows after the user provides credentials.
- Verifying submission state (
PUBLISHED,PENDING_REVIEW, etc.).
Agent Behavior Rules
- Treat dashboard/OAuth tasks as user-driven; do not imply you performed them.
- Give one clear step at a time and wait for confirmation before moving on.
- Ask for exact values only when needed, and tell user where each value comes from.
- Mask secrets in logs and never commit secret values to git.
- If
ghis available, offer secret upload automation; if not, provide manual fallback.
Step 1: Project Discovery (Before Any Credential Work)
Collect these inputs:
- manifest path containing extension version
- build command
- zip/package command and output file name/path
- CI platform (GitHub Actions by default)
- release branch policy (
main, tags, or manual dispatch) - local secret file convention (
.env,.env.local, etc.)
Ask explicitly:
- "Do you want CI to publish only when version changes?"
- "Do you want me to wire GitHub secret upload via
gh?"
Step 2: Detailed Credential Walkthrough (User + Agent)
2.1 Enable API in Google Cloud
Tell user to open:
https://console.cloud.google.com/apis/library/chromewebstore.googleapis.com
User actions:
- Select the intended Google Cloud project.
- Click
Enablefor Chrome Web Store API.
Agent prompt example:
- "When Chrome Web Store API shows as Enabled, tell me and I will move to OAuth setup."
2.2 Configure OAuth Consent Screen
Tell user to open one of:
https://console.cloud.google.com/apis/credentials/consent- If UI redirects, continue in Google Auth Platform consent screen pages.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 267 lines · 62 tokens per session scan A d76e325b909f
chrome-webstore-release-blueprint is a skill published in the GitHub repository sutchan/Agent-Skills-Hub (2 stars, last pushed yesterday), licensed MIT. It adds 62 tokens to every session and 2,072 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 97% identical to chrome-webstore-release-blueprint, differing in 7 lines, and is treated as a copy.
Other skills, from other repositories
git-workflow-and-versioning
Guides git commit discipline, trunk-based branching, and semantic versioning/changelogs for released code, including Go modules' major-version import path rule. Use when committing, branching, resolving conflicts, cutting a release, choosing a semantic version bump, tagging a release, or writing a changelog entry.
bump-version
Automate version bumping following semantic versioning and changelog management. Use when the user wants to bump a version, create a release, update the changelog, or tag a new version in a project using semver conventions and Keep a Changelog format.
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple…
comet-archive
A workflow for the fifth stage of Comet Classic: archiving a completed change, merging its specification updates, and finishing the branch. It uses Comet commands and a fixed layout for tracking the change.
skillshare-changelog
Generate CHANGELOG.md entry from recent commits in conventional format. Also syncs the website changelog page. Use this skill whenever the user asks to: generate a changelog, document what changed between tags, or create a new CHANGELOG entry. If you see requests like "write the changelog for v0.17", "what changed…
comet-safe-delivery
A Chinese-language procedure for safely delivering specified Comet changes through Git. It covers checking worktrees and unrelated edits, staging exact files, validating hooks, and authorized commits or pushes.