Frontend Tooling Trust Gate
Use this skill before installing or recommending a repo, package, MCP, plugin, template, or script.
Trust Classes
preferred: official or clearly reputable.acceptable: useful, maintained, and reasonably transparent.inspect manually: promising but insufficiently verified.avoid: suspicious, stale, unsafe, or low-quality.unknown risk: not enough evidence.
Inspection Checklist
- Prefer official sources, verified orgs, and vendor-maintained repos.
- Inspect README specificity, license, SECURITY.md, recent commits, releases, issues, and package registry links.
- Inspect
package.json, scripts, dependencies, and install instructions.
- Use
npm view <package> repository license version time maintainers when npm metadata matters.
- Look for preinstall/postinstall scripts, broad permissions, telemetry, token requests, cookie access, or curl-to-shell commands.
- Prefer project-local installs for frontend tools and libraries.
- Avoid global installs unless the tool is an agent-wide CLI and the user explicitly approves it.
- Never expose API keys, browser cookies, SSH keys, tokens, or private files to unknown tools.
Decision Output
Return:
- source and type
- trust class
- evidence
- red flags
- install stance:
install, project-local only, do not install, or needs user auth
- safer official alternative if rejected
Scope and evidence
Apply to frontend tooling adoption only. Reuse recent verified adoption decisions if no relevant version, source, permission or requirement changed. Stale maintenance is a factor, not proof of malice. Existing authorization covers routine approved installs; spending and external commitments keep their actual boundaries.
1---2name: frontend-tooling-trust-gate3description: Review trust before frontend tooling adoption.4---56# Frontend Tooling Trust Gate78Use this skill before installing or recommending a repo, package, MCP, plugin, template, or script.910## Trust Classes1112- `preferred`: official or clearly reputable.13- `acceptable`: useful, maintained, and reasonably transparent.14- `inspect manually`: promising but insufficiently verified.15- `avoid`: suspicious, stale, unsafe, or low-quality.16- `unknown risk`: not enough evidence.1718## Inspection Checklist19201. Prefer official sources, verified orgs, and vendor-maintained repos.212. Inspect README specificity, license, SECURITY.md, recent commits, releases, issues, and package registry links.223. Inspect `package.json`, scripts, dependencies, and install instructions.234. Use `npm view <package> repository license version time maintainers` when npm metadata matters.245. Look for preinstall/postinstall scripts, broad permissions, telemetry, token requests, cookie access, or curl-to-shell commands.256. Prefer project-local installs for frontend tools and libraries.267. Avoid global installs unless the tool is an agent-wide CLI and the user explicitly approves it.278. Never expose API keys, browser cookies, SSH keys, tokens, or private files to unknown tools.2829## Decision Output3031Return:3233- source and type34- trust class35- evidence36- red flags37- install stance: `install`, `project-local only`, `do not install`, or `needs user auth`38- safer official alternative if rejected3940## Scope and evidence4142Apply to frontend tooling adoption only. Reuse recent verified adoption decisions if no relevant version, source, permission or requirement changed. Stale maintenance is a factor, not proof of malice. Existing authorization covers routine approved installs; spending and external commitments keep their actual boundaries.
TheGoat395