On Monday you’re a product strategist. On Tuesday you’re an architect. Wednesday is sysadmin. Thursday is marketing. Friday you run the numbers and realize you’re an accountant. Saturday you look at the week and wonder who checked any of it. The question is always the same: which of these ten jobs do I do today?
The cruelty of the solo-founder job is not the difficulty. Each job alone is manageable. Product strategy is hard but contained. Architecture is hard but bounded. The cruelty is the switching cost. You touch each domain rarely enough that procedural memory never forms. You spend Monday thinking about roadmap prioritization and by Wednesday you’re debugging an nginx rewrite rule you haven’t touched in three months, and there is nothing that bridges the two modes except your own exhausted brain. You need every one of them to be correct. A pricing mistake loses money. A deployment mistake loses customers. A spec mistake wastes a week. And there is no second set of eyes on any of it.
When you work on a team, the switching cost is distributed. The marketer handles marketing. The accountant handles the books. The engineer reviews the engineer’s code. The solo founder has no distribution. Every hat is yours, every hat lands on the same head, and the loneliness of being the only reviewer is what turns a manageable pile of tasks into formless dread.
The pile is formless. Formlessness is what makes big work feel big.
I built a repository of about 144 skills for AI agents (agent-skills, written in the open Agent Skills format) because I was tired of the formlessness. Hermes Agent is the companion that carries them. The thesis is simple: big work feels small when clean means verified, not hoped.
Here’s the shape of it: six real demos of the companion working across six of the founder’s hats, carrying one illustrative product through the entire line from the hunch to production. A solo founder building a billing tool for small agencies. The product isn’t real, but the discipline is. Discover, decide, build, run, sell, review. Each demo starts the same way: you tell the companion what you need, it loads the skill, runs the tools that skill calls for, and brings back an answer. The thread between them is the same discipline repeated at every handoff.
What a skill actually is#
A skill in the agent-skills format isn’t a prompt template. It’s a self-contained procedure: when to trigger, which steps to run, what can go wrong, and how to check the result. Think of it as the checklist a competent person writes after doing something hard a few times, so the next person (or agent) doesn’t repeat the same mistakes.
The format’s plain Markdown. A skill file lives in a repository, and an agent reads it like a manual. It says: when you see X, do Y in this order, watch out for Z, and then check your work by doing W. The agent isn’t left to invent the procedure. It follows the one in the skill.
A skill carries tools. Not scripts you type, but programs the agent runs on your behalf. You give the companion a plain-language request, the skill tells the agent which tool to run, and the tool hands back a machine-readable outcome: a verdict, an exit code, a table, or a check result. The companion reads that outcome and turns it into an answer you can use. You don’t need to work the machinery yourself every time. What matters is the answer the companion brings back.
Hermes loads the skill for the job at hand. The skill carries the discipline. The companion does the checking.
Paul Graham wrote about Default Alive and Default Dead in 2015: if you’re spending more than you earn, you’re dead unless something changes. The framework is simple enough to explain in a paragraph, but applying it under pressure leaves plenty of room to misread the numbers. That is the kind of domain where a skill helps: the concept is clear, the execution is full of traps, and a solo founder has no CFO to call.
Let me show you how.
Neckbeard: the skill that finds the skill#
When you know which hat you’re wearing, you load the specialist skill directly. The demos ahead show exactly that. Tell the companion you need to run the numbers, and it loads the calculator. Tell it to check your spec, and it loads the quality gate.
But the hard problems rarely arrive labeled. You don’t always know which skill applies. A problem sits in front of you that could be product, engineering, operations, or all three at once. That is where Neckbeard comes in. I wrote about it in more detail in Introducing Neckbeard: Results Without the Cosplay. When you don’t know the hat, or the problem doesn’t fit one, you tell the companion to solve the problem. It loads Neckbeard.
Neckbeard is an umbrella skill and a router. It doesn’t replace specialist skills: it composes them. It moves the work through stages: frame the change contract, discover the real system before designing, select the smallest safe intervention, execute by stage, keep an evidence ledger, and stop and escalate by rule. At each stage it loads the specialist skill that owns the work: product-discovery for understanding the problem, spec-driven-development for structuring the plan, systematic-debugging for tracking down failures, secure-software-engineering for shipping safely, verification-methodology for checking the results, release-engineering for the deployment, and site-reliability-engineering for keeping it running. Instead of re-deriving the procedure each time, Neckbeard loads the specialist that already knows it.
Its one rule defines what “done” means: done is prohibited unless the declared verification target has actually been exercised. If it hasn’t, report the unverified gap honestly instead of claiming completion. Clean means verified, and Neckbeard refuses to call anything done that wasn’t checked. That’s the thesis of this article embedded as a gate inside the router itself.
The name is a joke about the “10x developer in a Markdown file” trope. The substance is the opposite: effectiveness earned by observable outcomes and scoped claims, never asserted by a persona. I built it with an evaluation harness that measures SDLC outcomes, never lines of code. It is my most-used skill for tech startup work because it makes sure I find the right skill even when I don’t know what skill to use. I tell it to solve a problem, and it picks the specialist skills and works through the problem.
Like product-discovery, Neckbeard isn’t a script you run. It’s the skill the companion loads when you don’t know which specialist belongs on the problem. Everything in the six demos ahead is what Neckbeard can route to, but you don’t need to know that in advance. That’s the point.
Discover: the hunch becomes a plan#
Before you build anything, you need to know whether anyone actually wants it. The product-discovery skill doesn’t produce code or a spec. It produces clarity. It maps stakeholders, structures interviews, distills notes into spec components, and uses its completion checklist as the gate before anything else happens.
Here is what that looks like for an illustrative billing product: overdue invoice reminders for a small B2B SaaS. The founder has a hunch that late-paying customers are a real problem, but a hunch is not a product. The discovery plan maps the stakeholders:
| Name/Role | Type | Priority | Interviewed? |
|---|---|---|---|
| Small agency owners who invoice monthly | Knowledge | Must | Yes |
| Freelance bookkeepers who chase late invoices | Affected | Must | Yes |
| The founder (owns product and budget) | Authority | Must | Yes |
| Billing platform engineer (knows the codebase) | Implementation | Should | Yes |
The plan structures the interviews into three phases. Phase A asks about the problem: walk me through the last invoice you had to chase, how do you notice an invoice is late, and what makes you give up on one. Phase B asks about feasibility: do invoices have a stable status field, and can we send email without a dedicated service. Phase C asks about validation: would you pay extra for this, and what would make you turn it off.
The completion checklist is the gate. Ten items, all checked before the handoff:
- All stakeholder types interviewed (knowledge holders, authority holders, affected parties, implementation knowers)
- At least three independent sources for every requirement
- Abstract nouns decomposed into measurable thresholds
- Conflicts resolved or documented with decision-maker identified
- Edge cases extracted from stakeholder anecdotes
- Every AC classified: SAID / IMPLIED / INTERPRETED / INFERRED
- HIGH-risk interpretations identified and flagged for validation
- Gaps, deferred decisions, and avoided topics documented
- Stakeholder validation loop completed
- Interpretation audit trail preserved for handoff
When all ten boxes are checked, the interview answers distill into the SPEC for the feature. That’s the handoff: discovery is Phase 0 of the pipeline, and the SPEC is Phase 1. The founder now has something concrete to specify, not a feeling.
The product-discovery skill is methodology, not a CLI. There’s no command to run and no output to capture. The artifact is the plan itself, the completed checklist, and the handoff line. The discipline is in the structure, not the execution. The companion walks the founder through the steps and checks each box.
Decide: am I going to survive?#
The yc-default-alive-calculator skill implements Graham’s framework as a calculator. You give it four numbers: monthly revenue, monthly burn, cash on hand, and monthly growth rate. It tells you whether you’re Default Alive or Default Dead and shows the diagnostics behind the verdict.
Here is an illustrative profile for the billing product itself: twelve thousand dollars in monthly revenue, eighteen thousand in monthly burn, two hundred twenty thousand in the bank, growing at seven percent a month. I told the companion to run the numbers. Inside the skill sits a small calculator: it takes four numbers and returns a verdict. The agent ran it and read back:
{
"inputs": {
"monthly_revenue": 12000.0,
"monthly_burn": 18000.0,
"cash_on_hand": 220000.0,
"monthly_growth_pct": 7.0
},
"diagnostics": {
"net_monthly_burn": 6000.0,
"burn_multiple": 0.6,
"burn_to_revenue_ratio": 0.5,
"current_arr": 144000.0,
"net_new_arr": 10080.0,
"projected_cashout_month": null,
"months_to_breakeven": 10,
"cashout_month": null,
"gap_to_breakeven": 6000.0,
"months_of_gap_remaining": 36.7,
"months_projected": 120
},
"model_assumptions": {
"fixed_burn_pct": 70.0,
"variable_burn_ratio": 0.45,
"growth_decay_pct": 0.5,
"projection_cap_months": 120,
"safety_buffer_months": 3
},
"verdict": "ALIVE",
"explanation": "\u2705 DEFAULT ALIVE \u2014 You will reach profitability before running out of cash.\n Breakeven projected at month 10.\n\n Burn Multiple: 0.6x (efficient, net burn / net new ARR)\n Burn to Revenue: 0.5x (net burn / MRR)\n Projected cash-out: none within the 10-year projection\n Monthly gap: $6,000\n Cash: $220,000",
"levers": [],
"trajectory": "60 months projected (use --verbose to show)"
}
Default Alive. The diagnostics show the meaningful numbers: a Burn Multiple of 0.6x (net burn divided by net new ARR), a cash gap coverage of 36.7 months at current spend (two hundred twenty thousand divided by six thousand), and breakeven projected at month 10. Sixty seconds, four numbers, and an answer to a question that can keep a founder up at night.
Now change two numbers. Keep the revenue at twelve thousand and the cash at two hundred twenty thousand, but raise the burn to twenty-six thousand and drop the growth to three percent. The companion ran the calculator again and handed back:
============================================================
DEFAULT ALIVE / DEFAULT DEAD ANALYSIS
============================================================
── Inputs ──────────────────────────────────────────────
Monthly revenue: $ 12,000
Monthly burn: $ 26,000
Cash on hand: $ 220,000
Monthly growth: 3.0%
── Verdict ─────────────────────────────────────────────
DEAD
❌ DEFAULT DEAD — You will run out of cash before reaching profitability.
Cash runs out at month 18.
Breakeven would require 57 months — too late.
Burn Multiple: 3.24x (critical, net burn / net new ARR)
Burn to Revenue: 1.17x (net burn / MRR)
Projected cash-out (model): month 18
Monthly gap: $14,000
Cash: $220,000
── Diagnostics ─────────────────────────────────────────
Net monthly burn: $ 14,000
Burn Multiple: 3.24x (net burn ÷ net new ARR)
Burn to Revenue: 1.17x (net burn ÷ MRR)
Current ARR: $ 144,000
Net new ARR/month: $ 4,320
Projected cash-out: month 18
Months to breakeven: 57
Cash gap coverage: 15.7 months at current spend
── Model Assumptions ──────────────────────────────
Fixed burn: 70% of burn fixed; 30% scales with revenue
Variable burn ratio: 0.65 per $1 of revenue
Growth decay: 0.5% per month
Projection cap: 120 months | Safety buffer: 3 months
── Levers ───────────────────────────────────────────────
🔴 accelerate-growth: Increasing growth rate to 15%/month would reach breakeven sooner
🔴 reduce-burn: Burn is more than 2x revenue — cost reduction extends runway directly
🚨 fundraising: Default Dead means fundraising is existential, not optional
🟡 pricing: 20% price increase with <5% churn impact could shift trajectory significantly
============================================================
Paul Graham's Default Alive/Dead Framework
paulgraham.com/default.html
============================================================
Default Dead. Cash runs out at month 18. Breakeven would require fifty-seven months. The Burn Multiple jumps to 3.24x. The cash gap coverage drops to 15.7 months. The levers are explicit: accelerate growth, reduce burn, or raise money.
Two things worth knowing about this output. First, the calculator models thirty percent of your burn as scaling with revenue, and growth decaying by half a percent per month. The Model Assumptions block in the output says so explicitly, because it didn’t always. Second, the Burn Multiple is Graham’s metric: net burn divided by net new ARR. The Burn to Revenue line below it is net burn divided by MRR, a secondary ratio, not the number to track. Those labels were not always this clear. A verification pass surfaced both problems, and I filed issue #272 and issue #273 to fix them. I’ll come back to that.
For now the point is simpler: sixty seconds, four numbers, and you have an answer to a question that can keep you up at night. Not a feeling. A number.
Build: shipping a feature with no reviewer#
The spec-driven-development skill turns the vague instruction “build this feature” into a structured specification that an agent can execute. The spec defines the problem, success criteria, what is in scope, what is out of scope, user stories with acceptance criteria, edge cases, and non-functional requirements.
The skill ships a quality gate that checks whether a spec has all the required sections. After the founder writes a rough draft of the spec, the agent runs the gate. The exit code is the verdict the agent reads. Here is what the gate came back with on the first draft for an overdue invoice reminder feature:
Checking: SPEC-first-draft.md
✓ Problem Statement
✓ Success Criteria
✓ In Scope
✓ Out of Scope
✓ User Stories
✓ Acceptance Criteria (found: 7 references)
✗ Edge Cases
✗ Non-Functional Requirements
✓ Assumptions & Open Questions
FAIL: 2 required section(s) missing from SPEC-first-draft.md
[exit=1]
The first draft fails. Two required sections are missing: edge cases and non-functional requirements. Without those, an agent building this feature would not know what happens when an invoice is paid between tier checks, or how fast the job needs to run, or whether email deliverability matters. Exit code 1 is the agent-parsable verdict: the spec is not ready.
Add the missing sections and the agent runs the gate again:
Checking: SPEC-final.md
✓ Problem Statement
✓ Success Criteria
✓ In Scope
✓ Out of Scope
✓ User Stories
✓ Acceptance Criteria (found: 7 references)
✓ Edge Cases (inline per user story)
✓ Non-Functional Requirements
✓ Assumptions & Open Questions
PASS: All required sections present in SPEC-final.md
[exit=0]
Pass. The exit codes tell the story: exit 1, then exit 0. The gate is the reviewer you don’t have on a solo team. It doesn’t care that you’re tired or tempted to skip the edge cases. It checks the structure and tells you what’s missing.
What makes this useful isn’t finding missing sections. Any careful person could scan a document for headers. What matters is that the discipline lands on the agent, not the founder. The founder can start with a rough spec, then the agent runs the gate, sees what’s missing, and fixes the draft. By the time the founder reviews it, the gate has already told the agent what still needs work. That’s the reversal.
But the spec alone is not enough. A complete spec that maps to zero tasks is a document, not a plan. The spec-driven-development skill also ships a task-plan coverage gate: after the spec passes its quality gate, a task plan must cover every acceptance criterion. The companion ran the coverage check:
Checking task coverage in: TASK-PLAN.md
Unique ACs referenced in tasks: 5
ACs found in spec: 5
Coverage: 5 / 5 ACs covered
PASS: Task coverage validation complete
[exit=0]
Five acceptance criteria in the spec, five referenced in the task plan. Every acceptance criterion is represented in the plan. The coverage gate is the second checkpoint between the spec and the build. First the spec is verified as structurally complete, then the plan is checked for coverage against the spec. Only then does the agent start writing code.
This is what “verified, not hoped” looks like in the Build hat. You don’t hope the spec is good enough. You check it, check the plan against it, and give yourself something firmer than one tired person’s confidence before the code starts.
Run: the stack health check#
The illustrative product is specified, the plan is covered, and the feature is ready to build. Then comes the Run hat. The docker-compose skill ships a diagnostic called compose-doctor.sh: a deterministic, read-only health check that never removes containers, networks, or volumes. It tells you what a real stack is actually doing, not what you think it’s doing.
The companion ran the diagnostic against a small monitoring stack on my own server. Here is the table it came back with (the path is shortened to protect the username):
Compose project: ~/docker-compose/grafana
Config: valid
Services:
grafana
loki
prometheus
promtail
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
grafana-grafana-1 grafana/grafana:13.1.1-ubuntu "/run.sh" grafana 8 days ago Up 6 days (healthy) 3000/tcp, 0.0.0.0:8300->8300/tcp, [::]:8300->8300/tcp
grafana-loki-1 grafana/loki:3.7.4 "/usr/bin/loki -conf…" loki 4 days ago Up 10 hours 3100/tcp
grafana-prometheus-1 prom/prometheus:v3.13.2 "/bin/prometheus --c…" prometheus 10 hours ago Up 10 hours 9090/tcp
grafana-promtail-1 grafana/promtail:3.6.11 "/usr/bin/promtail -…" promtail 4 days ago Up 10 hours
The config is valid. Four services listed. But look at the STATUS column. Grafana has been up six days and is marked healthy. Loki, Prometheus, and Promtail all show “Up 10 hours”, meaning all three started or restarted about ten hours ago while Grafana kept running. A founder reading this table sees the change at a glance, and the next question writes itself: what happened ten hours ago? No dashboard, no Grafana panel, just a sixty-second diagnostic that shows you what you have.
The skill’s own boundary statement is worth quoting: “Rendered configuration is not runtime proof. A running container is not a ready service.” The compose file says what should run. The doctor check adds runtime evidence about what is running. The gap between the two is where production lives.
This is the same discipline at a different layer. The spec quality gate checked whether a document was complete. Next, the task-plan gate checked whether a plan covered the document. The compose doctor checks whether a running stack matches its configuration. Three gates, same shape: verify instead of hope.
Sell: the 60-second launch check#
Sooner or later, someone needs to find the product. The seo-audit workflow checks five launch signals: robots.txt, sitemap.xml, llms.txt, a meta description, and JSON-LD structured data. The companion can run all five in under a minute.
llms.txt is worth calling out. In this workflow, it’s a plain-text file checked at the site root alongside robots.txt and sitemap.xml. The check establishes whether the file exists and can be fetched. It doesn’t establish who reads it or what effect it has.
I asked the companion to check two real sites: magnus919.com and groktop.us. Both are healthy. The point of the demo is not to find a dramatic failure. The point is that a founder can now verify, in under a minute, that their launch is findable. And the companion checks before claiming.
The companion ran the five checks. What came back wasn’t a dramatic failure. It was three small lessons about how easy it is to check the wrong thing.
A sitemap that is one minified line shows “1 URL” if you count lines. The real count is 1,332. Count the occurrences, not the lines. This is the kind of thing that makes a founder believe their sitemap lists one page and panic, when actually the file is just formatted efficiently.
The second trap was the meta description. It can exist with unquoted attributes, so a naive check misses it entirely. Check the actual attribute shape. HTML is forgiving in ways that simple pattern matching is not.
Then there’s the redirect. If a site sends every path to a canonical host with a 302, you need to check that host before concluding anything. groktop.us redirects the bare domain to www.groktop.us, and the checks need to follow it. A founder who stops at the bare domain could walk away with a false negative.
Neither site had a dramatic gap. That’s the honest result. But now you know. The checks ran, the companion reported the findings, and “clean” means verified rather than hoped. It’s the same pattern as the other demos: no magic, just discipline. Run the checks, look at the results, and know what you have.
Review: the second set of eyes#
This is where the companion stops feeling like a tool and starts feeling like a partner. The verification-methodology skill runs a structured verification pass against an output produced by another skill. It doesn’t rubber-stamp. It checks.
I asked the companion to verify the calculator’s output from the Decide demo. It checked each number independently. Here’s what came back:
Static runway arithmetic passed. The script’s “Cash gap coverage: 15.7 months at current spend” matches the independent calculation of 220,000 divided by 14,000, which is 15.71 months. The arithmetic is right.
The cash-out month of 18 in the DEAD verdict passed with explanation. The number reflects the calculator’s model assumptions: thirty percent of burn scales with revenue, and growth decays by half a percent per month. A constant-burn calculation would give about 26 months. The difference is the model assumption, not an arithmetic error. The calculator’s source code confirms this. In that version, the assumptions were not printed in the output, which was the problem. The number itself was internally consistent.
Two findings emerged that did not pass, against the version of the calculator I first ran:
First, that version printed “Burn Multiple: 1.17x (efficient)” directly under a DEAD verdict. The number was net burn divided by monthly revenue, not Graham’s burn multiple. Graham’s metric, net burn divided by net new ARR, was 3.24x, and it was reported under the separate name “ARR Burn Multiple.” That was issue #272: the headline field suggested a metric the number did not represent.
Second, that same version printed “Runway: 120 months” in an ALIVE verdict. 120 was the projection cap, not a runway. The meaningful static number was “Cash gap coverage: 36.7 months at current spend.” Two runway-like numbers with different bases shared near-identical labels. That was issue #273.
The verification pass didn’t find a bug in the calculator’s arithmetic. The arithmetic was sound. What it found were labeling defects that could mislead a founder reading the output. That distinction matters: a bug produces wrong numbers, while a labeling defect produces right numbers that point you in the wrong direction.
Both issues are now fixed and merged. The calculator reports Graham’s burn multiple under its own name, prints the burn-to-revenue ratio separately, shows “Projected cash-out” instead of a misleading cap, and prints its model assumptions in every output. That is what the Decide section shows above.
This is the climax of the companion’s role: it doesn’t rubber-stamp the tools you build. It confirmed what was right and surfaced what could mislead. The checker got checked. Clean means verified.
The skills also improve because the work keeps finding their edges. I patch a skill when I notice something missing, something broken, or when I reach for a tool that just isn’t there yet. Issues #272 and #273 are that loop in action: the verification pass caught the mislabels, the issues documented them, and the fixes landed in the open. The companion checks the checker, and the checker gets improved.
The discovery-to-production thread runs through all six demos, and the same discipline repeats at every handoff: verify instead of hope. The gates are the reviewers a solo founder doesn’t have.
What stays human#
The skills carry procedure. They don’t carry judgment. There are honest gaps in what this system covers, and naming them is part of using it honestly.
Sales conversations don’t collapse into procedure. A skill can give you a qualification framework and a follow-up cadence, but it can’t tell you whether a prospect is telling the truth about their budget or timeline. You still have to read the room.
Hiring can take a rubric and a scorecard. What no scorecard can tell you is whether someone will be good to work with at 11 p.m. on a Tuesday when the server is down. You have to know people.
Taste sits even farther outside the checklist. A skill can confirm that a spec has every required section, but it can’t tell you whether the feature is worth building. You have to know what your users actually want.
Judgment stays human. The companion carries the discipline for the parts of the job that can be disciplined. It checks the math, verifies the launch, and audits the spec. It doesn’t decide what to build, who to hire, or whether the company should pivot.
That’s the honest scope. Procedure is carried. Judgment is yours.
The hats stay#
Monday still starts with the product strategist hat. Tuesday still needs the architect. Wednesday still has a broken deployment. The hats don’t go away.
What changes is that none of them are formless anymore.
Start with the uncertainty. In the Discover hat, product-discovery gives you a stakeholder map, an interview plan, and a ten-item completion checklist before you write a line of spec. Then the Decide hat gets a sixty-second answer from yc-default-alive-calculator: are you going to survive?
Build and Run turn that answer into something you can trust. spec-driven-development gives the Build hat a structured spec, a quality gate, and a task-plan coverage check before an agent writes code. For the Run hat, the docker-compose skill’s compose-doctor.sh shows what your stack is actually doing, not what you think it’s doing.
The Sell hat gets an under-a-minute check of the launch signals from seo-audit. Review gets verification-methodology, which checks another skill’s output against declared criteria. Here, it caught misleading labels wrapped around otherwise sound arithmetic.
And when the problem won’t sit neatly under any hat, neckbeard figures out which specialists belong in the room and routes the work to them.
The companion doesn’t replace the founder. It gives the founder a second set of eyes, a checklist, and a verifier. It turns the question “which of these ten jobs do I do today” from a source of dread into a question of which skill to load.
I built these skills because I needed them. I use them because they work. And I file issues against my own tools when the verification pass finds problems, because the companion checks the checker too.
Every hat gets one companion. The companion carries the discipline. The discipline makes the work small. And the work is still yours.