Agentic Readiness Assessment

imageExadel AI Agentic Readiness Assessment

Agentic Readiness Assessment is an agent plugin that evaluates a software repository for readiness to be developed and maintained by AI coding agents. It inspects the repository in place and produces an evidence-based readiness scorecard together with actionable recommendations.

Built by Exadel.

Description

The assessment establishes, with evidence, whether an AI coding agent can independently understand this repository, find the right change points, build a reproducible environment, validate its work, and prepare a change for delivery.

It scores 14 areas, weighted, for an applicable maximum of 105 points:

Areas that do not apply to the repository's archetype are marked N/A and subtracted from the maximum, so the normalized score stays comparable across different kinds of repository.

Three gates sit above the score. Gate 1 anchors on setup, Gate 2 on the deliverable, Gate 3 on whichever area holds the archetype's primary verification surface. A gate passes only when its anchor area is fully verified, so a high average can never hide a failed gate.

Evidence, not configuration. A command that was not executed is a claim. The assessment runs safe commands and records each one with its working directory, result and artifacts. A capability is verified only when a check proved it, never because a config file mentions it.

A probe proves the loop. One small reversible edit confirms the repository can actually take a change from edit to green, then it is reverted. Nothing else is modified.

Guardrails have a hard cap. A permission bypass, a blanket allow-all policy, an unguarded secret file or a committed plaintext credential caps area 13 at 2 regardless of what else is in place, and each one becomes its own P0 or P1 fix record. Paths are reported, values never are.

The run produces a status of Ready, Partially ready or Not ready, paired with a verification confidence of High, Medium or Low, so a weak score and a weakly-evidenced score never read the same.

The plugin ships two Agent Skills, both of which run entirely locally, need no backend or MCP server, and send nothing anywhere:

• agentic-readiness-assessment audits the repository in your working directory: can an agent work in it?
• agent-tool-call-latency audits the agents' own tool calls on your machine: how much of their run time is waste? See Agent tool-call latency.

Supported clients

This is a skill written in the open Agent Skills format. It includes native manifests for Cursor-compatible Agent Plugins, Codex, and Claude Code:

• plugin.json for the portable Agent Plugins format used by Cursor;
• .codex-plugin/plugin.json for ChatGPT and Codex;
• .claude-plugin/plugin.json for Claude Code.

The three packages point to the same skills and require no backend or MCP server.

Clients that read the Agent Skills format directly, including Gemini CLI, Antigravity, Zed, Warp, Windsurf and Amp, load each skill from its folder under skills/ with no conversion. A gemini-extension.json manifest is present for Gemini CLI's extension installer.

Installation

Cursor

Once published, install it from the Cursor marketplace.

Claude Code

Add this repository as a marketplace and install the plugin:

claude plugin marketplace add exadel-inc/agentic-readiness-assessment
claude plugin install agentic-readiness-assessment@exadel-agent-plugins

To try it without adding a marketplace, clone the repository and load it directly with claude --plugin-dir ..

ChatGPT and Codex

Public installation will be available after OpenAI review and publication. The native Codex package is already present in the repository for submission and local packaging.

Gemini CLI

gemini extensions install https://github.com/exadel-inc/agentic-readiness-assessment

Or install the skill on its own, without the extension manifest:

gemini skills install https://github.com/exadel-inc/agentic-readiness-assessment --path skills/agentic-readiness-assessment

GitHub Copilot CLI

copilot plugin marketplace add exadel-inc/agentic-readiness-assessment

JetBrains Junie

Open /extensions, go to the Marketplaces tab, choose Add marketplace and paste the repository URL. Junie reads the .claude-plugin/marketplace.json in this repository.

Any client that reads Agent Skills

npx skills add exadel-inc/agentic-readiness-assessment

For Zed, Warp, Windsurf, Amp and anything else that discovers skills on the filesystem, copy skills/agentic-readiness-assessment/ into the client's skills directory, usually .agents/skills/ in the repository you want to assess. skills/agent-tool-call-latency/ audits the machine rather than one repository, so it belongs in the user-level skills directory, such as ~/.agents/skills/.

From source

Clone the repository and point a compatible client at the repository root:

git clone https://github.com/exadel-inc/agentic-readiness-assessment.git

Getting Started

Ask your agent for an assessment from inside the repository you want to evaluate:

• "Run an agentic readiness assessment on this repository."
• "Generate an AI-readiness scorecard for this codebase."
• "How ready is this repo for AI coding agents, and what should we fix first?"

There are no arguments or configuration. The skill reads the repository in your current working directory.

It writes exactly one file: reports/agentic-readiness.md, creating reports/ if it does not exist. That single document holds both the decision content and the supporting evidence, in thirteen fixed sections:

1. Verdict
2. Run and Scope
3. Glossary
4. Readiness Scorecard
5. Mandatory Gates
6. What to Fix
7. What Can Be Delegated Today
8. What Is Already Good
9. Surface Resolution
10. Golden Path
11. Probe
12. Commands Executed
13. Confidence and Limits

Sections 1 to 8 are the decision document, ordered so a reader has the whole readiness picture before reaching the action list. Sections 9 to 13 are the evidence behind it.

Nothing else in your repository is changed. The one exception is the probe, a single reversible edit that is reverted before the report is written.

Example report

examples/fs-demo-project/agentic-readiness.md is a full run against a Next.js 14 application with Prisma and PostgreSQL. It scored 71 of 100, Partially ready, at Medium confidence. The golden path and the test suite verified cleanly; a port conflict on the audit host blocked the database and, with it, the probe. That is the useful case to read, because the report separates what the repository is missing from what this particular machine could not prove.

More runs, and what was redacted before publishing, in examples/.

Agent tool-call latency

Modern coding agents run for hours. Part of that is by design: we hand them genuinely large tasks and expect them to take time. But part of every long run is the agent waiting on its own tools, and some of those tools are slow for reasons nobody chose:

• a poll loop that blocks the agent's turn until the tool's 10-minute cap kills it, and is then run again;
• an end-to-end harness with a fixed debug port or a global lock, so agents in parallel checkouts queue behind each other;
• an approval check or an automatic reviewer that adds a fraction of a second to a few seconds to every cheap command;
• a client release in which a file edit took a second instead of 50 ms;
• a heavy process, such as a headless browser or a renderer, launched again for every screenshot or render.

None of these shows up in a single session. They show up when every tool call of the last month is lined up and measured, which is what this skill does. A repository can pass the readiness assessment and still lose hours a month in its agents' feedback loop; this skill measures that loop as the agents actually ran it.

Ask for it by name: /agent-tool-call-latency in Claude Code, $agent-tool-call-latency in Codex, or "audit my agents' tool-call latency" elsewhere. Add a window or a focus, such as 14 days or a project name. The default is the last 30 days.

The skill:

1. Takes inventory of the agent clients on the machine and their local session history. Claude Code, Codex, T3 Code, Cursor and Antigravity are read by built-in adapters. For any other client the agent writes an adapter to one shared call-record format, and checks that adapter against the client's raw log. A client whose history carries no per-call timing can be recorded live through its pre-tool and post-tool hooks.
2. Measures every call: time by client, category and command pattern, calls ending at a timeout cap, cheap operations compared across clients, permission modes and releases, and automatic-review time.
3. Diagnoses each large pattern, separating the time the work needs from the time it wastes, and confirms each cause on the machine with a benchmark, the client's documentation or the line of code responsible.
4. Stops for your decisions, with fixes ranked by the hours they recover each month and grouped by owner: the repository, the agent environment or the client vendor.
5. Applies the fixes you approve: each config file is backed up first, and each repository change goes through that repository's own workflow.
6. Writes a report to ~/.cache/agent-tool-call-latency/<date>/report.md.

examples/agent-tool-call-latency/report.md is a full run on a developer laptop: 120,896 calls and 282 hours of tool time in 30 days across five clients. Between 24 and 53 of those hours were waste, and another 34 were agents waiting for the user to answer.

It reads session history read-only and never changes or deletes it. The call records it builds keep commands, so calls can be classified, with anything that looks like a secret masked, and point back to the session file each call came from. Records, summaries and the report go to ~/.cache/agent-tool-call-latency/; overhead benchmarks run short headless agent sessions under /tmp/agent-latency-bench/. The scripts need Python 3.9 or later and use the standard library only.

System Requirements

• An agent client that reads the Agent Skills format (see Supported clients).
• No additional runtime dependencies for the readiness assessment, which is prompt-driven.
• Python 3.9 or later for the scripts of agent-tool-call-latency (standard library only).

Data handling and privacy

• The readiness assessment performs read-only analysis of the repository in the current working directory.
• agent-tool-call-latency reads your agent clients' local session history read-only, and writes its records and report under ~/.cache/agent-tool-call-latency/. Its overhead benchmarks run headless agent sessions under /tmp/agent-latency-bench/, which use your model quota and appear in your clients' history. It changes a client's configuration or a repository only to apply a fix or a hook capture that you approved.
• No repository contents are transmitted to any external service by the plugin itself. Your agent client's own model requests are subject to that client's privacy policy.
• The plugin contains no credentials and requires none.

Limitations

The audit machine shapes what can be proven. If a required tool, service, network route or permission is missing on the machine running the assessment, that is recorded as an environment blocker rather than counted against the repository. Those areas score at most half and the run's confidence drops, so the score stays a property of the repository.

Some commands are never run. Anything that pushes, publishes, deploys, runs a production migration, uses real credentials or customer data, calls a paid service, or needs root is refused by design. A refused command is recorded with its class, and the area is scored on the safe evidence that remains.

A locked install that fails caps its own area. If the repository's frozen install cannot complete, the assessment retries once without mutating any resolution file and labels the result an unfrozen fallback. Downstream evidence stays valid, but the setup area scores at most half.

Hard questions get abandoned on purpose. After roughly five attempts on the same unresolved question, the assessment records not determined and scores on the evidence in hand.

Monorepos are audited in full or not at all. Every applicable workspace and component is covered; the assessment will not silently sample a subset. On a very large repository this is the main cost driver.

A Low confidence rating is a real result. When less than half the applicable areas could be executed, or a required probe did not complete, the report says so on its face.

Versioning

The version field in plugin.json is the canonical source of truth. Platform marketplaces require self-contained manifests, so the same value is mirrored in gemini-extension.json, .codex-plugin/plugin.json and .claude-plugin/plugin.json. The skill reads the portable root manifest and records that value as prompt_version in every generated report.

The current version is the version field of plugin.json. MAJOR.MINOR continues the assessment prompt's own revision history, which predates this repository, so reports produced here stay on one timeline with reports produced by earlier revisions of the prompt. PATCH covers packaging changes that leave the prompt untouched.

Bump it as follows:

Set the canonical version and every platform manifest version together:

python3 .github/scripts/sync_versions.py X.Y.Z

Scores are directly comparable across reports sharing the same MAJOR.MINOR. A minor bump may shift scores, so compare across one with care; a major bump breaks the contract, so do not compare across it at all.

A change to agent-tool-call-latency leaves readiness reports comparable, so it is a patch bump. Latency reports record the same version as plugin_version; a change to their sections is called out in CHANGELOG.md.

Describe what changed in the commit message and in CHANGELOG.md, not inside SKILL.md. The revision history lives in git:

git log --follow skills/agentic-readiness-assessment/SKILL.md

Documentation

• Skill definition
• Agent tool-call latency skill, its call-record format and adapter guide
• Example reports
• Publishing guide
• Changelog

Contributing

Contributions are welcomed and greatly appreciated. See CONTRIBUTING.md.

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

After creating your first contributing PR you will be requested to sign our Contributor License Agreement by commenting your PR with a special message.

License

Distributed under the Apache License 2.0. See LICENSE for the full terms and NOTICE for attribution.

What this does not do

The assessment is narrow by design. It audits one repository, on your machine, and hands you a ranked backlog with the evidence behind every line.

It does not fix any of it. It does not look at how your teams actually work. And it will not tell you which of your fifty repositories to start with, or what the whole estate costs you.

Those are the questions people ask us next, so we do them as work:

• Working the backlog. AI-Enabled Product Engineering: engineers who do the remediation alongside your team.
• A portfolio instead of a repository. AI Maturity & Readiness Assessment: the organization-level version of this report, covering people and process as well as code.
• Once the repositories are ready. Exadel Colleague: the AI teammate we put to work inside them.

If any of that would help: exadel.com/contact.

Support

Open an issue for anything about the assessment itself. Security reports go through SECURITY.md.

For anything commercial: exadel.com/contact.

Privacy

Exadel privacy policy and terms. The plugin itself collects nothing and transmits nothing.

Contact

Built by Exadel.