frontend-tooling-trust-gate git:20260905.f7824baA

Immutable. This exact content is served forever at /api/v1/blob/e4ba9fea0c6b2089.

---
name: frontend-tooling-trust-gate
description: "Review trust before frontend tooling adoption."
---

# 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

1. Prefer official sources, verified orgs, and vendor-maintained repos.
2. Inspect README specificity, license, SECURITY.md, recent commits, releases, issues, and package registry links.
3. Inspect `package.json`, scripts, dependencies, and install instructions.
4. Use `npm view <package> repository license version time maintainers` when npm metadata matters.
5. Look for preinstall/postinstall scripts, broad permissions, telemetry, token requests, cookie access, or curl-to-shell commands.
6. Prefer project-local installs for frontend tools and libraries.
7. Avoid global installs unless the tool is an agent-wide CLI and the user explicitly approves it.
8. 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.