A rigorously structured, highly TypeScript-native monorepo that is exceptionally well-suited for AI navigation, hindered only by bloated documentation trees and the lack of a central codebase map.
last scored 2026-09-18 · both lenses
Readiness lenses
The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.
How ready the repo is for an AI coding agent to read, build, and operate it.
80 / 10030 of 41 checks passed across 6 categories.
Machine Orientation
85Clear agent instructions and robust setup guidance make this repo straightforward for an AI agent to navigate and build.
The repository provides clear machine-readable orientation through both `CONTRIBUTING.md` and an explicit `AGENTS.md` file that points agents directly to development, package management (`pnpm@11.9.0`), and testing commands. This easily clears the Solid band (70–89), though it falls short of Exemplary due to lacking a dedicated architecture doc or llms.txt.
Reproducible Setup
85Solid, deterministic setup via pnpm and nvm with clear developer documentation.
The repository provides solid reproducible setup signals with a pinned `pnpm-lock.yaml`, an exact `.nvmrc` and `packageManager` field, a devcontainer configuration, and explicit installation/build instructions in CONTRIBUTING.md. Minor gaps include the lack of a top-level .env.example (though none is explicitly required for core library packages) and no dedicated task runner tool beyond nx/pnpm scripts. This clears the Solid band (70–89).
Code Navigability
80Strong monorepo structure with strict TypeScript, though lacking a central codebase map for fast agent orientation.
The repository features a clear monorepo structure with strict TypeScript configuration and conventional layout, but lacks a dedicated architectural map or llms.txt guide to help agents navigate the multi-package ecosystem. This clears the Solid band (70-89) because core standards are strong and structured, though navigation across numerous packages requires trial-and-error discovery.
Verification Surface
75Robust verification infrastructure with CI and test scripts, though lacking a simplified task runner wrapper.
The repository provides extensive verification scripts in package.json (test, lint, type-checking via nx, knip, sherif) backed by 4 GitHub Actions workflows including a dedicated PR checks workflow. This places the repository firmly in the solid band (75/100) for verification surface.
Agent Safety
80Solid agent safety with good secret hygiene and clear agent guidance, missing only an explicit env example and security policy.
Solid secret hygiene with gitignore coverage and no committed secrets, paired with dedicated agent guidance in AGENTS.md, placing this repository in the 70–89 Solid band. Minor gaps include the lack of an explicit .env.example file and SECURITY.md policy document.
Context Economy
75Clean of build artifacts and node_modules, but burdened by a massive tree of generated docs.
Context economy is solid (75/100): dependencies and lockfiles are clean with no committed node_modules or build output, and an AGENTS.md file provides clear guardrails. However, the repository contains a massive number of generated documentation and reference files (over 3,500 files total), which can saturate an agent's context window if navigating without caution.
Machine Orientation
7 checks passed3 problems found
- lowllms.txt present
An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.
Fix: Add an llms.txt pointing at the key docs and entry points.
- lowArchitecture doc
An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
Fix: Add an ARCHITECTURE.md describing the major components and how they fit.
- lowREADME shows usage
A usage/example section tells an agent how the project is actually invoked.
Fix: Add a Usage or Examples section to the README with a runnable snippet.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
- Agent instructions stay lean — A bloated instructions file burns context and measurably hurts more than it helps.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
- Examples directory — An examples/ directory gives an agent runnable, copyable references for the API.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
5 checks passed2 problems found
- mediumREADME documents setup
Explicit install/setup steps are what let an agent go from clone to running.
Fix: Add a Setup/Install section with the exact commands to install and run.
- lowEnv template present
A .env.example tells an agent which configuration keys it must supply to run.
Fix: Ship a .env.example listing every required key with placeholder values.
- Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
- Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
- Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
- Dev container — A .devcontainer gives an agent a one-command, fully-declared environment.
Code Navigability
4 checks passed1 problem found
- lowTyped public API
A declared `types` entry gives an agent typed signatures to anchor an edit on.
Fix: Ship type declarations and point package.json `types`/`typings` at them.
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
- TypeScript strict mode on — Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
- .editorconfig present — An .editorconfig keeps whitespace and encoding consistent, so diffs stay legible.
- Formatter configured — A formatter config (Prettier/Biome/rustfmt/…) keeps style uniform across the tree.
Verification Surface
5 checks passed2 problems found
- lowTask runner present
A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
Fix: Add a Makefile / Taskfile / justfile collecting the common commands.
- lowTypecheck command
A typecheck script lets an agent catch type errors before they ship.
Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- Test command defined — A `test` script is the documented, discoverable way to run the suite.
- Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
- CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
- Build command — A documented build command is the discoverable way for an agent to produce artifacts.
Agent Safety
7 checks passed1 problem found
- mediumSecurity policy
A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
Fix: Add a SECURITY.md stating the disclosure channel and the repo's security rules.
- No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
- No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
- .gitignore covers env files — An ignore rule for .env is what keeps the next careless commit from leaking secrets.
- CODEOWNERS present — CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
- Automated dependency updates — Dependabot / Renovate keeps dependencies patched without a human in the loop.
- .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
2 checks passed2 problems found
- lowGenerated / vendored files marked
A .gitattributes linguist marker tells tools (and agents) what to skip.
Fix: Mark generated/vendored paths in .gitattributes (linguist-generated / linguist-vendored).
- lowNo oversized source file
A single file in the hundreds of KB blows past an agent's effective context window.
Fix: Split the largest files along their natural seams.
- Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
How ready the repo is for a human newcomer to understand, set up, and contribute.
80 / 10024 of 33 checks passed across 6 categories.
First Impression
80Clear purpose and ecosystem context, though a quick inline code example would elevate it to exemplary.
The README clearly states the project's purpose as an async state management and data fetching library for TS/JS and multiple frameworks, includes badges, ecosystem links, and a direct link to docs. This places the project firmly in the Solid band (70-89) for first impression, as it provides a clear scope, purpose, and orientation without being missing or bare, though a direct code usage example in the README itself is absent (relying on documentation links).
Getting Running
85Solid getting-running setup with clear instructions, pinned lockfiles, and standard pnpm/nx commands.
The repository provides explicit setup instructions in CONTRIBUTING.md with pinned pnpm/Node versions (.nvmrc, packageManager), lockfiles (pnpm-lock.yaml), and copy-pasteable install and build commands (pnpm install, pnpm build:all). However, it lacks a dedicated local development env/config template, placing it solidly in the 70-89 band.
Finding Your Way
75Solid navigation framework with clear conventions and entry points, though lacking a dedicated architecture map.
The repository features a clear layout with standard files like CONTRIBUTING.md, AGENTS.md, and CODEOWNERS, but lacks a high-level architecture or structural overview document in the root or docs. This lands the repository in the Solid band (75/100), where newcomers have clear entry points and file organization but lack an explicit structural map for the massive monorepo.
Path to Contribute
85An exceptionally thorough contribution guide and setup process, missing only minor automated template-detection alignment.
The repository features an explicit CONTRIBUTING.md guide with local setup steps (pnpm, nvmrc), structured issue templates, a pull request template, and clear test/build scripts. It achieves Solid status (85/100) because the PR template file exists in the file tree (.github/pull_request_template.md) even though the standard automatic detection flagged it as missing due to path/naming conventions.
Signs of Life
85Actively maintained with robust CI, automated releases, and comprehensive contributor tooling.
The repository exhibits clear signs of active maintenance and sustainability, featuring recent commits up to September 2026, robust CI workflows (.github/workflows/pr.yml, release.yml), automated dependency updates (Renovate), and clear contribution guidelines (CONTRIBUTING.md). It easily clears the Solid band with minor room for perfection given standard open-source issue velocity.
Open Door
65Solid licensing and contributing docs, but missing a Code of Conduct and security policy.
The repository provides a clear MIT license, a comprehensive contributing guide, and issue templates, but completely lacks a Code of Conduct (`CODE_OF_CONDUCT.md`) and a security reporting policy (`SECURITY.md`), landing it in the Workable band.
First Impression
5 checks passed1 problem found
- mediumREADME shows what it does
A usage/example section lets a newcomer see the tool in action before committing.
Fix: Add a Usage or Examples section with a concrete, copy-pasteable example.
- README present — The README is the first screen — with none, a newcomer has nothing to land on.
- Repository description set — The one-line description sets expectations before a newcomer even opens the README.
- Topics set — Topics situate the project's domain at a glance and help a newcomer find it.
- Status badges — Build/version badges signal at a glance that the project is alive and healthy.
- Examples to learn from — An examples/ directory gives a newcomer something concrete to run and adapt.
Getting Running
5 checks passed2 problems found
- highREADME documents setup
Explicit install steps are the difference between a 5-minute start and giving up.
Fix: Add a Setup/Quickstart section with the exact prerequisites and commands.
- lowEnv template present
A .env.example shows a newcomer exactly which settings they must fill in to run it.
Fix: Ship a .env.example listing every required key with placeholder values.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- Prerequisite versions pinned — Unpinned prerequisites are the classic 'works on my machine' first-run failure.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
- One-click dev container — A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
3 checks passed2 problems found
- mediumArchitecture / overview doc
An overview hands a newcomer the map instead of making them reconstruct it.
Fix: Add an ARCHITECTURE.md (or a 'Project layout' README section) naming the key directories.
- lowNo oversized source file
A single thousand-line file is a wall a newcomer bounces off.
Fix: Split the largest files along their natural seams.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
- .editorconfig present — Consistent indentation/encoding keeps the code readable and diffs clean for newcomers.
- Formatter configured — An auto-formatter means a newcomer never guesses the house style.
Path to Contribute
4 checks passed2 problems found
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- lowTask runner
A Makefile / Taskfile gives a contributor a single index of the project's commands.
Fix: Add a Makefile / Taskfile collecting the common dev commands.
- CONTRIBUTING guide — A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
- Issue templates — Issue templates show a newcomer how to file something useful — and that contributions are welcome.
- Test command defined — A documented test command lets a contributor check their change before opening a PR.
- Lint command — A linter lets a first-time contributor catch style issues before review.
Signs of Life
5 checks passed0 problems found
- Tests present — A test suite signals a project that's cared for, not abandoned.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
- Automated dependency updates — Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
- Changelog — A maintained CHANGELOG shows a newcomer the project ships and records its changes.
- Funding configured — A FUNDING config signals an invested, sponsored project — not a one-off dump.
Open Door
2 checks passed2 problems found
- lowCode of conduct
A code of conduct states the social ground rules that make it safe to step in.
Fix: Add a CODE_OF_CONDUCT.md (the Contributor Covenant is the de-facto standard).
- lowSecurity policy
A SECURITY.md tells a newcomer how to report a problem responsibly.
Fix: Add a SECURITY.md describing how to report a vulnerability.
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- License is a standard one — A non-standard or custom license is a legal question mark a newcomer won't resolve.
Where the grip slips
- lowVerification Surface+5 pts if fixed
Missing unified task runner wrapper
Local task runner setup relies entirely on pnpm and nx scripts without a unified wrapper task runner like Justfile or Taskfile for agents.
Fix: Provide a Taskfile.yml or Makefile summarizing the common verification commands (test, lint, types) for quick agent discovery.
- mediumCode Navigability+3 pts if fixed
Missing architecture document or navigation map for monorepo packages
No top-level architecture document or navigation guide (like llms.txt or a codebase map) explaining package and module relationships across the monorepo.
Fix: Add an architecture document or llms.txt at the repository root detailing the packages structure, core entry points, and module boundaries.
- lowReproducible Setup+3 pts if fixed
Missing root .env.example
No .env.example file is present at the root, which could leave agents guessing if environment variables are needed for external integrations or docs generation.
Fix: Add a root .env.example file documenting any optional or required environment variables.
- mediumContext Economy+2 pts if fixed
High file count from generated documentation and reference files
Large volume of auto-generated markdown docs and type references inflate the file tree and token count.
Fix: Ensure agents use targeted file searches or globs rather than reading full directory trees or bulk docs.
- lowMachine Orientation+2 pts if fixed
Missing architecture document or llms.txt
No dedicated architecture document or llms.txt explaining the monorepo package graph layout in depth.
Fix: Add a high-level architecture overview document detailing the layout of packages/ and integrations/.
- lowAgent Safety+1 pts if fixed
Missing .env.example template
No .env.example template file is provided in the repository.
Fix: Add a .env.example file if environment variables are needed for local development or testing.
- lowAgent Safety+1 pts if fixed
Missing SECURITY.md
No SECURITY.md file is present for reporting vulnerabilities.
Fix: Create a SECURITY.md file detailing vulnerability reporting procedures.
Show your score
[](https://latch.fyi/tanstack/query)Share this analysis
https://latch.fyi/tanstack/queryFixed some issues? Re-analyze to measure your progress →
Copy the whole report
Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.