How ready is your codebase for AI agents?
Drop one skill into your repo and let your agent run it. It reads the code the way a new engineer would, answers 46 checks with real evidence, writes AINE-REPORT.md into the repo, and hands you the fixes ranked by what to do first.
- 46 checks
- 5 areas
- Score out of 100
- under 10 minutes
npx skills add alfonsograziano/skills --skill aine-readiness-analyzerRun on a real repo
A well-run project still loses points where it never wrote anything down for an agent — good code and a good harness are not the same thing. Open a row to read the whole report and the run that produced it.
- 01supabase/supabase76
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.
View report → - 02home-assistant/core74
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.
View report → - 03nousresearch/hermes-agent72
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.
View report → - 04anomalyco/opencode67
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.
View report → - 05openai/codex65
A deep, specific AGENTS.md and a serious CI gate; nothing written down about why, and no single command to prove a change.
View report → - 06django/django64
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.
View report → - 07langchain-ai/langchain61
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.
View report →
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.
Run it on your repo
- 01
Install the skill
Run npx skills add alfonsograziano/skills --skill aine-readiness-analyzer in your repo, so every agent and every engineer on the team runs the same audit.
- 02
Ask your agent to run it
No flags, no config. It defaults to the current repo and writes the report there.
- 03
Read AINE-REPORT.md, fix the top of the list
Start with the high-priority, cheapest fixes. Re-run it next month to see the score move.
> Run the AINE readiness analyzer on this repo
Or any of: “audit this repo for agents”, “is my repo ready for Claude / Cursor / Codex”, “what is my AGENTS.md missing”.
How it works
Five steps, one agent, no sub-agents. It works like an auditor who has to show their working: every answer carries the evidence it was based on.
- 01Plant
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.
- 02Read
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.
- 03Judge
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.
- 04Write
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.
- 05Rank
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.
46 checks, 5 areas
Every check asks about a capability, never a tool. “Is there an automated test suite” is the question; jest is one answer out of hundreds. That is what makes the same report work on a Rust crate, a Django app or a shell script from 2009.
Context
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
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
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
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
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?
The 46 checks are the practices from AI-Native Software Engineering, turned into questions an agent can answer about your repo. Want a version you run with your team instead of an agent? Take the maturity assessment or run the canvas.