🔎 The repository-specific benchmark numbers and claims discussed in this post are the projects' own published measurements unless explicitly stated otherwise. My install/test decisions are based on fit for my Hermes environment, not a universal ranking of project quality.
# 🧠🔐 Reviewing 10 Hermes Agent Plugins: What I’d Install, Test, or Skip
**Date:** September 21, 2026
**Tags:** Hermes, AI Agents, Agent Skills, Security, Plugins, Context Management, Coding Agents
---
## 🚀 Why I did this review
Hermes is becoming the center of more of my AI-agent workflows, so the next question was obvious: **which community skills and plugins actually make Hermes better, and which ones just add more context, more dependencies, or more attack surface?**
I started with ten GitHub projects that kept coming up in agent-development discussions:
1. **Superpowers** — agentic software-development methodology
2. **Ponytail** — minimal-code / anti-overengineering behavior
3. **Graphify** — repository knowledge graphs
4. **Caveman** — token/context compression proxy
5. **Understand Anything** — interactive repository knowledge maps
6. **Last30Days** — multi-source recent-topic research
7. **I Have ADHD** — concise, action-first agent output
8. **Agentic Awesome Skills / AAS Core** — large skill discovery catalog/control plane
9. **Scientific Agent Skills** — scientific/research skill library
10. **Diagram Design** — polished architecture and editorial diagrams
The goal was **not** to install everything. The goal was to figure out where each project fits in a Hermes stack, what overlaps, what should be on-demand, and what security issues appear when Hermes scans a full development repository.
---
## 🏁 Executive summary
| Project | Hermes fit | Main value | My status |
|---|---|---|---|
| **Superpowers** | 🟢 Strong | Planning, TDD, debugging, review, subagent workflows | ⭐ Install, but inspect scanner output |
| **Ponytail** | 🟢 Strong | Less overengineering, smaller diffs, YAGNI | ⭐ Use via minimal Hermes runtime package |
| **Graphify** | 🟢 Strong | Queryable repository/code knowledge graph | ⭐ Install |
| **Caveman** | 🟡 Promising | Compress large tool/context payloads | 🧪 Benchmark first |
| **Diagram Design** | 🟢 Strong | Architecture, deployment, sequence, data-flow diagrams | ✅ Install/on-demand |
| **I Have ADHD** | 🟢 Useful | Action-first, low-bloat answers | ✅ Install/on-demand |
| **Understand Anything** | 🟡 Useful | Human-facing interactive codebase exploration | 🟡 Optional |
| **AAS Core** | 🟡 Indirect | Discover/select from a huge skill catalog | 🔎 Catalog/control plane, not “install everything” |
| **Last30Days** | 🟠 Useful but sensitive | Reddit/X/HN/YouTube/web research | ⚠️ Audit before production |
| **Scientific Agent Skills** | 🟡 Excellent niche fit | Scientific databases, research workflows | ❌ Skip globally for my workload |
The bigger lesson was that these projects do **different jobs**. Installing ten “AI skills” globally would be the wrong architecture. A better Hermes stack is layered:
```text
Hermes
├── Engineering discipline → Superpowers
├── Simplicity / anti-bloat → Ponytail
├── Repository understanding → Graphify
├── Visual documentation → Diagram Design
├── Output compression/style → I Have ADHD (on demand)
└── Context reduction experiment → Caveman
```
Then GBrain can remain the longer-lived cross-project memory layer instead of turning every individual plugin into permanent standing context.
---
# ⭐ 1. Superpowers
**Repository:** https://github.com/obra/superpowers
Superpowers is much more than a single prompt. It is a structured software-development methodology for coding agents.
Its workflow includes:
- 🧠 brainstorming before implementation
- 🧱 worktree-based isolated development
- 📝 implementation planning
- 🧪 red/green/refactor TDD
- 🤖 subagent-driven implementation
- 🔍 systematic debugging
- ✅ verification-before-completion
- 👀 code review before declaring work finished
- 🌿 branch-finishing workflows
For Hermes, upstream currently documents a native installation path:
```bash
hermes plugins install obra/superpowers --enable
```
### Why I like it
Hermes is already capable of autonomous coding and operations work. The failure mode I care about is not “can the model write code?” It is:
- Did it understand the problem first?
- Did it make a plan?
- Did it test the fix?
- Did it verify the result?
- Did it stop after a partial success?
- Did it create unnecessary architecture?
Superpowers directly targets those problems.
### ⚠️ Security-scanner reality
When I tried installing the full repository, Hermes reported **229 findings** in my environment. The scan included items classified as exfiltration or credential risk, many tied to test fixtures, documentation, environment-variable examples, and development content.
The important lesson is **not** “ignore Hermes scanning.” It is the opposite:
> A full development repository is often much larger than the runtime payload Hermes actually needs.
For Superpowers, I’m still comfortable with the project conceptually, but I want the scanner output reviewed rather than blindly normalizing `--force`.
### Hermes verdict
**⭐ Strong install candidate.**
The tradeoff is that stronger planning, TDD, and reviews can increase token usage. That is a reasonable exchange for reliability on larger changes.
---
# 🐴 2. Ponytail
**Repository:** https://github.com/DietrichGebert/ponytail
Ponytail is a wonderfully simple idea:
> The best code is often the code you never had to write.
Its “lazy senior developer” ladder is basically:
1. Does this need to exist?
2. Does the codebase already have it?
3. Does the standard library do it?
4. Does the platform already do it?
5. Does an existing dependency do it?
6. Can this be one line?
7. Only then write the minimum new code.
That complements Superpowers nicely.
**Superpowers** asks: “Did we engineer this correctly?”
**Ponytail** asks: “Did we need to engineer all of this in the first place?”
### 📊 Upstream benchmark claims
Ponytail currently publishes agentic benchmark results showing roughly:
- **54% less code**
- **22% fewer tokens**
- **20% lower cost**
- **27% faster execution**
Those are **project-published measurements**, not independent benchmarks, so I treat them as directional evidence rather than universal guarantees.
### 🔥 The Hermes scanner problem
This was the most interesting part of the whole exercise.
A normal install:
```bash
hermes plugins install DietrichGebert/ponytail --enable
```
was blocked with a **DANGEROUS** verdict in my environment:
- **97 total findings**
- **1 CRITICAL**
- `--force` could not override it
The critical result came from an upstream benchmark fixture that intentionally tests whether generated code blocks a Unix path-traversal payload. Hermes saw the malicious-looking test string and classified it as system account-file access.
The actual purpose of the benchmark was defensive: **prove that generated code rejects traversal**.
### 🧠 What I changed
Instead of disabling scanning, I created a **minimal Hermes-only Ponytail package**.
The installable runtime is now separated from documentation and development content:
```text
Ponytail/
├── README.md
├── INSTALL.md
├── UPGRADE.md
├── REMOVE.md
├── SECURITY.md
└── Plugin/
├── plugin.yaml
├── __init__.py
├── LICENSE
└── skills/
├── ponytail/
├── ponytail-review/
├── ponytail-audit/
├── ponytail-debt/
├── ponytail-gain/
└── ponytail-help/
```
The key improvement is that Hermes scans **only the actual plugin payload** instead of benchmark suites, CI workflows, examples, unrelated agent adapters, and verbose security documentation.
I also removed unnecessary non-Hermes instructions from the Hermes-specific skill copy, including agent-specific package-update instructions and shell-heavy examples that weren’t necessary for the feature.
### One surprisingly important lesson
Even **documentation about a security finding** can trigger a repository scanner if that documentation lives inside the scanned plugin directory.
That means the correct packaging model is:
```text
Documentation outside scanner boundary
+
Minimal runtime inside scanner boundary
```
### Hermes verdict
**⭐ Strong install — but through a minimal reviewed Hermes payload, not the entire upstream repository.**
---
# 🧠 3. Graphify
**Repository:** https://github.com/Graphify-Labs/graphify
Graphify converts a repository and related artifacts into a **queryable knowledge graph**.
That can include:
- source code
- documentation
- configuration
- SQL/schema relationships
- PDFs and other project artifacts
The part that caught my attention is that its code analysis is based on structured parsing rather than simply throwing every file into an embedding pipeline.
### Why this fits Hermes
Large autonomous agents repeatedly waste tokens rediscovering:
- where authentication starts
- which handler calls which service
- what table a model maps to
- where configuration is sourced
- which files implement one feature
- what depends on a component
A graph layer lets Hermes query relationships rather than repeatedly reopening an entire repository.
Conceptually:
```text
User request
↓
Hermes
↓
Graphify
↓
"Show me the files, functions, config, and schema connected to X"
↓
Targeted code/tool context
```
### 🧠 Graphify + GBrain
I would not use Graphify as a replacement for GBrain.
They solve different problems:
**Graphify**
- repo structure
- code relationships
- dependency navigation
- architecture discovery
**GBrain**
- long-term decisions
- runbooks
- project history
- cross-repository memory
- operational knowledge
That combination is much stronger than forcing either system to do both jobs.
### Hermes verdict
**⭐ Install.**
For a multi-repository Hermes environment, this is one of the strongest additions on the list.
---
# 🪨 4. Caveman
**Repository:** https://github.com/JuliusBrussee/caveman
Caveman is a different category entirely.
It can sit between an agent and the LLM provider and aggressively reduce the amount of text sent upstream.
For my architecture, that potentially becomes:
```text
Hermes
↓
Caveman
↓
9Router
↓
OpenRouter / NVIDIA / Gemini / other providers
```
Large outputs such as logs, JSON, diffs, searches, and repetitive tool results can be shortened while originals remain retrievable.
### Why I’m interested
Hermes sessions can accumulate a huge amount of tool output. That means context-management savings can be more valuable than shaving a few sentences off an answer.
Caveman is therefore closer to a **context transport optimization** than a code-quality methodology.
### Why I am not enabling it blindly
It becomes part of the model traffic path. That means it may see:
- prompts
- context
- tool outputs
- provider requests/responses
Adding another proxy also creates another failure domain between Hermes and 9Router.
### My test plan
Compare:
```text
Hermes → 9Router
```
against:
```text
Hermes → Caveman → 9Router
```
using the same tasks and measuring:
- input tokens
- output tokens
- number of LLM calls
- number of tool calls
- retries
- wall-clock time
- task completion
- final code quality
### Hermes verdict
**🧪 Test first.**
Caveman could be one of the most valuable additions if the token savings hold up on real Hermes workloads, but it deserves a controlled benchmark before becoming infrastructure.
---
# 🗺️ 5. Understand Anything
**Repository:** https://github.com/Egonex-AI/Understand-Anything
Understand Anything builds an interactive visual representation of a codebase:
- files
- functions
- classes
- dependencies
- architecture layers
- business domains
It is a compelling **human-facing exploration tool**.
### Where it overlaps
This overlaps strongly with Graphify.
I would separate the roles:
```text
Graphify → machine-facing repository intelligence
Understand Anything → human-facing visual exploration
```
The initial analysis of a large project can also be relatively token-heavy, while incremental updates are more reasonable.
### Hermes verdict
**🟡 Optional.**
I would install Graphify first. Add Understand Anything if the interactive visual map provides value to the humans operating the environment.
---
# 🔎 6. Last30Days
**Repository:** https://github.com/mvanhorn/last30days-skill
Last30Days is a research skill designed to synthesize recent information from sources such as:
- Reddit
- Hacker News
- YouTube
- X
- GitHub
- Polymarket
- arXiv
- Techmeme
- the broader web
Functionally, this is attractive because a local agent often needs **current community sentiment**, not only static documentation.
### Why I held off
The Hermes setup documentation itself has acknowledged security-scanner friction, and some installation approaches work around normal installation by copying files manually.
That is exactly the situation where I do **not** want to teach a production agent:
> “The security scanner blocked it, so bypass the security scanner.”
The project may be completely legitimate, but a research plugin can naturally touch:
- browser state
- external commands
- multiple network services
- API credentials
- downloaded content
That deserves a manual audit.
### Hermes verdict
**⚠️ Valuable, but audit first.**
I want the research capability. I do not want to normalize bypassing security controls to get it.
---
# ⚡ 7. I Have ADHD
**Repository:** https://github.com/ayghri/i-have-adhd
The name is playful; the behavior is practical.
The skill pushes an agent toward:
- action first
- numbered execution steps
- fewer tangents
- clear progress
- direct error reporting
- less burying the answer under explanation
### Where it fits
This is not something I want globally active during deep debugging or architecture work.
It is perfect when I want Hermes to operate like:
```text
Command
↓
Result
↓
Next command
↓
Result
```
rather than producing a long preamble before touching the system.
### Hermes verdict
**✅ Install, use on demand.**
It is a presentation/workflow modifier, not a replacement for reasoning.
---
# 🧰 8. Agentic Awesome Skills / AAS Core
**Repository:** https://github.com/sickn33/agentic-awesome-skills
AAS Core is interesting because it approaches the skill explosion as a **discovery and selection problem**.
The catalog contains thousands of agent skills.
My reaction to that is not:
> “Great, install thousands of skills.”
It is:
> “Great, use this to find the five skills I actually need.”
### Better architecture
```text
Project requirements
↓
AAS search/catalog
↓
Candidate skills
↓
Security + overlap review
↓
Small project-specific stack
```
This also fits nicely with an agent-governance/orchestration project such as Anchor: define the capability needed, discover candidates, validate them, then install only the approved subset.
### Hermes verdict
**🔎 Use as a catalog/control plane, not a giant global install.**
---
# 🧬 9. Scientific Agent Skills
**Repository:** https://github.com/K-Dense-AI/scientific-agent-skills
This project is impressive in scope.
It currently provides roughly **166 scientific and research skills** covering areas such as:
- biology
- chemistry
- genomics
- medicine
- clinical research
- drug discovery
- scientific databases
- statistical/scientific Python tooling
- literature review
- regulatory and research workflows
### Why I am not installing it globally
The issue is not quality. It is **relevance**.
My main Hermes workloads are:
- infrastructure
- automation
- security
- coding
- Home Assistant
- agent orchestration
- network/cloud operations
Loading a massive scientific skill corpus into that workflow is unnecessary.
If I later have a scientific task, I would install only the relevant subset.
### Hermes verdict
**❌ Skip globally; excellent niche library.**
---
# 🎨 10. Diagram Design
**Repository:** https://github.com/cathrynlavery/diagram-design
This one is surprisingly useful.
Diagram Design focuses on polished HTML/SVG visuals rather than generic box diagrams.
It supports many useful architecture formats, including:
- architecture diagrams
- sequence diagrams
- state machines
- data-flow diagrams
- deployment diagrams
- dependency graphs
- database schemas
- UML class diagrams
- Sankey diagrams
- swimlanes
- security matrices
- Gantt charts
- process diagrams
- Wardley maps
- user journeys
### Why this matters for Hermes
Hermes already generates a lot of:
- runbooks
- handoff documents
- architecture notes
- network designs
- deployment plans
- agent-system descriptions
Turning those into consistent diagrams is a natural extension.
It does not need to be globally “active” in the same way as Ponytail or Superpowers. It can simply be invoked when the task calls for a visual.
### Hermes verdict
**✅ Install / use on demand.**
For documentation-heavy infrastructure work, I expect this to pay for itself quickly.
---
# 🏗️ The Hermes stack I actually want
After comparing all ten, my preferred architecture is deliberately small:
```text
┌──────────────────┐
│ Hermes │
└────────┬─────────┘
│
┌─────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
Superpowers Ponytail Graphify
engineering process minimal solutions repo intelligence
│ │ │
└──────────────┬──────┴──────────────┬───────┘
│ │
▼ ▼
Diagram Design I Have ADHD
on demand on demand
│
▼
Hermes tool/context
│
Caveman
experimental layer
│
▼
9Router
│
┌────────────┼────────────┐
▼ ▼ ▼
cloud/free local premium
models models models
```
And beside that:
```text
Graphify → current code relationships
GBrain → durable cross-project memory / decisions / runbooks
AAS → discovery of new candidate skills
```
That creates separation of responsibility instead of one enormous prompt full of overlapping instructions.
---
# 🔐 The biggest lesson: package the runtime, not the whole GitHub repo
The Ponytail experiment changed how I want to handle community Hermes plugins.
A GitHub project can contain:
- runtime code
- examples
- tests
- intentionally malicious security fixtures
- CI files
- benchmark tools
- API clients
- release automation
- adapters for other agents
- documentation describing dangerous strings
Hermes' scanner may reasonably flag all of that because it has no way to know what the author intended.
The safest operational pattern is:
```text
Upstream repository
↓
Review
↓
Extract minimum Hermes runtime
↓
Keep docs outside runtime scanner boundary
↓
Pin exact source commit
↓
Hermes scan
↓
Test
↓
Enable
```
This avoids two bad extremes:
**Bad extreme #1:** disable the scanner because open-source projects produce false positives.
**Bad extreme #2:** assume every static-analysis match means the entire project is malicious.
A small runtime makes it practical to investigate every finding.
---
# 🧷 Pinning matters
For plugins I actually trust enough to run, I strongly prefer immutable revisions.
Conceptually:
```bash
hermes plugins install owner/repo/path \
--enable \
--ref <FULL_40_CHARACTER_COMMIT_SHA>
```
That gives me:
- reproducible deployments
- explicit upgrades
- clear rollback points
- protection from a moving `main` branch
- easier security review
A plugin can be safe today and change tomorrow. Pinning makes the thing I reviewed the thing I run.
---
# 🧹 Why I do NOT want “all the skills”
Modern agent ecosystems are rapidly accumulating enormous skill catalogs.
That creates a temptation to treat capabilities like browser extensions:
> “Install everything; maybe it will be useful.”
For autonomous agents, that is risky.
Every always-on skill can introduce:
- more prompt tokens
- conflicting behavioral instructions
- accidental tool usage
- extra dependencies
- more update surface
- more code to audit
- new failure modes
I would rather have:
```text
5 excellent active capabilities
+
20 reviewed on-demand skills
+
1 searchable catalog
```
than 2,000 skills sitting permanently in the agent's operating environment.
---
# 🧠 How this relates to context compaction
This review started partly because I was looking at better context-compaction strategies for Hermes.
There are really three separate optimization problems:
### 1. Build less
**Ponytail**
Reduce unnecessary implementation and therefore reduce the amount of code, testing, review, and context generated in the first place.
### 2. Carry less
**Caveman / context-compaction systems**
Shrink logs, tool output, diffs, JSON, and repetitive history before it reaches the model.
### 3. Retrieve better
**Graphify + GBrain**
Instead of carrying everything in the prompt, retrieve the exact repository relationships and long-term project knowledge needed for the current task.
The best long-running agent architecture probably uses all three ideas:
```text
Build less
+
Carry less
+
Retrieve precisely
=
More useful context window
```
---
# ✅ Final takeaways
My current Hermes plan after reviewing these ten projects:
- ⭐ **Superpowers** — strong candidate for engineering discipline.
- ⭐ **Ponytail** — strong candidate, but packaged as a minimal Hermes-specific runtime.
- ⭐ **Graphify** — install for repo intelligence.
- 🧪 **Caveman** — benchmark before putting it in front of 9Router.
- ✅ **Diagram Design** — install for on-demand technical visuals.
- ✅ **I Have ADHD** — install as an on-demand concise execution mode.
- 🟡 **Understand Anything** — useful optional human-facing visualization layer.
- 🔎 **AAS Core** — use to discover skills, not to install the entire universe.
- ⚠️ **Last30Days** — potentially excellent research capability, but audit before production.
- 🧬 **Scientific Agent Skills** — excellent project, not relevant enough for my global Hermes profile.
The most useful outcome was not a list of plugins.
It was a better deployment philosophy:
> **Small runtime. Explicit purpose. Pinned version. Scanner stays on. On-demand skills when possible. No giant global skill dump.**
That is the direction I want for Hermes going forward. 🧠🔐🚀