agent-skills v0.7.0: Thirty-One New Skills and One Flat Repo

I’ve been tagging releases of my open-source agent-skills repository like it’s my job lately. v0.7.0 landed today: thirty-one new skills, serious upgrades to more than twenty existing ones, and a repo restructure that’s been brewing for weeks. The portfolio now stands at 163 SKILL.md entry points on main.

I’ll just say it: I think this is the deepest collection of agent skills anywhere on GitHub. Here’s what’s actually in this one.

The pace first, because the git tags tell the story honestly. v0.3.0 shipped July 21. Then v0.4.0 the very next day, v0.5.0 on July 27, v0.6.0 on August 2, and v0.7.0 tonight. Five releases in about four and a half weeks. That cadence is only possible because I run a solo software factory: an agent harness with role-separated workers, independent validation, and deployment automation that I’ve written about before. My time goes into the pre-coding work (specs, review, deciding what’s worth building at all), while the coding, QA, and deployment are the harness’s job, not mine. The skills improve constantly because shipping one is cheap.

If you want the whole release on one poster before the tour, here it is:

The thirty-one new skills#

I counted these the honest way: by diffing the skill trees between the v0.6.0 and v0.7.0 tags. 132 skills became 163. This batch covers more ground than some entire libraries. Here’s the tour, group by group, with a real description of each one rather than a name and a shrug.

Architecture and strategy#

These seven live at the thinking layer of the job, the part that happens before anyone writes code:

• enterprise-architecture: design and evolve architecture at organizational scale, where the systems estate, the operating model, and the budget all have to agree with each other. It treats enterprise architecture as a connective discipline rather than a shelf document. Useful when someone asks why the company runs four tools that do the same job.
• software-architecture: shape systems on purpose instead of by accretion. It covers designing from business drivers, reviewing designs for drift, and documenting decisions so they survive personnel changes. If you’ve ever inherited a codebase and wondered what the architects were thinking, this is the skill that produces architects worth wondering about.
• multi-tenant-saas-architecture: build one product that many companies live in safely. It walks end-to-end design for multi-tenant SaaS: tenant isolation models, noisy-neighbor management, data boundaries, and the operational habits that keep customer A’s outage from becoming customer B’s problem.
• digital-twin: create virtual stand-ins for physical systems, then keep them trustworthy over time. Design, evaluation, governance, monitoring, evolution, and eventual retirement are all in scope, because a twin nobody trusts is just an expensive animation.
• ai-operating-economics: decide whether an AI-enabled workflow should be automated at all, and model what it really costs when it is. Unit economics, capacity constraints, and build-versus-buy calls get explicit treatment. Most teams are currently answering these questions with vibes, and the vibes are expensive.
• aeo: Answer Engine Optimization. Search used to reward pages people clicked. It increasingly rewards pages engines quote, and being quotable is a different technical game with different rules around structure, evidence, and answer-first content.
• ai-governance: stand up real AI governance for an organization, from first intake form to board report. It ships a use-case risk-tier classifier script, model card and model-risk assessment templates, governance charter and intake materials, third-party due-diligence and board-report templates, and reference coverage spanning regulation, LLM security, privacy, procurement, transparency, fairness, accountability, and GxP expectations in regulated life sciences. If your organization is improvising its AI governance, start here.

Engineering operations#

The eight your infrastructure folks will adopt first:

• postgres: operate PostgreSQL instances without holding your breath. Safe configuration review, routine maintenance, troubleshooting, and upgrade hygiene are all covered, aimed at keeping production databases boring in the best way.
• terraform: run Terraform and OpenTofu across the whole infrastructure lifecycle. State handling, module design, plan review, and drift correction get real depth instead of tutorial-level hand-waving.
• vllm: serve LLM inference at high throughput with vLLM. Configuration, benchmarking, quantization choices, and troubleshooting are covered end to end, for when token generation needs to be fast enough to matter.
• litellm: operate LiteLLM as your AI gateway. One front door for every model provider: routing rules, key management, budgets, fallbacks, and the security posture that a component sitting between all your apps and all your model spend actually requires.
• telemetry: stand up observability as one stack instead of three tools that argue with each other. Prometheus metrics, OpenTelemetry instrumentation, and Loki logs deploy together, with ingestion paths you can debug when something inevitably stops reporting.
• mobile-development: build, test, sign, and ship mobile apps across iOS, Android, Flutter, and React Native. Store signing, release channels, and platform quirks are treated as first-class engineering concerns rather than afterthoughts.
• playwright: drive browsers end to end with Playwright. Automated testing, scraping, and headless browsing share one operational reference, including the auth flows and flaky-selector realities that documentation usually skips.
• data-cleaning: clean, profile, validate, reshape, and document messy tabular data. It assumes the spreadsheet is messier than the tutorial promised, because it always is, and gives you a repeatable pipeline instead of heroics.

Domain and craft#

Sixteen more, and this is where the library gets interesting, because no two of these came from the same neighborhood:

• actuarial-risk-modeling: insurance-grade statistical modeling for financial risk. Mortality tables, loss distributions, and reserve calculations get actuary-grade treatment. An agent skill for actuarial work is not something I ever expected to ship, and yet here we are.
• semantic-spacetime: a research-grounded model of how agents (and people) establish shared semantic ground. It’s useful for diagnosing why two systems agree on vocabulary but not meaning, which turns out to be most coordination failures in disguise.
• promise-theory: coordinate hybrid human-and-AI teams through promises instead of orders. It gives you a language for who commits to what, how commitments propagate, and where trust breaks down. I reach for it when a workflow spans people, agents, and services that all need to keep their word.
• dsm5: an evidence-based companion to the DSM-5-TR for navigating diagnostic criteria honestly. It helps assess and explain mental health and neurodivergence questions without armchair diagnosing anyone. Quietly, I think it might be the most consequential skill in this batch.
• genius-life: cultivate creativity deliberately instead of waiting for lightning. It guides a person through structuring their own working conditions for better ideas. Think of it as practice infrastructure for the creative process.
• travel-guide: personalized, source-grounded travel dossiers rather than an SEO listicle with ads. Itineraries come with provenance, practical detail, and enough structure to survive contact with an actual trip.
• ascii-city-engine: build portable, first-person colored ASCII city engines that render in any terminal. Whole explorable cities out of characters and ANSI color codes. I’m oddly fond of this one.
• anydoc: convert Word, PowerPoint, Excel, EPUB, and other office documents into clean GitHub-Flavored Markdown. Layout inspection included, because faithful conversion means knowing what the rendered thing actually looks like.
• documents: generate, read, edit, validate, and repair PDFs, Word files, spreadsheets, and presentations programmatically. Where anydoc gets documents into Markdown, this one creates and fixes them in their native formats.
• forward-deployed-engineering: run embedded technical engagements where the work happens at the customer’s edge. It covers the whole arc from ambiguous stakeholder needs through scoped delivery, written for engineers who live closer to customers than to headquarters.
• slack, notion, email, crm, and stripe: a five-piece collaboration and business-app layer covering chat, documents, mail, customer records, and payments. These are the connective-tissue skills for agents doing real office work. They handle the unglamorous transactions that actual jobs run on: sending the message, updating the record, reconciling the charge.
• writers-helper: guide any writer, fiction or nonfiction, through the whole writing process from first idea to final polish. It’s the skill behind a growing share of the prose on my sites.

An actuarial scientist and an ASCII city planner, sharing a repository. I love that these coexist. Real work isn’t one genre, and neither is this library.

The upgrades worth knowing about#

More than twenty existing skills got major surgery. The headlines:

site-reliability-engineering gained a recovery closure gate. Here’s the failure it targets: the alert clears, the health endpoint goes green, and someone declares the incident over while the job queue is still backing up and users still see errors. The gate says a cleared alert is evidence, not a verdict. Before you mark anything resolved, it makes you verify what users are actually experiencing, watch through a stability window, confirm the backlog recovered, and record what you saw. If the evidence isn’t there, the incident stays open.

linear and fireflies caught up with their live services. The Linear CLI learned project mutations and richer issue verbs. Fireflies was reconciled against its live GraphQL schema and now surfaces recording URLs in transcripts.

travel-guide got a complete visual system, then survived three SkillOpt optimization epochs to tighten it: journey lines, day strips, meters, photo grading, and section footers working as one presentation language.

Beyond those: deeper fitness-function evidence in adr-authoring, API landscape governance in api-design-and-evolution, communication-quality gates in mermaid-diagrams, service-extraction guidance in migration-engineering, proportional governance in technology-radar, tenant-boundary depth in secure-software-engineering, data mesh and event-product guidance in data-architect, and scripts, templates, and evals thickening out backend-engineering, frontend-engineering, ml-engineering, platform-engineering, and supabase. Ten sub-skills now carry eval manifests, and five went through multi-epoch SkillOpt refinement passes. First drafts are for humans, but refinement epochs are how skills earn trust.

Neckbeard, my workhorse#

Calling neckbeard a skill is cheating a little. It’s part skill, part router to many other skills in the repo: it knows what’s there and has good judgment about when to reach for each piece. That’s exactly why it’s the one I call to begin very complex work. I hand it a mess, and it sees the work through to the end.

The core loop is unchanged. Give it a change request (an issue, a ticket, anything with an outcome) and it routes the work through framing, discovery, design, implementation, review, and verification, choosing the smallest safe intervention at each step and keeping an inspectable evidence ledger as it goes. For real change-request work it follows a nine-phase journey with explicit gates between phases, so “almost done” has to survive actual evidence at each boundary. It composes the catalog’s specialist skills rather than replacing them: neckbeard is the conductor, not a second orchestra.

v0.7.0 taught it two genuinely new tricks:

1. Position assessment for mid-flight work. The old weakness: hand it a half-finished branch or a change another contributor started, and it either restarted from scratch or trusted someone’s summary of what was done. Now it inventories the observable artifacts, scores them against each phase’s exit conditions, and emits a position report: where the work actually is, which gates are satisfied with evidence pointers, and what remains. Then it bootstraps a delivery packet and continues from there. It meets work where it actually is instead of where the story claims it is.
2. Tracker-neutral intake. It now detects which tracking system holds the work item (Linear, Jira, Notion) and routes tracker operations to the matching tooling skill, keeping its own vocabulary neutral. The journey no longer cares where the ticket lives.

The whole journey, with every gate, looks like this:

It’s also the skill behind this very article’s pipeline: the drafting gates that keep my voice intact run on the same evidence-over-assertion discipline neckbeard enforces everywhere else. When people ask how one person ships releases this fast, this is half the answer. The repo is the other half.

The other big bet: digital twins#

If neckbeard is the workhorse, digital-twin is the long bet. On the surface it’s a lifecycle skill for virtual stand-ins of physical systems: design the twin, validate it against reality, govern who gets to act on it, monitor drift between the model and the world, evolve the pair together, and retire the twin honestly when it stops earning trust. Useful stuff. But it’s not the reason I rated this skill’s odds so highly.

An agent that wants to act on real infrastructure runs into a hard ceiling: acting is risky, so a human has to be in the loop for everything, forever. A trustworthy twin changes that math. It gives the agent somewhere to rehearse: propose the change, run it against the stand-in, watch what breaks, measure the blast radius, and bring the evidence back to reality before anyone’s production system feels a thing. Failure gets cheap. Verification becomes something you can show instead of promise.

We’re only scratching the surface of that today. But the direction is clear: safe, responsible agentic engineering needs somewhere safe to be aggressive first, and I expect this skill to grow into one of the most important things in the portfolio. Call me in a year and ask whether I was right.

Evals, and why a skill library has them#

A few terms in this release deserve a plain-language explanation, because they’re where the bundle is headed.

An eval is a repeatable test for an agent skill: give the skill a realistic task, check the output against criteria you wrote down in advance, and record whether it held up. Skills without evals are recipes with no taste-tester: you find out they’re broken when dinner’s ruined. Ten sub-skills now ship eval manifests, which means anyone can run those checks themselves instead of taking my word for it.

Mutation testing is how you test the tests. The tool deliberately injects small bugs into code (flip a comparison, drop a boundary check) and watches whether the test suite notices. Every injected bug that survives undetected is a blind spot with a name on it. The repo applies the same suspicion to its own quality machinery: qa-methodology carries mutation-guided test hardening, and the CI pipeline enforces an eval-coverage ratchet, so if you modify a skill without keeping its evals at least half covered, the build fails.

One flat repo#

The structural change in the title: the nested bundles/ directories are gone. Every skill now lives at the repository root, which makes the whole portfolio easier to browse, easier to fork piecemeal, and easier to script against.

Two new GitHub Actions workflows bring automated Droid code review to pull requests alongside the existing checks. (A robot reviews my contributions now, and the honest summary is that it catches real things.) Validation also enforces a 60,000-character cap on skill reference files, which sounds bureaucratic until you understand it as progressive-disclosure discipline in executable form: oversized references split into an index and focused parts instead of one giant context payload. And I repaired dead cross-skill routing references across the methodology skills, because a skill pointing at a dead next step is still a broken workflow.

What this means when you clone it#

You clone one directory and you get more than prompt text. Methodology, sure, but also templates you can fill in, scripts you can run, references organized for progressive disclosure, and evals that show what “working” means for each skill.

But the part I care most about is what open source puts in your hands: agency. Inspect a skill before you trust it with anything that matters. Fork what fits your environment. Change the parts that don’t. Delete freely. The person installing a skill still owns the judgment about where it belongs, how much authority it gets, and how its output gets verified. A bigger library should mean more control over your tools, not a bigger pile of magic to defer to.

Where this goes next#

The near-term work is depth: more eval coverage, more skills carrying executable support, more refinement passes on entries that deserve them. The tags will keep telling the story either way.

If you’re building with agents and haven’t looked at the repository yet, v0.7.0 is a good week to fix that.