agentleFS
Sign inStart free
ForgeyClapForgeyClap/Forge-Core/.claude/skills/forge-extension/SKILL.md

forge-extension

Skill2 starsChanged 6 days agoMITView on GitHub

Playbook for MV3 browser extensions: permissions, CSP (gebruik bij een extensie).

1 other project uses a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use for: Chrome/Edge Manifest V3 browser extensions: permissions, messaging, CSP, service worker, store policy.

    line 11
  2. Very specific:

    Not for: Firefox/Safari ports (separate, only on request).

    line 12
  3. Very specific:

    No remotely-hosted code — no eval/new Function/remote <script>.

    line 38
  4. Very specific:

    Default MV3 CSP kept strict (script-src 'self', no unsafe-eval/unsafe-inline).

    line 40
  5. Very specific:

    No secrets in the package.

    line 42

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Forge playbook — Browser extension (Chrome MV3)

When to use

  • Use for: Chrome/Edge Manifest V3 browser extensions: permissions, messaging, CSP, service worker, store policy.
  • Not for: Firefox/Safari ports (separate, only on request); popup/options UI defers to forge-website, backend calls to forge-integration.
  • Domain framing, team roles and honesty rule: references/overview.md.

Hard rules (non-negotiable)

  • Least-privilege permissions.
  • No remotely-hosted code (MV3 policy).
  • Safe content-script + messaging.
  • Strict CSP kept strict.
  • Termination-resilient service worker.
  • No secrets in the package; store-policy compliance.

Full text of every rule: references/hard-rules.md.

Team (conditional by stack/level)

Lead: build-boss. Security: security-boss (permission surface, CSP, message validation, no-remote-code — the defining risk of this domain). Support: typescript-reviewer (background/content/messaging code), test-boss (load the unpacked extension in Playwright/Puppeteer for E2E), ui-boss (popup/options UI via forge-website). Backend calls: forge-integration team.

Skills / commands / MCP

Skills, commands, MCP and opt-in dependencies: references/team-and-tools.md.

Fan-out & flow

L2 a single-purpose extension (popup + one content script); L3 a service worker + multiple content scripts + options page + messaging + a backend. Serial: manifest + permission model → service worker + messaging contract → content scripts → popup/options UI → CSP + security review → load-unpacked E2E → production zip. Parallel: content script ∥ popup/options UI ∥ background logic build in parallel once the message contract is fixed (the message schema is the seam).

Domain gates

  • Manifest requests only permissions/host_permissions the code uses; activeTab/optional preferred over <all_urls> (each justified).
  • No remotely-hosted code — no eval/new Function/remote <script>; all JS bundled.
  • Runtime + content-script messages validate sender + payload; page-supplied data is never eval'd; externally_connectable and web_accessible_resources scoped to specific matches.
  • Default MV3 CSP kept strict (script-src 'self', no unsafe-eval/unsafe-inline).
  • Service worker is event-driven and termination-resilient — listeners at top level, durable state in chrome.storage, no global-state reliance.
  • No secrets in the package; OAuth via chrome.identity with minimal scopes.
  • Extension loads unpacked and the core flow works (evidence: load + a screenshot/log), and a production zip is produced.

Ship-readiness (unique)

Evidence checklist before handoff: references/ship-readiness.md.

Safety, approval and honesty

  • Approval / safety: no API secret in the package; real secrets sit behind a backend.
  • Approval / safety: store submission needs a developer account and is owner-gated.
  • Honest failure: "loads unpacked" counts only with the core flow actually exercised; every permission must be one the code uses.
  • Honest failure: if security-boss / codex-reviewer did not run, say so.
  • Shared gates for every playbook (honesty, owner approval, secrets, reviews): .claude/docs/forge-reference/playbook-template.md.

References

  • references/overview.md — domain framing paragraph(s) from under the title.
  • references/hard-rules.md — full text of every hard rule.
  • references/team-and-tools.md — full team roster, skills, commands, MCP and opt-in runtimes.
  • references/ship-readiness.md — full ship-readiness evidence checklist.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free