# AINE Readiness Analyzer

> A free skill that audits how ready a codebase is for AI coding agents: 46 checks across 5 areas, a score out of 100, and the fixes ranked by what to do first.

- **Source:** https://ainativesoftware.engineering/readiness
- **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book

A free skill that audits how ready a codebase is for AI coding agents. It runs in one agent, under 10 minutes, answering 46 checks across 5 areas, writing AINE-REPORT.md into the repo, and printing the fixes ranked by what to do first.

- **Checks:** 46
- **Areas:** 5
- **Runtime:** one agent, under 10 minutes
- **Cost:** Free
- **Try it:** https://ainativesoftware.engineering/readiness

## Run on a real repo

Real audits, not estimates: each score comes from a full run against a fresh clone, and the report it wrote is linked beside it. More repos as they are run — or run it yourself and get a number for your own.

- **[supabase/supabase](https://ainativesoftware.engineering/readiness/report/supabase-supabase) — 76/100** — Routed instructions, skills symlinked to one source, 27 pre-merge checks; no single command to prove a change, and a production deploy any agent can run from a laptop. Run 13 August 2026.
- **[home-assistant/core](https://ainativesoftware.engineering/readiness/report/home-assistant-core) — 74/100** — One instruction file symlinked for every agent, six committed skills shared across three vendors, and 19 pre-merge CI jobs; no design reasoning written down in the repo at all, and nothing scanning for secrets. Run 14 August 2026.
- **[nousresearch/hermes-agent](https://ainativesoftware.engineering/readiness/report/nousresearch-hermes-agent) — 72/100** — An instruction file edited the same day as HEAD, 2,910 test files green from a bare clone, and 27 workflows behind one required check; the lint command that blocks the merge is named nowhere an agent reads, and one laptop command ships a release, the docs site and :latest at once. Run 14 August 2026.
- **[anomalyco/opencode](https://ainativesoftware.engineering/readiness/report/anomalyco-opencode) — 67/100** — 19 AGENTS.md files, 723 test files and its own agent reviewing every pull request; no lint or secret scan in the pipeline, and a script called dev: that opens a production shell. Run 14 August 2026.
- **[openai/codex](https://ainativesoftware.engineering/readiness/report/openai-codex) — 65/100** — A deep, specific AGENTS.md and a serious CI gate; nothing written down about why, and no single command to prove a change. Run 13 August 2026.
- **[django/django](https://ainativesoftware.engineering/readiness/report/django-django) — 64/100** — Linters clean on a bare checkout, one word runs every check, 780 tests with no setup at all; the only file at an agent-instruction path is a Copilot review muzzle, and there is no lockfile anywhere. Run 14 August 2026.
- **[langchain-ai/langchain](https://ainativesoftware.engineering/readiness/report/langchain-ai-langchain) — 61/100** — Tests, linters and types all green on a bare checkout, 21 lockfiles pinned and watched, CI on every pull request; no design reasoning anywhere in 3,033 files, and the instruction file hands every session the one-liner that publishes to PyPI. Run 14 August 2026.

## Run it on your repo

1. Install the skill: `npx skills add alfonsograziano/skills --skill aine-readiness-analyzer`. It comes from [alfonsograziano/skills](https://github.com/alfonsograziano/skills).
2. Ask your agent to run it — for example, "Run the AINE readiness analyzer on this repo". It defaults to the current repo and writes the report there.
3. Read AINE-REPORT.md and start with the high-priority, cheapest fixes. Re-run it next month to see the score move.

## How it works

### 01 · Plant the report

The analyzer starts by copying a fixed template into the repo as AINE-REPORT.md. The report file is the method, not just the output: every question has a Proof line that stays visibly empty until it is answered, so no check can be quietly skipped, and the team is left a file they can re-run against later.

### 02 · Read the repo in bulk

Before answering anything, it builds a picture of the repo in a handful of commands: the file listing, the recent git log, then the agent instruction entry point and every file that entry point points at, the README, the manifest or build file, the CI config and the ignore file. Instructions are often spread across several files, with one file routing to the rest, so it follows the pointers and judges the whole set. Five or six reads cover most of the checklist. It works out the stack from what is actually there, not from what is popular.

### 03 · Answer every check with proof

It goes through the checklist top to bottom. Every check is about a capability, never a tool — "is there an automated test suite" rather than "is there jest" — so it holds up in any language. Each one gets a status of PASS, FAIL or N/A, a Proof line citing a real path or command, and, on a FAIL, one concrete fix naming real files. It never claims something without evidence: when it cannot determine something, the proof line says exactly that, and N/A is kept for the checks that could never apply here, never for the ones that failed.

### 04 · Write the file section by section

It answers a whole section, then writes it into AINE-REPORT.md in one edit — five or six edits for the whole report, not forty. When every section is done it fills in the result line at the top: how many checks passed, failed and did not apply.

### 05 · Rank the fixes

It prints the recommendations in chat, sorted into high and low priority, cheapest fix first inside each bucket so you can start today. High priority means an agent working here hits the problem on day one; low means it helps but nothing breaks without it. The detail stays in the file.

## The 46 checks, by area

### Context (10 checks)

Whether an agent lands in the repo already knowing how to build, test and behave here — judged across the whole instruction set, not one file.

- Is there an agent instruction file, and what does it point at?
- Do the instructions name the real build and test commands?
- Does everything they name still exist — the commands, the paths, the files they link to?

### Specs (7 checks)

Whether intent and the reasoning behind it are written down, in a shape a machine can check against.

- Is the thinking written down somewhere durable — specs, RFCs, ADRs or architecture notes?
- Do the specs state acceptance criteria a machine could check?
- Can recent shipped work be traced back to a spec?

### Verification (10 checks)

Whether an agent can prove its own work before it ships — tests, linters, types, and CI that runs before a change lands.

- Is there an automated test suite, in whatever form this ecosystem uses?
- One command that runs every check the project has?
- Does CI run before a change lands, rather than after?

### Tooling (7 checks)

Whether the repeatable jobs and the systems past the repo's edge are reachable from the repo, not from someone's laptop.

- Can an agent reach the outside systems this project depends on — an MCP server or a CLI, committed, not set up per laptop?
- Are there project CLI scripts or task-runner targets for the common jobs?
- Would a bare checkout in a fresh worktree actually run, from the written setup steps alone?

### Safety (12 checks)

Whether an agent can go wrong here without a human seeing it first — secrets, pinned deps, review gates and a way back.

- Are credentials kept out of the repo, with an example env file for the shape?
- Does every action that spends money, destroys data or changes production have a human in the way?
- Is there a way back — can a bad change be undone without a rebuild and redeploy?

## Where this comes from

The 46 checks are the practices from [AI-Native Software Engineering](https://ainativesoftware.engineering/book.md), turned into questions an agent can answer about your repo. For a version you run with your team instead of an agent, take [the maturity assessment](https://ainativesoftware.engineering/assessment.md) or run [the canvas](https://ainativesoftware.engineering/canvas.md).

---

_AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._