Dachary Carey

Two conversations this month sent me back into my server logs.

A colleague asked me this week how I've built the things I've built over the past year: the Agent-Friendly Documentation Spec, the afdocs checker, agentsummons and agentminutes, Agent Skill Implementation, the Agent Reading Test.

I've been building some new tools lately, and have noticed some interesting patterns in Claude Code around discovering its own capabilities and limitations.

Organizations have been pushing official company skills out the door because skills look like just a markdown file, and that seems simple and trivial.

In the last ~6 months, Agent Skills have gone from a new feature introduced by Claude Code to a widely adopted paradigm across the industry.

As I have been re-scoring documentation sites with my updated afdocs tool, I have had the opportunity to see a snapshot of various docs sites a few weeks apart as the industry is starting to pay a lot more attention to how to make documentation agent-frie…

I'm working on a new research report that starts by scoring a wide cross-section of documentation sites with afdocs.

If you're a documentation team trying to figure out what "agent-ready" means for your site, you've probably noticed that several different organizations are now offering to score you.

With my work on the Agent-Friendly Documentation Spec and the companion AFDocs tool, I've been talking with a lot of people about what all this means.

Almost exactly a month ago, I wrote an article about poking around in my server logs attempting to measure agent web traffic: How to Measure Agent Web Traffic.

After sharing my article yesterday about the verification gap in AI content pipelines, someone on LinkedIn replied: "I'll take humble human mistakes over confident machine gibberish any day."

I've been running an AI-assisted editorial pipeline for about a month now.

Recently, Vercel published an Agent Readability Spec (Timothy Jordan, last updated March 23, no publication date), a scoring system for how well websites serve AI agents.

I wrote the other day about the AI news gathering pipeline I set up that collects and tags news items for different downstream consumers.

When I decided I might be doing more than just digging into AI a little, I started to think about how I might want to learn about AI in a more realistic way.

Someone made a feature request on the skill-validator tool: support for the evals/ directory introduced by Anthropic's recent updates to its skill-creator skill.

The Agent Skills spec claims to be "A simple, open format for giving agents new capabilities and expertise."

You shipped your llms.txt.

A month ago, I published an ecosystem-scale analysis of 673 Agent Skills from 41 repositories.

There's a growing body of advice about how to write documentation for AI.

After sharing my recent findings about how agents use docs with the folks at work, one of the first questions (from multiple people!)

Apparently I live in the "agent" space now, so let's talk about what's inside an agent!

With all the writing I've been doing lately around agent-friendly docs, I decided that all new websites I set up will be agent-friendly from the beginning.

When I did the research for my recent Agent Skill research paper, I took two approaches to trying to understand the impact of Skills in developer workflows: take a wide, zoomed-out look at Skills across different segments, verticals, and use cases, and ta…

I've been writing a lot about agents and docs lately, and one thing I keep bumping into in conversations is confusion about what "AI-friendly docs" actually means.

I've been posting a lot of content lately and having a lot of conversations with people in various roles as a result.

After posting about Agent-Friendly Docs, I got some very good questions that I wanted to dig into.

Contents Change, thy name is Agent!

Claude introduced Agent Skills in fall 2025, and they have quickly become the next hot thing in AI-assisted development.

In my last article, I wrote about why we designed a simplified testing framework approach to help technical writers test the code examples in our documentation.

I've written before about why you should test the code examples in your documentation and why your docs team should write the code examples.

My wife has been using a word-diffing tool called dwdiff for years.

After a months-long code example audit process that included: Aligning about definitions and types of code examples Building out tooling to programmatically ingest code examples into a database Creating queries to give us different views of the data Refin…

With our code example audit data ingested into the database, we were no longer constrained to static analysis at the time of parsing the data.

As we worked our way through this initial code example audit process, requirements emerged sporadically.

With over 35,000 code examples, there's no way our docs organization could afford for people to spend time manually assigning a category to each code example.

Having defined categories to better quantify our code examples, and identified the data we wanted to track, we were ready to start the audit - right?

Now that we had defined what we were going to count as a code example, we just needed to count them - right?

When the Education AI team provided an initial count of code examples across our documentation corpus, broken down by programming language, the numbers were much higher than some members of the org expected.

My company uses a docs-as-code workflow.

Apparently writing Shattered Ring a few years ago whetted my appetite for useful tools that do what I want in the way I want.

My team documents a product that represents 9 different SDKs in 9 different programming languages.

My team documents a product that represents 9 different SDKs in 9 different programming languages.

I wrote last month about how to test docs code examples.

A few months ago, I wrote about why you should test docs code examples.

I have been a fan of the folks at Critical Role for many years.

In this final installment in my hackathon series, let's take a look at the MongoDB Charts I made from all the lovely data I've liberated from Google Sheets.

Defining a data model MongoDB is a document database.

One of my favorite things about working at MongoDB is that we do a hackathon once or twice a year.

A few weeks ago, I wrote about the benefits of testing the code examples in your documentation.