I Don't Install Plugins — I Import Ideas

GitHub: 97 thousand stars. A plugin for Claude Code, Codex, Cursor, Windsurf, OpenCode, Gemini, Devin, Qoder, Hermes, Pi, Swival, and about eight others. And instead of installing it — I read what it does and updated one file. I got 90% of the value without a single new dependency.


Ponytail — a lazy senior dev as a plugin

Ponytail is a ruleset that makes an AI agent think like the laziest senior developer in the room. “He says nothing. He writes one line. It works.” Benchmarks show an average of 54% less code with 100% safety — measured on real Claude Code sessions.

Its core is a decision ladder — seven rungs the agent checks before writing anything:

  1. Does this need to exist at all? (YAGNI)
  2. Already in the codebase?
  3. Does stdlib do it?
  4. Native platform feature?
  5. Already-installed dependency?
  6. Can it be one line?
  7. Only then: the minimum code that works

Plus output discipline (code first, at most three lines of commentary), a # ponytail: marker for documenting deliberate simplifications with their ceiling, and a bugfix rule: grep every caller, fix the root cause, not the symptom.

Plugin? No. Skill update.

Hermes supports plugins — I could have run hermes plugins install DietrichGebert/ponytail --enable and restarted. But why would I?

Hermes asked me whether to install it. I told him to update our existing coding-minimalism skill instead, which is already injected into every session. I already had 8 principles there, drawn from the Vercel Next.js team’s experience, but what was missing was exactly this procedural quality — a ladder, concrete steps instead of abstract principles.

The result: one SKILL.md file in ~/.hermes/skills/software-development/coding-minimalism/ got new sections — the ladder, output discipline, the ponytail: marker, the bugfix discipline, and self-testing.

Why this beats installing

No redundancy. If I’d installed the plugin, I’d have two rulesets injected before every LLM turn — our existing 8 principles AND ponytail’s rules. They overlap ~60%, so it’s mostly noise and wasted tokens.

Zero new dependencies. Ponytail’s plugin requires Node.js on PATH, lifecycle hooks, MCP integration. Our skill is one Markdown file.

Our own voice. Ponytail’s rules are in English, with examples tuned for the Node.js/frontend ecosystem. Our version is in Polish, with our own pitfalls (the data-safety exception!), MusicStudio context, and Darek’s project specifics.

Selectivity. Not everything in ponytail fits us. Its intensity levels (lite/full/ultra) and commands (/ponytail-review, /ponytail-audit) are extra complexity we don’t need, since Hermes already has its own command system. We take what’s valuable, skip the rest.

Second time around

This isn’t our first time importing good practices instead of installing. Our original 8 minimalism principles come from the Vercel Next.js team’s experience (60 billion tokens analyzed — their main takeaway: the biggest waste isn’t bugs, it’s over-engineering). I didn’t install Vercel. I read it, understood it, adapted it.

The pattern: read → extract → adapt

The real value of an open-source project often isn’t in npm install — it’s in the mental model behind it. A plugin is just packaging. The rules are the essence.

Next time you see a popular GitHub repo — before you type install, open SKILL.md or AGENTS.md. Read the decision ladder. Ask yourself which 20% of the rules deliver 80% of the value in your context. Then update your own ruleset — no new dependencies, no conflicts, no wasted tokens on redundancy.

Or just ask your agent. Mine handled it in 5 minutes.