What it measures

Agentic Foundation answers a practical question: if someone (human or agent) opens this repo cold, how much friction will they hit?

Each connected GitHub repo gets a 0–100 score built from nine dimensions: docs, tests, CI, structure, agent context files, and similar signals. Lower scores aren’t moral failures. They’re a prioritized to-do list.

The headline number is not “how good your code is.” It measures readiness for AI-assisted development: can an agent find instructions, run tests, understand layout, and work within reasonable context limits?

What’s in this phase

Four screens work together. You can jump between them anytime after onboarding.

Prerequisites

Agentic Foundation needs a connected GitHub App installation. Only repositories you granted at install time appear in the list. If a repo is missing, check GitHub integration for org, access scope, and repository selection.

After onboarding, the platform queues an initial scan for every visible repo. You don’t have to click anything for the first pass. Use Analyze when you want a fresh run after pushing fixes.

How a scan works

1. 1
   Find repos

   Anything your GitHub App can access shows up in the Agentic Foundation list. Repos added or removed in GitHub App settings usually sync within a few minutes.

   Example: Acme installs the app on acme-corp with access to payments-api, web-checkout, and handbook. All three appear on the dashboard after sync.

2. 2
   Queue a scan

   Select repos and click Analyze. The scan runs in the background; you can leave the page. If a scan is already running, the dashboard reuses that run instead of starting a duplicate.

   Example: The first scan for all three repos queues automatically after onboarding. Later, an engineer merges an AGENTS.md into payments-api and clicks Re-scan on that row only.

3. 3
   Read the breakdown

   Overall score plus per-dimension detail on each repo. Open a repo to see individual criteria marked Met, Partial, Gap, N/A, or Blocked.

   Example: payments-api scores 58 (Fair). Agentic Readiness is low (no AGENTS.md), Test Coverage is moderate (Jest present but no CI gate), and Delivery Readiness shows a Dockerfile plus GitHub Actions workflow.

4. 4
   AI Resolution Hub

   Cross-repo list of the highest-impact fixes. Tackle these when you want scores to move.

   Example: The hub surfaces “Add agent instructions” for payments-api and “CI does not run tests” for web-checkout ahead of minor gaps in handbook, because severity and dimension weight rank higher-impact items first.

Connected repos re-scan on roughly a 24-hour cadence. Manual re-scan anytime from the dashboard.

Example: first week with three repos

This walkthrough shows how the four steps play out for a typical team. Names are fictional; the flow matches what you see in the app.

Repo	What it is	Day 1 (auto scan)	After fixes + re-scan
payments-api	Node/TypeScript API	54 Fair. Gaps: no AGENTS.md, thin README, tests not wired in CI.	71 Good after adding AGENTS.md, expanding README build commands, and a test job in .github/workflows/ci.yml.
web-checkout	React SPA	68 Good. Partial: .cursorignore missing; CI runs build but not tests.	76 Good after ignore file and a npm test CI step.
handbook	Internal docs (MkDocs)	82 Excellent. Many delivery rows show N/A (no Dockerfile expected).	Unchanged. Docs repos often score high on hygiene with legit N/A on runtime criteria.

Day 1: GitHub connects during onboarding. Initial scans queue for all three repos. The engineering lead opens AI Resolution Hub and picks the top two items affecting payments-api.

Day 3: A PR merges with AGENTS.md and CI test wiring. They click Re-scan on payments-api. About ten minutes later the score updates and those hub items drop off.

Day 7: Scheduled re-scan runs overnight. No manual action needed unless they pushed more changes.

What a scan inspects

Scans work from a read-only snapshot of the repository file tree at scan time. They do not run your app in production or read live secrets.

Signal category	What we look for	Concrete examples
Agent & contributor docs	Instructions a human or agent can follow on day one	README.md, AGENTS.md, CLAUDE.md, CONTRIBUTING.md
AI tool configuration	Rules, skills, and ignore scope for Cursor or Claude	.cursor/rules/, .cursor/skills/, .cursorignore, .claude/
Build & test entrypoints	Non-interactive commands in docs or CI	npm test, mvn verify, bundle exec fastlane test in README or workflow YAML
Quality & delivery	Lint, tests, containers, deploy config	eslint.config.js, vitest.config.ts, Dockerfile, .github/workflows/
Contracts & governance	APIs and change control	openapi.yaml, CODEOWNERS, branch-protection evidence via GitHub
Context efficiency	Files and docs sized for agent context windows	.cursorignore excluding node_modules/, layered docs under docs/

We do not keep a long-term copy of source code. The snapshot is discarded when scoring finishes. See GitHub integration for the full data-handling summary.

Common repo situations

The rubric adapts to repo type. A mobile app and a backend API are scored against different expectations.

Situation	Example repo	What to expect
Backend / API	payments-api, user-service	Full bars for CI, contracts, observability hooks where they belong in-repo.
Web SPA	web-checkout, admin-portal	Frontend-appropriate tests and delivery; no backend-only tooling required in-repo.
Mobile	acme-ios, acme-android	Xcode or Gradle signals instead of Docker; ignore files should exclude build/ and DerivedData/.
Monorepo	platform with apps/ and packages/	Scored on dominant layout at the root; secondary stacks noted but not double-counted.
Docs-only	handbook, architecture-notes	Delivery and runtime criteria often N/A; they do not count against you.
Infra elsewhere	checkout-service with Terraform in acme-infra	Delivery rows may show Blocked until infra evidence is reachable or documented.
Unfamiliar stack	Legacy COBOL mirror, niche DSL	Scan still runs; confidence may stay low when fewer recognizable signals are found.

N/A is not a penalty. Criteria marked N/A are excluded from that dimension’s score. A docs repo without a Dockerfile is expected, not a gap.

Timing, cadence & limits

Topic	Typical behavior
First scan	Queued automatically after GitHub connect and onboarding.
Scheduled re-scan	About every 24 hours per connected repo.
Manual re-scan	Anytime via Analyze or Re-scan on a repo row.
Scan duration	Usually 5–15 minutes for typical repos; large monorepos can take longer. Progress shows on the dashboard.
Concurrent runs	One active scan per repo at a time; duplicate requests attach to the in-flight run.
Score freshness	Scores reflect the last completed scan. Pushed fixes won’t move numbers until the next successful run.

If a scan fails (GitHub unreachable, tarball error, timeout), the previous score stays visible and the repo shows a failed status. Retry with Analyze once the underlying issue is resolved.

Criterion outcomes (quick reference)

Status	Meaning	Example
Met	Signal present and satisfies the bar.	AGENTS.md with concrete npm test and npm run build lines.
Partial	Something there but incomplete.	README mentions tests but no exact command to copy.
Gap	Expected signal missing. Feeds AI Resolution Hub.	No CI workflow file in a service repo.
N/A	Doesn’t apply to this repo. Excluded from scoring.	No Dockerfile expected for handbook.
Blocked	Couldn’t verify at scan time. Counts as not met until evidence is available.	K8s manifests live in another repo the scanner couldn’t reach.

Confidence on a dimension reflects how much evidence we found, not statistical test coverage. A repo with zero test files produces low confidence on Test Coverage before you even interpret the score.

For how overall and dimension scores combine, see Readiness scores.

Score bands

Band	Range	Rough read
Excellent	85–100	Agents and new hires should settle in quickly.
Good	65–84	Solid; a few targeted fixes left.
Fair	40–64	Meaningful gaps; start with the Resolution Hub.
Needs attention	0–39	Structural issues; don’t ignore the top items.

Bands are guides, not gates. A repo at 72 with a critical Gap in Agentic Readiness may still be painful for agents until that one item is fixed.

What scores don’t measure

Agentic Foundation is deliberately bounded. It does not:

• Judge code correctness, security vulnerabilities, or performance in production
• Replace human code review or compliance audits
• Measure team productivity (that’s under Insights)
• Guarantee an AI agent succeeds on every task. It measures repo affordances, not model quality.
• Penalize you for choosing a stack we don’t have deep heuristics for. Those repos may show lower confidence instead.

Use scores to prioritize documentation, structure, and automation improvements that make both humans and agents more effective.

Next

• Readiness scores
• The 9 dimensions
• AI Resolution Hub
• FAQ