Product · WeaveAI Ready
Is your repo ready for coding agents?
You are handing your codebase to autonomous agents. Most repos were never built for it — undocumented commands, unpinned dependencies, no tests an agent can trust. Ready scores yours in under three minutes, shows you exactly what is blocking automation, and can open the pull request that fixes it.
Your first full run is free — every finding, all 8 sections. Packs from $14.99.
87
deterministic checks across 8 sections, plus a real agent's judgment on top
< 3 min
from URL to a scored, evidence-backed report — re-scans of an unchanged commit are instant
0 bytes
of your source stored — the sandbox is destroyed after the scan
This is the whole thing. Nothing withheld.
A real scan of sindresorhus/p-limit — 30 findings, per-category rationale, and the .mcp.json for its stack. Scroll it. Then go check the repo yourself.
24/100
Grade F — Hostile to agents
9/87 deterministic checks passed
Sections
No AGENTS.md, CLAUDE.md, .claude dir, skills, or MCP config exist anywhere. Partially mitigated by index.js being ~130 lines and self-explanatory, but nothing documents the compound `test` script (xo && ava && tsd, package.json:23) as an all-or-nothing gate, the ESM-only `type:module` constraint, or that no lockfile is committed by design (.npmrc). An agent must rediscover these from scratch every session.
CI (.github/workflows/main.yml) is real, runs Node 20/22/24, matches engines>=20 in package.json. xo lint is genuinely enforced but only inside the compound test script, not a standalone lint command, so it's easy to miss. No lockfile is committed (.npmrc:1, yarn.lock gitignored) — deliberate for a library but reduces install reproducibility. .editorconfig, .gitignore, and license are clean.
readme.md and recipes.md are unusually accurate: every documented API (pLimit, limitFunction, activeCount, pendingCount, clearQueue, concurrency, map, rejectOnClear) matches index.js/index.d.ts exactly. But there's no CONTRIBUTING.md, changelog, or architecture note telling an agent that readme.md/recipes.md/index.d.ts must be updated together when the API changes.
The deterministic 0/12 undersells this: test.js has 24 genuinely behavioral ava tests covering concurrency ceilings, timing windows, error propagation, AsyncLocalStorage context, and dynamic concurrency changes — not hollow smoke tests. index.test-d.ts adds tsd type-contract tests. It scores 0 only because there's no test/ dir, coverage tooling, or fixtures, which are genuinely absent, not because the tests are weak.
.gitattributes (text=auto eol=lf) and a minimal .gitignore (node_modules, yarn.lock) are correctly scoped for a dependency-free library with no build output or vendored code to steer an agent away from.
No committed prompts or skills exist. Appropriate for a ~130-line single-purpose library — no recurring workflow here would benefit from a reusable skill.
No MCP config exists and none is warranted — the project has no database, external API, or service dependency for an MCP server to reflect.
No AI/LLM SDK dependencies in package.json, consistent with this being a plain concurrency-limiting utility whose only runtime dependency is yocto-queue.
Findings (30)
package.json:23 defines `test` as `xo && ava && tsd` — three distinct tools chained so any one failing fails CI, and package.json:13 sets `type: module` (ESM-only, no CJS fallback). Neither invariant is written down anywhere; an agent must infer both from package.json alone every session, and a naive CJS-style change would only surface as a failure deep in the chain.
→ Add a minimal AGENTS.md stating: run `npm test` (lint+test+type-check combined), package is ESM-only, no lockfile is committed by design.
package.json.npmrc:1 sets `package-lock=false` and yarn.lock is explicitly gitignored (.gitignore:2). This is a deliberate sindresorhus-library convention, but it means `npm install` can resolve different transitive versions of yocto-queue/ava/xo/tsd run-to-run, giving an agent nothing to diff against when a CI run fails for a dependency-related reason.
→ If reproducibility for agent-driven CI debugging matters, consider documenting the no-lockfile convention explicitly (e.g., in an AGENTS.md) so it isn't mistaken for an oversight.
.npmrctest.js sits at repo root rather than under test/ or tests/, so the check-ai `test-dir` check fails and scores testing 0/12. In reality test.js contains 24 ava tests asserting concurrency ceilings, timing windows (e.g. lines 10-27), error propagation (lines 118-136), and AsyncLocalStorage context propagation (lines 45-58) — a genuine safety net, not a hollow smoke test.
→ No code change needed for test quality, but an agent orienting itself should be told (e.g. in an AGENTS.md) that test.js at the repo root is the real suite, since directory-convention scanners will miss it.
test.jspackage.json has no c8/nyc coverage script, so nothing quantifies whether a change actually exercises the touched code path. test.js:196-197 already has a Node-version-conditional test skip (`process.versions.node.startsWith('20.')`) that could silently rot without coverage visibility.
→ Add a `coverage` script (e.g. `c8 ava`) so an agent can verify new code paths are actually exercised before proposing a change.
package.jsonreadme.md and recipes.md currently match index.js/index.d.ts exactly, but nothing documents that this must be maintained by hand — e.g. a change to limitFunction (index.js:117-121) has no written signal that readme.md's API section and recipes.md need corresponding updates.
→ Add a short CONTRIBUTING.md noting that readme.md, recipes.md, and index.d.ts must be kept in sync with index.js on any API change.
readme.mdxo is a devDependency and is genuinely enforced, but only as part of the compound `test` script (package.json:23: `xo && ava && tsd`). There is no standalone `lint` script, so an agent scanning package.json scripts for a fast style-check before proposing a diff won't find one.
→ Add a standalone `lint` script (e.g. `"lint": "xo"`) so agents can run static analysis without paying for the full ava+tsd suite.
package.json`git log` shows a single commit (42599eb, "Fix typo") with no type prefix. There isn't enough history in this checkout to judge whether the check-ai commit-messages/conventional-commits failures reflect real project practice or just a shallow/squashed snapshot.
→ Treat the commit-message and conventional-commits deterministic failures as inconclusive given the truncated history available here rather than a confirmed hygiene gap.
check-ai's `has-any-agent-tool` check did not pass (worth 20 points in agent_configs).
→ Add At least one AI tool configured — agents look for it and fall back to guessing without it.
check-ai's `agents-md` check did not pass (worth 10 points in agent_configs).
→ Add an AGENTS.md with build/test commands, invariants, and the files automation must not touch. This is the single highest-leverage file for agent readiness.
check-ai's `agents-md-quality` check did not pass (worth 5 points in agent_configs).
→ Expand AGENTS.md — an agent needs runnable commands, not a description. Include setup, test, lint, and the project's non-obvious rules.
check-ai's `agents-md-nested` check did not pass (worth 4 points in agent_configs).
→ Add Nested AGENTS.md — agents look for it and fall back to guessing without it.
check-ai's `agents-dir` check did not pass (worth 4 points in agent_configs).
→ Add .agents/ directory — agents look for it and fall back to guessing without it.
check-ai's `agents-skills` check did not pass (worth 4 points in agent_configs).
→ Add .agents/skills/ — agents look for it and fall back to guessing without it.
check-ai's `claude-md` check did not pass (worth 3 points in agent_configs).
→ Add CLAUDE.md — agents look for it and fall back to guessing without it.
check-ai's `env-example` check did not pass (worth 3 points in repo_hygiene).
→ Add a .env.example listing every required variable (names only, no values) so an agent can configure the project without reading your secrets.
check-ai's `linter` check did not pass (worth 4 points in repo_hygiene).
→ Add a linter config so an agent's output matches your conventions instead of its defaults.
check-ai's `formatter` check did not pass (worth 3 points in repo_hygiene).
→ Add a formatter config — without one, agent diffs are noisy with unrelated whitespace churn.
check-ai's `scripts` check did not pass (worth 4 points in repo_hygiene).
→ Add Standard scripts — agents look for it and fall back to guessing without it.
check-ai's `devcontainer` check did not pass (worth 3 points in repo_hygiene).
→ Add Dev container — agents look for it and fall back to guessing without it.
check-ai's `commit-messages` check did not pass (worth 3 points in repo_hygiene).
→ Add Descriptive commits — agents look for it and fall back to guessing without it.
check-ai's `conventional-commits` check did not pass (worth 2 points in repo_hygiene).
→ Add Conventional commits — agents look for it and fall back to guessing without it.
check-ai's `dockerfile` check did not pass (worth 2 points in repo_hygiene).
→ Add Dockerfile / docker-compose — agents look for it and fall back to guessing without it.
check-ai's `task-runner` check did not pass (worth 2 points in repo_hygiene).
→ Add Makefile / Justfile / Taskfile — agents look for it and fall back to guessing without it.
check-ai's `type-safety` check did not pass (worth 3 points in repo_hygiene).
→ Add Type safety config — agents look for it and fall back to guessing without it.
check-ai's `version-pinning` check did not pass (worth 2 points in repo_hygiene).
→ Add Runtime version pinning — agents look for it and fall back to guessing without it.
check-ai's `contributing` check did not pass (worth 2 points in grounding_docs).
→ Add CONTRIBUTING.md — agents look for it and fall back to guessing without it.
check-ai's `architecture-doc` check did not pass (worth 4 points in grounding_docs).
→ Add Architecture doc — agents look for it and fall back to guessing without it.
check-ai's `tech-stack-doc` check did not pass (worth 3 points in grounding_docs).
→ Add Tech stack doc — agents look for it and fall back to guessing without it.
check-ai's `ai-requirements` check did not pass (worth 3 points in grounding_docs).
→ Add AI requirements / PRDs — agents look for it and fall back to guessing without it.
check-ai's `llms-txt` check did not pass (worth 3 points in grounding_docs).
→ Add llms.txt — agents look for it and fall back to guessing without it.
Assessment
p-limit is a small, mature, single-purpose ESM library with strong code-level fundamentals that the raw deterministic scores understate: readme.md and recipes.md match index.js/index.d.ts exactly, CI (.github/workflows/main.yml) genuinely runs across Node 20/22/24, and test.js is a real behavioral suite (24 ava tests covering concurrency, timing, error propagation, async context) despite scoring 0 on directory-convention checks. The real agent-readiness gap is meta-guidance: there is no AGENTS.md/CLAUDE.md anywhere, so an agent must rediscover every session that `npm test` chains xo+ava+tsd as one gate, that the package is ESM-only, and that no lockfile is committed by design. Repo hygiene is otherwise clean but lacks a standalone lint script and any CONTRIBUTING guidance. MCP, AI-deps, and prompts/skills categories are correctly near-zero because none are applicable to a dependency-free utility library — that reflects appropriate scope, not neglect.
Recommended MCP servers
Work with issues, pull requests, and CI runs on GitHub.
Re-scan this repo for agent readiness and fetch MCP recommendations.
{
"mcpServers": {
"github": {
"url": "https://api.githubcopilot.com/mcp/"
},
"weaveai-ready": {
"url": "https://app.weaveai.dev/ready/api/mcp",
"headers": {
"Authorization": "Bearer ${WEAVE_READY_API_KEY}"
}
}
}
}One of the most-downloaded libraries on npm, written by one of its best maintainers — and it scores 24/100. Not because the code is bad: because nothing about it is legible to agents. That is the gap Ready measures.
A confused agent is the expensive agent.
Agents pay for every turn they spend rediscovering what your repo never wrote down — in tokens, in latency, and in context they no longer have for the actual task.
Observed — efficiency
Where your agents' turns actually go.
We turned a coding agent loose on a popular, genuinely well-maintained npm library with no AGENTS.md. These are its first 13 tool calls, verbatim — every one re-deriving a fact a context file states in a single read. Your agents repeat this at the start of every session, in every repo, before any real work begins.
- 1find . -maxdepth 2 | sort
- 2find . -iname '*.yml' -o -iname '*.yaml'
- 3Read package.json
- 4Read .github/workflows/main.yml
- 5Read readme.md
- 6Read test.js
- 7Read index.js
- 8Read .npmrc
- 9cat .editorconfig · head license
- 10git log --oneline · cat index.d.ts
- 11ls -la .github
- 12ls -la . · cat security.md
- 13git log --all --oneline | wc -l
- →13 of 13 turns spent orienting. Zero spent working.
Source: verbatim glass-box trace from a real agent session on a public npm library with no agent configuration, July 2026. Every Ready report includes this trace for your own repo.
Published — token cost
Stable context is discounted context.
A correct, stable AGENTS.md does more than save turns — it is a cacheable prefix. Orientation your agents currently re-buy at full price on every session becomes a one-time write and a cheap cached read. The numbers below are Anthropic's own published figures for prompt caching on long, stable prompts.
−90%
cost on cached prompt content
−85%
latency on long prompts
The catch: caching only pays on context that is stable and correct. A missing AGENTS.md caches nothing; a wrong one caches misinformation. Ready scores whether yours exists, whether it tells the truth — and writes it when it doesn't.
Source: Anthropic, "Prompt caching" — "reducing costs by up to 90% and latency by up to 85% for long prompts" (claude.com/blog/prompt-caching, checked July 2026). Savings apply to cached prompt content; actual figures depend on your provider and usage.
“LLM performance degrades as context fills. When the context window is getting full, Claude may start “forgetting” earlier instructions or making more mistakes.”
Anthropic — Claude Code best practices
Orientation your repo forces on every session pollutes the context the agent needs for the actual task.
“CLAUDE.md is a special file that Claude reads at the start of every conversation. This gives Claude persistent context it can't infer from code alone.”
Anthropic — Claude Code best practices
A correct context file answers once what your agents otherwise re-derive every single session.
“Think of AGENTS.md as a README for agents … used by over 60k open-source projects.”
agents.md — OpenAI Codex, Google Jules, Cursor, Factory · Linux Foundation
The files Ready scores — and writes for you — are the industry standard, not our invention.
Paste a URL. Read the truth.
No install, no configuration, no GitHub app for public repos. The scan runs in a sandbox that is destroyed when it finishes.
Paste a repository URL
No install, no login, no GitHub app. Public repos scan straight from the URL — you can have a score before you finish reading this page.
An agent audits it in a sandbox
We shallow-clone into an ephemeral container, run the deterministic checks, then turn a coding agent loose on the code to judge what a checklist cannot. The container is destroyed on exit.
Get the score — then the fix
Read every finding with file-level evidence, copy the .mcp.json for your stack, and let the fix agent open a guardrailed pull request that raises the score.
87 checks. 8 sections. One honest number.
The deterministic layer anchors every score — files, lockfiles, config quality, secret patterns — and a real coding agent judges what a checklist cannot, clamped so it can adjust the evidence but never overrule it.
Agent configs
AGENTS.md, CLAUDE.md, rules and skills — and whether they say anything useful. A config file that exists but answers nothing scores like it doesn't. The single heaviest section.
Repo hygiene
Lockfiles, linter, formatter, CI, devcontainer, license, conventional commits. If installs and checks are not reproducible, an agent cannot tell its own bug from drift. A committed credential caps this section outright.
Grounding docs
README quality, architecture and conventions docs, llms.txt, changelog. Not 'is there a README' — would the documented commands actually work if an agent ran them today?
Testing
Tests are an agent's safety net. We check that they exist, that they assert real behavior rather than snapshots, and that one command runs them.
AI context & dependencies
Scoped ignore files that steer agents away from generated code and vendored trees, and whether the project's AI SDK usage is discoverable at all.
Prompts, skills & MCP
Committed prompts and skills your team reuses, and a .mcp.json that reflects what the project actually depends on. We generate the .mcp.json for you.
Weights are each section's share of the 170-point deterministic budget — the engine is open source, so the rubric is auditable.
A score you can act on the same day.
The report is not a grade. It is a work order — with the fixes attached.
Zero code persistence
Your source is cloned into a container that is torn down when the scan exits. We keep the score, the findings, and the file paths they cite — never file contents.
MCP servers, chosen for your stack
The report detects what you actually use — Supabase, Playwright, Postgres, Sentry — and hands you a ready-to-paste .mcp.json, so your agents get the right tools on day one.
A fix agent with guardrails
The PR agent may only touch AGENTS.md, .mcp.json, .env.example, CI, and .gitignore. It cannot delete files, cannot edit source, cannot push to your default branch — and the score must provably improve or nothing ships.
Private repos never leave your CI
The packaged GitHub Action runs the identical scan inside your own pipeline with your own model keys. Only the code-free JSON report comes back to your dashboard.
Pay per run, not per seat.
No subscription. Your first full run is free, a run costs $1.50 in a pack — and re-scanning an unchanged commit never costs a run at all.
Free
$0 1 full run per account
The complete report, once
- One full scan — every finding, all 8 sections
- 87 deterministic checks + agent judgment
- Ready-to-paste .mcp.json for your stack
- Shareable report link
Run pack
$14.99 10 runs · $1.50 a run
Scan, fix, re-scan — prove the score moved
- 10 full scans across any repos
- Re-scans of an unchanged commit are free — they don't spend a run
- Glass-box trace on every report
- Agent fix PR — $29 add-on, guardrailed, before/after score in the PR
Enterprise
Let's talk for teams that never want a 24/100 again
Readiness as a pipeline, not an audit
- CI gate in every repo — scans run in your pipeline, code never leaves it
- Drift watch: scheduled re-scans, alerts when a score drops
- Fix PRs at fleet scale, on your BYOK model keys
- MCP access so your own agents scan, read, and act on reports
Scanning private repos? The GitHub Action runs inside your own CI with your own model keys — your code never leaves your infrastructure.
Questions engineers ask us.
Direct answers, no hedging.
What is agent readiness?
Agent readiness is how productively an autonomous coding agent — Claude Code, Cursor, Droid — can work in your repository. It is not code quality. A beautifully written codebase with no lockfile, no AGENTS.md, and no runnable test command is hostile to an agent: it cannot install the project reproducibly, cannot learn your conventions, and cannot verify its own changes.
How is this different from a linter or a code-quality tool?
A linter reads your source and judges style. Ready judges the scaffolding around your source — the agent configs, docs, tests, lockfiles, CI, and MCP configuration that decide whether automation can operate safely. 87 deterministic checks across 8 sections anchor every score, and a real coding agent reads your code to answer what a checklist cannot: do the documented commands match reality, do the tests assert anything meaningful. The agent can adjust the evidence but never overrule it, and every report ships with the full trace of how the score was reached.
Is my code stored anywhere?
No. Public repos are cloned into an ephemeral container that is destroyed when the scan finishes. We persist the score, the findings, and the file paths they cite — never file contents. Private repositories never reach us at all: the GitHub Action runs the identical scan inside your own CI with your own model credentials and posts back only the code-free JSON report.
What does the fix PR actually change?
It adds the agent-facing scaffolding: an AGENTS.md written from your report, a .mcp.json for your detected stack, a .env.example, a minimal CI workflow, and missing .gitignore entries. It is hard-limited to those paths — it cannot modify source, cannot delete files, cannot push to your default branch, and the deterministic score must improve before the branch is pushed at all.
Can my agents run scans themselves?
Yes. Ready is also an MCP server. Mint an API key and your coding agent can call scan_repo, get_scan_status, get_report, get_scan_trace, and get_mcp_recommendations directly — so it can audit a repository, read the findings, inspect how the score was reached, and act on it without a human in the loop.
What do I get for free?
One full run per account — the complete report, not a teaser: every finding with file-level evidence, all 8 section scores with the agent's rationale, and the .mcp.json for your stack. After that, runs are $1.50 in a 10-pack. Re-scanning a commit that hasn't changed is always free and never spends a run.
How do teams roll this out across many repos?
The enterprise plan turns readiness from a one-time audit into a pipeline: the GitHub Action gates every repo's CI with your own model keys (code never leaves your infrastructure), scheduled re-scans watch for drift and alert when a score drops — new repos, rotted AGENTS.md, a lockfile someone deleted — and the fix agent opens guardrailed PRs across the fleet. Talk to us and we'll scope it to your org.
Start Now
Your agents are already in this repo. Find out how they are doing.
One URL, one score, zero setup. If you do not like what you see, the fix agent will open the pull request for you.