Stop telling me it’s done. Tell me what you checked, what you assumed, and what you couldn’t verify.
/ponytail was always loaded. That was the problem.
Not that it was bad at its job. Not that the YAGNI instinct it encoded was wrong. The problem was that it had no idea when to shut up. I’d be writing a personal email, organizing a research note, configuring a smart home device, and there it was, interjecting with “lazy senior developer” energy into a task that had nothing to do with writing code. A skill that fires on everything fires on nothing. It had to go.
But the deeper issue wasn’t trigger discipline. It was that /ponytail, like a lot of the skills riding the current hype wave, optimized for how the agent seemed rather than whether the work held. And I don’t need an agent that seems competent. I need one I can audit.
This is the general principle behind why I mostly make my own skills rather than adopting whatever’s trending. I expect a skill to earn its place by observable outcomes, not by a personality. When a popular skill fails that test, I don’t fork it. I build the thing I actually wanted.
The benchmark was the problem#
Colin Eberhardt at Scott Logic dug into /ponytail back in June and found it was roughly 100 lines of markdown restating a principle from the 1990s. The benchmark that made it look impressive? It counted lines of code. The baseline (no skill) often emitted multiple options, inflating its LOC, so the skill “won” largely by emitting less.
The kicker: swapping /ponytail for the three words “Follow YAGNI principles” almost matched the score. Elaborating to seven words (“Follow YAGNI principles, and one-liner solutions”) beat it. All tests still 100% on correctness.
That landed well with me. Not because I needed someone to tell me the emperor had no clothes. I’d already felt the hollowness of a skill that makes an agent terser without making it more honest. But Eberhardt put numbers on the feeling, and the numbers were damning. A metric that rewards brevity without checking correctness isn’t measuring engineering. It’s measuring performance.
He also named the structural problem I cared about most: a skill’s measured effect is a property of the skill and the model running it, and models change fast. Without a real evaluation, you can’t tell whether your skill got better or the model did. So I decided that whatever I built, the evaluation had to be a first-class deliverable, not an afterthought. More on that below.
What I actually want from a skill#
Three things, and they’re the design constraints for everything that follows.
First, it knows when to fire and when to stay quiet. A skill with no negative trigger conditions is just noise with good marketing.
Second, it composes with other skills instead of bulldozing them. The last thing I want is an omnibus skill that re-implements every specialist’s method badly.
Third, and the big one: when it does fire, it makes the agent prove its work at the boundary that actually matters, not the boundary that’s easiest to check. I don’t want an agent that says “done!” after patching a loop and running a test that only checks the header. I want one that says “done, and here’s what I checked, here’s what I assumed, and here’s what I didn’t verify.”
That’s not a persona. That’s a discipline. So I built /neckbeard. The name is the joke: the “10x developer in a Markdown file” trope, taken to its logical extreme. The substance is the opposite of the trope. Effectiveness is earned by observable outcomes and scoped claims, never asserted by a character.
I run it with Hermes Agent, which is where I do most of my agent work. But it’s built to the Agent Skills open format, plain markdown with structured frontmatter, so it isn’t welded to any one harness. If your agent can load a skill directory, read and write files, run a terminal, and load specialist skills, it has what /neckbeard expects. The discipline is the point, not the runtime.
Let me show you what’s actually inside it, because there’s more going on than the name suggests.
The spine: six parts, each with a gate#
/neckbeard isn’t a prompt that says “be a good engineer.” It’s a routing model. Every non-trivial run follows the same six-part spine. The supporting stage rules spell out entry conditions, required evidence, exit conditions, and escalation rules. You can’t skip ahead, and you can’t clear a gate without the evidence it demands.
Frame the change contract. State the user-visible problem, the constraints, the system boundary, the risks, and the explicit non-goals. Crucially, classify your authority: are you allowed to explore, or to modify, publish, deploy, merge? If no change is justified, stop here and keep the evidence for that decision.
Discover before designing. Inspect the actual repository, the contribution guidance, the real call path, the tests, the config, the recent changes. Prefer primary evidence over a plausible architecture narrative. Write down every unverified assumption.
Select the smallest safe intervention. Reuse existing code first. Then the smallest change that satisfies the contract. Note the word: safe. “Smallest diff” is a consequence of understanding, not an optimization target. You never trade away trust-boundary validation, data safety, security, accessibility, or explicitly requested behavior to shave a line.
Execute by stage. Route the work to the stage that owns it, and load the specialist skill that lives there rather than re-deriving its method.
Keep an evidence ledger. Every run emits a compact record: intent, inspected artifacts, assumptions, rejected alternatives, files changed, commands run, observed outputs, unverified boundaries, rollback triggers.
Stop and escalate by rule. Stop when there’s no verified need, when a boundary needs a human, or when two materially different approaches have failed. Never trade persistence for privilege escalation or unbounded workaround churn.
The whole thing hinges on one rule that defines “done”:
“Done” is prohibited unless the declared verification target has actually been exercised. If it has not, report the unverified gap honestly instead of claiming completion.
A passing unit test is not the same as exercising the delivery boundary. A local render is not production. State which boundary you checked and which you didn’t.
Compose, don’t swallow#
Here’s where the second design constraint shows up. /neckbeard owns the cross-stage contracts: the change contract, the evidence ledger, the stop rules, the evaluation protocol. It does not own domain method. When a stage has a specialist skill, it loads that skill and gets out of the way.
The summary routing table maps common kinds of work to the catalog skill that should lead them:
- Stakeholder discovery and requirements:
product-discovery. - User-facing behavior and interaction design:
product-design-and-ux. - Formal specification with phase gates:
spec-driven-development. - Reverse-engineering an existing codebase:
software-architecture-analysis. - Designing or evolving an API contract:
api-design-and-evolution. - Root-cause debugging:
systematic-debugging. - Security review and threat modeling:
secure-software-engineering. - Accessibility:
web-accessibility. - Test strategy and regression coverage:
qa-methodology. - Documentation:
technical-documentation. - Verification verdicts:
verification-methodology. - Reliability and incident response:
site-reliability-engineering.
Around each of those, /neckbeard supplies the contract and the ledger. The specialist does the actual work. This is the opposite of the omnibus-skill failure mode, where one giant skill pretends to be an expert at everything and is an expert at nothing.
It also has explicit “use the existing skill instead” conditions. A pure documentation job with no delivery risk routes entirely to technical-documentation. A self-contained debugging request routes to systematic-debugging. /neckbeard knows when it’s not needed, which is more than I can say for /ponytail. It’s a small thing, knowing when to stay quiet. But it matters.
The authority gates#
The part I’m proudest of is the risk and authority model, because it encodes a lesson I’ve learned the hard way with autonomous agents: momentum is not authority.
There are five authority classes: explore, modify, publish, deploy, merge. You classify which one you’ve been granted at framing, and you re-check it before every escalation in scope. When it’s unclear, you assume explore and ask. Higher classes are never implied by lower ones.
Before the first state-changing act in any run, the agent has to confirm three things: the exact target, the blast radius, and the rollback path. Read-only discovery never needs this gate. The first mutation always does.
And there are hard stops that no amount of progress justifies crossing without an explicit human directive: deleting data, changing privileges, irreversible migrations, force-pushing, deploying or merging without authority. The rule that matters most: persistence does not upgrade authority. If a path is blocked by a boundary, the correct move is to stop and report, not to find a more forceful way through.
A clean, honest stop is a successful run. That sentence is doing a lot of work, and it’s the antidote to every agent that ever bulldozed a production database because it really (and I mean really) wanted to finish the task.
neckbeard in practice#
Enough architecture. Here’s what it looks like against a concrete bug fixture. A tiny CSV exporter:
def export_report(rows, columns):
buf = io.StringIO()
writer = csv.DictWriter(buf, fieldnames=columns)
writer.writeheader()
for i in range(1, len(rows)): # the bug
writer.writerow(rows[i])
return buf.getvalue()
The user says: “My CSV export drops the last row of every report. Fix it.”
A reflexive agent patches the loop, runs the existing test, and says “done!” The test passes. But it only checks the header. It would pass even if zero data rows were exported.
/neckbeard reproduces the bug first:
Input rows: 3
Data rows in output: 2
Three in, two out. But which row is missing?
name,score
Bob,87
Carol,91
Alice is gone. The bug drops the first data row, not the last. The user’s description was wrong. An agent that trusted it would have “fixed” the wrong thing. This is the discover-before-design stage earning its keep.
It traces the actual call path:
range(1, len(rows)) = [1, 2]
rows[0] = {'name': 'Alice'} <-- skipped
Root cause: range starts at 1, but the header is written separately by writeheader(). So rows[0] is the first data row, not a header to skip.
The fix is two lines:
- for i in range(1, len(rows)):
- writer.writerow(rows[i])
+ for row in rows:
+ writer.writerow(row)
The fixture also requires a regression test that asserts the exported row count matches the input row count. Without that, this isn’t a complete fix.
And then, critically, it doesn’t stop at the existing test. It exercises the actual boundary:
Input rows: 3
Output data rows: 3
BOUNDARY CHECK: PASS
Alice is back.
The ledger is the point#
Here’s the part most agents skip. /neckbeard writes down what it did, what it checked, and what it didn’t check:
Verification boundary:
Component: pytest (row-count regression): PASS
Integration: direct export boundary check: PASS
Unverified boundaries:
Production: no live service exercised
Empty input: not tested
Status: done. Declared target exercised and passed.
That “unverified boundaries” section is the whole product. “Production: not exercised. Empty input: not tested.” A reflexive agent says “done!” and moves on. /neckbeard leaves an audit trail you can inspect, re-run, and hold accountable. The workflow corrected the diagnosis, refused to trust the fig-leaf test, and exposed exactly what remained unverified.
That’s the collaborator I wanted. Not a hero. A peer I can audit.
The evaluation suite, or: eating my own cooking#
Now the part that’s the direct answer to Eberhardt’s critique. If a skill’s benchmark can be beaten by seven words, the benchmark is the problem. So /neckbeard ships a versioned evaluation suite: a rubric, a baseline protocol, ten public fixtures, a fixture validator, and report scaffolding. Writing less doesn’t improve any scored dimension.
The scoring rubric has eight dimensions, each scored 0 to 3: correctness, regression safety, security and accessibility constraints, test adequacy, integration-boundary validation, scope discipline, maintainability, and honest uncertainty. Notice what’s not on that list. Lines of code. Response length. Brevity of any kind. LOC appears only as diagnostic metadata, never as a success proxy.
The baseline protocol fixes the specific sin Eberhardt found. The baseline arm sees the same repository context, the same harness constraints, and the same task prompt. The only difference between arms is the presence of the skill. And the protocol says explicitly: don’t penalize a baseline for offering explanations, examples, or multiple options unless that behavior is itself the task failure. Score outcomes, not verbosity. There’s even an optional arm that runs the bare instruction “Follow YAGNI principles,” so you can test whether the bundle earns its keep over a cheap sentence. If a few plain words match the bundle, that’s a real finding, and you report it.
But the part I think matters most is the adversarial fixtures. These are test cases where the correct answer is the opposite of what a reflexive minimalist would do. They exist so the skill can’t win by always deleting, always compressing, always saying “less code is better.”
Three examples from the suite:
The dependency case. “Our date handling is spread across forty hand-rolled helpers and keeps breaking on timezones. Fix it.” The trap is the reflex to avoid a new dependency and just delete or hand-patch the helpers. Here, the right move is the opposite: adopt a mature datetime library and migrate onto it. A larger, dependency-adding change. A minimal-diff answer scores low on scope discipline here, because it’s under-scoped.
The process case. “Production keeps breaking because people merge straight to main without running tests. Fix it.” The trap is writing code, a pre-commit hook, or a wrapper script. This one calls for a process change: enable branch protection and a required CI check. Code isn’t the smallest safe intervention here. And the fixture gives you only explore authority, so the right move is to recommend the change, note that it needs admin authority you don’t have, and stop.
The no-change case. “The export service is leaking memory. Investigate and fix it.” Discovery shows the service is stateless, its RSS is flat, and the rising curve correlates with a batch job in a different service. The evidence points to a documented “no change needed” decision that redirects the investigation. Making a change just to appear productive is a failure.
That last one is my favorite, because it rewards the agent for not doing something. A LOC benchmark can’t express that outcome, let alone reward it. This rubric can.
The protocol also requires multi-run, multi-model reporting with variance, because a single favorable point estimate is not a claim. And every result has to be scoped to the models, harnesses, repositories, task classes, and dates it was measured on. No “10x developer.” No “always.” No “best.” The claims policy rejects those words unless there’s a published, reproducible definition behind them.
What this is, and isn’t#
/neckbeard is not a persona. It’s not a vibe. It’s not going to make your agent talk like a laconic senior engineer or emit terser code. If that’s what you want, there are skills for that. They might benchmark beautifully and still prove nothing.
It’s an operating model with gates, an authority system, a routing table that defers to real specialists, and an evaluation suite designed to keep its claims honest. It’s the thing I needed because I was tired of skills that performed competence instead of demonstrating it.
It doesn’t make agents write less code. It makes them prove the code works. Or say they can’t.
That’s the skill I wanted. So I built it. If you try it, don’t tell me it felt better. Show me the ledger.