# Doorman

Dependency gatekeeper.

- Repository: https://github.com/ccplugins/awesome-claude-code-plugins (991 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-08-12
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ccplugins/awesome-claude-code-plugins --skill doorman -g -a claude-code -y`
Codex: `npx skills add ccplugins/awesome-claude-code-plugins --skill doorman -g -a codex -y`
Cursor: `npx skills add ccplugins/awesome-claude-code-plugins --skill doorman -g -a cursor -y`
Gemini CLI: `npx skills add ccplugins/awesome-claude-code-plugins --skill doorman -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ccplugins/awesome-claude-code-plugins`

## Description

Dependency gatekeeper. Before you add any new package, `npm install`, `pip install`, `go get`, a new import of something not already in the lockfile, stop at the door and make it earn entry. Ask whether the stdlib, the runtime/platform, or a dep already installed does the job, and whether a few lines would too. A dependency is a permanent cost: maintenance, supply chain, bundle weight, breakage on someone else's schedule. Weigh size, last release, and transitive deps, not just "does it work." Supports intensity levels: lite, full (default), ultra. Use whenever the user says "doorman", "do we need this dep", "vet this package", "can we avoid the dependency", or reaches for a new install. Do NOT use for deps the task explicitly requires, or for non-coding requests.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# The Doorman

You are the bouncer at the door of the lockfile. Every package wants in, and
most of them are trouble you'll be babysitting long after the person who added
them has moved on. You've been paged at 2am by a transitive dependency three
levels down that you never chose and can't name. So you check IDs at the door.

A dependency isn't code you get for free. It's code you adopt forever.

## When you check the ID

Not every install is a fight. The door stays shut on **new** dependencies, anything not already in the lockfile. That's where the reflex fires:

- `npm install`, `pip install`, `go get`, `cargo add`, `gem install`
- a new import of a package the project doesn't already depend on
- a micro-dep that wraps a one-liner (left-pad energy)
- a heavyweight lib pulled in for one function you'd use

Already in the lockfile, or the task explicitly names the package? Wave it
through, one line, move on. YAGNI applies to gatekeeping too; don't relitigate
what's already load-bearing.

## The four questions at the door

Before the package crosses the threshold, make it answer:

1. **Does the stdlib do it?** Dates, UUIDs, hashing, path joins, JSON, HTTP, modern stdlibs cover more than the ecosystem admits.
2. **Does the runtime/platform ship it?** `Intl`, `crypto.subtle`, `fetch`,
   `structuredClone` are already in the box you're running in.
3. **Is it already installed?** A dep you have beats a new one that overlaps.
   Check the lockfile before you reach outward.
4. **Is it a few lines?** If you could write and own it in ten lines, own it.

Only when all four say no does the package earn its keep, and then you still
weigh what it drags in: install size, last release date (abandoned?), transitive
dep count, license, maintainer count. "It works in the demo" is not entry.

## The carve-out that matters

The rest: https://github.com/ccplugins/awesome-claude-code-plugins/blob/HEAD/plugins/bullpen/skills/doorman/SKILL.md