Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add 42-evey/hermes-plugins --skill plan-before-buildinggit clone --depth 1 https://github.com/42-evey/hermes-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/42-evey/hermes-plugins/plan-before-building)<a href="https://agentmods.dev/skills/42-evey/hermes-plugins/plan-before-building"><img src="https://agentmods.dev/badge/skills/42-evey/hermes-plugins/plan-before-building/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/42-evey/hermes-plugins/plan-before-building"><img src="https://agentmods.dev/badge/skills/42-evey/hermes-plugins/plan-before-building.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00019 | $0.01101 |
| Opus 5.5 | $0.00008 | $0.00440 |
| Sonnet 5.5 | $0.00004 | $0.00220 |
| Haiku 4.5 | $0.00002 | $0.00110 |
Grade A, and why
plan-before-building scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Before Building
Turn a request into a written spec and a task plan, decide every detail you can yourself, and get the user's approval in one round. When the open question is whether something is feasible at all, use spike first.
When to Use
- A request that adds a feature, changes behavior, touches more than a few files, or spans sessions
- The user asks for a design, a plan, or to think it through first
- Work you will hand to subagents, which need tasks with exact files
- Don't use for: one-line fixes, a task the user already specified file by file, debugging (
systematic-debugging)
Procedure
- Read before asking. Read the relevant code, docs and recent history (
terminal("git log --oneline -20")), and find conventions withsearch_files. Done when you can name the files the change touches. - Sort the open decisions. List them all. Mark each one:
- Architecture: data model, interfaces, storage, external dependencies, what the user sees, irreversible operations, recurring cost.
- Detail: names, file layout, a library within the existing stack, error text. Decide every detail yourself, following the project's conventions.
- Ask the architecture questions once. Send them together in one message (
clarifyor plain text). Give each your recommended answer, the alternatives, and what each choice changes. With no architecture questions, skip to step 4. Done when each has an answer. - Write the spec to
docs/specs/YYYY-MM-DD-<topic>.md, or wherever the project keeps specs:- Request: the user's words quoted verbatim from their messages. Paraphrase is where scope drifts.
- Goal: the end state in one or two sentences.
- Out of scope: what this work does not do.
- Decisions: each call you made, with a one-line reason.
- Design: components, data flow, interfaces, error handling.
- Done means: observable checks that prove it works on the user's path (
verify-before-done).
- Write the plan to
docs/plans/YYYY-MM-DD-<topic>.md. One task per change that can be finished and verified in one sitting. Each task names Files, Change, Proof and Depends on (template below). Order tasks so each leaves the project building and testable; put tests with or before the code they cover. - Review the plan against the spec. Every spec requirement maps to a task. No task says "TBD", "handle edge cases" or "add error handling" without naming the cases. Names and signatures match across tasks. Every Proof command can fail. Fix gaps in place.
- Ask for one approval. Send the spec and plan paths and a short list of the calls you made for the user ("Decided: SQLite, not Postgres, because the app is single-user; ..."). Done when the user approves. Write any correction into the spec, not only the chat.
- Hand off. Execute task by task, or brief one subagent per task with
delegation-brief. For work that spans sessions, copy the tasks into the ledger (work-ledger).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today First seen · 73 lines · 19 tokens per session scan A b6bf83a650a8
plan-before-building is a skill published in the GitHub repository 42-evey/hermes-plugins (534 stars, last pushed today), licensed MIT. It adds 19 tokens to every session and 1,101 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-25.
Other skills, from other repositories
hunt-wordpress
Use when an authorized target exposes WordPress core, plugin, theme, REST, or XML-RPC behavior.
life-os
You are Hermes Life OS — a personal operating system that learns who you are, remembers everything you share, and grows smarter about your life every single day.
browser-harness-authoring
Use when mapping a repeatable website workflow into a verified Hermes skill so later runs can follow known steps instead of rediscovering the site. Surveys browser compatibility, semantic targets, failure modes, recovery paths, decision gates, and expiry using dummy data and no irreversible submissions.
notion-artifact-capture
Use when a user says “save to Notion” for research, reports, drafts, references, or generated artifacts and wants a reusable default destination. Bootstraps a generic Notion AI Output Library under a user-created shared parent page, saves typed metadata and optional Markdown, verifies every write through the live API…
obsidian-memory-architecture
Use when designing, setting up, or maintaining an Obsidian vault as Hermes Agent's durable knowledge layer. Routes facts, conversation history, documents, procedures, and daily logs to the correct Hermes or vault system without duplicating everything into the prompt.
wordpress-plugin-hunt
Hunt WP plugins via REST, exploit CVEs when version known.