A well-structured NestJS monorepo with solid verification and navigability, though agents would benefit from clearer onboarding guides and environment templates.
last scored 2026-09-13 · 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.
77 / 10026 of 43 checks passed across 6 categories.
Machine Orientation
65Solid codebase structure and package scripts, but lacks dedicated machine-readable agent onboarding instructions.
While NestJS features an extensive test suite and clear package scripts in package.json, it lacks an AGENTS.md or CLAUDE.md file providing dedicated machine-readable onboarding instructions for an AI agent. It clears the Workable band (50–69) because core scripts and structure are present in package.json and CONTRIBUTING.md, but agent guidance is missing.
Reproducible Setup
75Well-structured npm workspaces with complete build and test scripts, missing only containerization and environment templates.
The repository provides a clear Node.js workspace structure with a package-lock.json and defined scripts for building, testing, and linting in package.json. However, it lacks an environment variables template (.env.example) and a container setup (Dockerfile/devcontainer), placing it firmly in the Solid band.
Code Navigability
85Code navigability is strong with a clean monorepo layout and predictable module boundaries.
The repository uses a clear monorepo structure under `packages/` with consistent TypeScript conventions, descriptive package naming, and conventional layout, allowing an AI agent to easily localize and navigate code. Minor gaps include missing explicit tsconfig strict settings in root summary signals, but module boundaries are well defined. Code Navigability easily clears the Solid band.
Verification Surface
85Solid verification surface with Vitest, oxlint, and CircleCI integration.
The repository provides a comprehensive verification surface with Vitest tests, oxlint linting, TypeScript build checking, and a detailed CircleCI workflow (.circleci/config.yml) covering unit, integration, and sample tests. This clears the Solid band cleanly, as an agent can easily run npm test, npm run lint, and npm run build locally to verify its changes.
Agent Safety
60Secure secret hygiene and SECURITY.md exist, but .env.example and .gitignore environment coverage are missing.
The repository has no committed environment files or secret-shaped hits, and includes a SECURITY.md file, but lacks an .env.example template and its .gitignore does not explicitly cover .env files. Because the essentials exist with named gaps, this lands firmly in the Workable (50–69) band.
Context Economy
85Clean workspace boundaries and proper ignore configurations keep context pollution minimal for agents.
The repository manages context effectively with clean build artifacts and well-structured source code, clearing the Solid band (70-89). However, lack of explicit `llms.txt` or a high-level architectural overview document prevents it from reaching exemplary status.
Machine Orientation
6 checks passed3 problems found
- mediumAgent instructions file
AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
Fix: Add an AGENTS.md naming the entry points, the build/test commands, and the house conventions.
- 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.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- 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.
- README shows usage — A usage/example section tells an agent how the project is actually invoked.
- 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
4 checks passed3 problems found
- lowVersion pins are exact
A floating pin (a bare major, or a range) still drifts between installs.
Fix: Pin to an exact or minor version, not a floating range.
- 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.
- lowDev container
A .devcontainer gives an agent a one-command, fully-declared environment.
Fix: Add a .devcontainer so the toolchain is declared, not assumed.
- 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.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
- README documents setup — Explicit install/setup steps are what let an agent go from clone to running.
Code Navigability
2 checks passed3 problems found
- lowTypeScript strict mode on
Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Fix: Turn on `strict` in tsconfig.json.
- low.editorconfig present
An .editorconfig keeps whitespace and encoding consistent, so diffs stay legible.
Fix: Add an .editorconfig pinning indentation, charset, and final-newline.
- 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.
- 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
6 checks passed5 problems found
- medium.gitignore covers env files
An ignore rule for .env is what keeps the next careless commit from leaking secrets.
Fix: Add `.env` (and `.env.*`) to .gitignore.
- mediumPolicy names the threat model
A scanning agent aims at what the repo says it is defending, and where untrusted input crosses in.
Fix: Describe the threat model and trust boundaries in SECURITY.md — what is attacker-controlled, and where it reaches trusted code.
- mediumPolicy scopes what counts as a finding
With no reportable-finding bar and no out-of-scope list, an automated scan returns noise nobody triages.
Fix: State in SECURITY.md what counts as a reportable finding, and what is out of scope or accepted risk.
- lowCODEOWNERS present
CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
Fix: Add a CODEOWNERS file marking the sensitive paths.
- lowPolicy gives severity context
Severity judged against this system beats a generic rating an agent had to guess at.
Fix: Say in SECURITY.md how severity is judged here — what makes a finding critical for this system.
- 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.
- 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.
- Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
3 checks passed1 problem found
- 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.
- Generated / vendored files marked — A .gitattributes linguist marker tells tools (and agents) what to skip.
How ready the repo is for a human newcomer to understand, set up, and contribute.
77 / 10025 of 33 checks passed across 6 categories.
First Impression
85Solid first impression with clear purpose and links, though an inline code example would complete the picture.
The repository clears the Solid band (85 score) because the README clearly explains the framework's purpose, scope, and philosophy while pointing to comprehensive external docs, though an inline quickstart or code example in the README itself would push it to exemplary.
Getting Running
65Workable setup with standard npm tooling, but lacks local development instructions in the README.
The repository has clear package setup with a package-lock.json and npm scripts for build, test, and lint, but lacks local development setup instructions or an env template in the README. This places it in the Work workable band (50–69).
Finding Your Way
65A massive monorepo layout with clear directory divisions, though lacking an explicit architecture map to navigate its thousands of files.
The repository provides a conventional monorepo layout with clear module boundaries under packages/ and integration/, but lacks an explicit architecture document or overview map to guide newcomers through the 2,300+ files. This places it firmly in the workable band where essentials exist but require discovery through source inspection.
Path to Contribute
82Solid contributor pathway with comprehensive guidelines, templates, and testing commands.
The repository provides an explicit and robust contribution pathway including a detailed CONTRIBUTING.md guide, structured issue templates, a PR template, a security policy, and standard development scripts in package.json. This clears the Solid band cleanly, with minor gaps such as missing a local env template file or dev container configuration.
Signs of Life
85Actively maintained repository with robust CI, dependabot, and recent commit activity.
The repository clearly demonstrates robust signs of life with recent commits (pushed September 2026), active CI pipelines via CircleCI, Dependabot configuration, and complete issue/PR templates. This comfortably places it in the Solid band (70–89).
Open Door
85Legally and socially safe to step into with a clear MIT license, code of conduct, and contribution guidelines.
The repository clearly provides a standard MIT license, a Contributor Covenant Code of Conduct, and a CONTRIBUTING.md guide with community and issue/pr guidelines. Additionally, support channels like Discord and security reporting are explicitly documented in the README and SECURITY.md. This firmly places the repository in the Solid band (70-89).
First Impression
6 checks passed0 problems found
- 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.
- README shows what it does — A usage/example section lets a newcomer see the tool in action before committing.
- Examples to learn from — An examples/ directory gives a newcomer something concrete to run and adapt.
Getting Running
4 checks passed3 problems found
- 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.
- lowOne-click dev container
A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
Fix: Add a .devcontainer for a one-click, batteries-included environment.
- lowVersions pinned exactly
A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Fix: Pin prerequisites to an exact or minor version, not a floating range.
- 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.
- README documents setup — Explicit install steps are the difference between a 5-minute start and giving up.
Finding Your Way
2 checks passed3 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.
- low.editorconfig present
Consistent indentation/encoding keeps the code readable and diffs clean for newcomers.
Fix: Add an .editorconfig pinning indentation, charset, and final-newline.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
- Formatter configured — An auto-formatter means a newcomer never guesses the house style.
Path to Contribute
5 checks passed1 problem found
- 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.
- Pull-request template — A PR template tells a first-time contributor what a good change includes.
- 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
4 checks passed1 problem found
- lowChangelog
A maintained CHANGELOG shows a newcomer the project ships and records its changes.
Fix: Keep a CHANGELOG.md (e.g. the Keep a Changelog format).
- 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.
- Funding configured — A FUNDING config signals an invested, sponsored project — not a one-off dump.
Open Door
4 checks passed0 problems found
- 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.
- Code of conduct — A code of conduct states the social ground rules that make it safe to step in.
- Security policy — A SECURITY.md tells a newcomer how to report a problem responsibly.
Where the grip slips
- mediumMachine Orientation+4 pts if fixed
Missing AGENTS.md or CLAUDE.md guidance file
No AGENTS.md or CLAUDE.md file is present to guide AI coding agents on build, test, and contribution workflows.
Fix: Create an AGENTS.md file summarizing the primary build (`npm run build`), test (`npm test`), lint (`npm run lint`), and package layout conventions.
- mediumAgent Safety+3 pts if fixed
Missing .env.example template
No .env.example or template file is provided for configuration, which can lead agents to guess required environment variables.
Fix: Add a robust .env.example file documenting all expected environment variables.
- lowReproducible Setup+3 pts if fixed
Missing containerized setup
No Dockerfile or devcontainer configuration is provided for containerized agent execution.
Fix: Add a Dockerfile or devcontainer configuration to standardize the runtime environment.
- lowVerification Surface+3 pts if fixed
Missing dedicated typecheck npm script
Typecheck verification script relies on tsc -b but there is no dedicated npm run typecheck script in package.json.
Fix: Add a `"typecheck": "tsc -b --noEmit"` script to package.json.
- mediumAgent Safety+2 pts if fixed
.gitignore does not explicitly cover .env files
The .gitignore file does not explicitly ignore standard .env files, risking accidental secret leakage if local environment files are created.
Fix: Add .env, .env.local, and related environment file patterns to .gitignore.
- lowReproducible Setup+2 pts if fixed
Missing environment template
No .env.example or environment configuration template is present.
Fix: Add a .env.example file documenting expected configuration variables.
- lowCode Navigability+2 pts if fixed
Implicit strict TypeScript signal
Root tsconfig strictness is not explicitly marked in standard config signals.
Fix: Ensure tsconfig.json explicitly sets strict mode flags and documents them for agent context.
- lowContext Economy+1 pts if fixed
Missing LLM orientation guide (llms.txt)
No dedicated LLM orientation file (llms.txt) is provided to guide agents on package architecture and workspace relationships.
Fix: Create an llms.txt at the repository root outlining the monorepo structure and core packages.
Show your score
[](https://latch.fyi/nestjs/nest)Share this analysis
https://latch.fyi/nestjs/nestFixed 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.