A monumental codebase whose legendary subsystem organization keeps it navigable for agents despite the complete absence of modern containerized setups or automated verification pipelines.
last scored 2026-09-17 · 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.
63 / 10013 of 38 checks passed across 6 categories.
Machine Orientation
60Extensive documentation and README exist, but an explicit AGENTS.md is missing for machine orientation.
The repository features a clear top-level README and comprehensive architecture and process documentation in Documentation/, but lacks a dedicated AGENTS.md or CLAUDE.md file specifying machine-readable entry points for AI agents. This places it in the Workable band (50–69), as essentials exist across extensive documentation files but lack concise, agent-first onboarding guidance.
Reproducible Setup
60Documented tool requirements exist, but automated reproducible setup and containers are entirely absent.
The repository provides comprehensive documentation for build requirements and procedures (such as Documentation/process/changes.rst), but completely lacks machine-verifiable setup artifacts such as containers, dockerfiles, lockfiles, or pinned dependency versions. Consequently, an AI agent cannot deterministically or automatically set up the build environment without manual system-level package installation. This lands the category squarely in the Workable band.
Code Navigability
65Traditional kernel layout with clear subsystem boundaries and robust formatting aids makes navigation workable despite massive scale.
The Linux kernel uses traditional C source layout with explicit subsystem directories and configuration files like .clang-format, but lacks structured language type strictness signals and standard modern conventions. Code navigation relies heavily on robust formatting configs and documentation trees, clearing the Workable band cleanly.
Verification Surface
60The kernel has powerful build targets, but zero automated CI pipelines or turnkey agent verification runners.
While the repository provides standard kernel test hooks and kbuild targets (tests=yes, taskRunner=yes), there is no automated CI configuration (ci=no), lockfiles, or standard agent-verifiable check suite out of the box. This places the verification surface in the 50–69 Workable band, as essentials exist for human workflows but lack turnkey machine-verifiable feedback loops for an agent.
Agent Safety
60Secret hygiene is sound, but explicit .env exclusion is missing from gitignore.
Secret hygiene is well-managed with no committed env files and private keys like signing_key.pem explicitly excluded in .gitignore, though .env exclusion is not explicitly covered. There are no flagged destructive or irreversible agent operations or prompt-injection hazards in agent-read content. This repository clears the Workable (50-69) band for agent safety essentials.
Context Economy
80Vast code volume cleanly managed by ignore rules, but overwhelming for unindexed agent contexts.
The Linux kernel repository is massive (~67,000+ files) with no generated or vendored bulk tracked in git and proper .gitignore coverage, earning a Solid band for Context Economy despite its monumental scale. The signal-to-noise ratio is kept high by cleanly excluding build artifacts and node modules, though the sheer size of the codebase naturally challenges standard agent context windows.
Machine Orientation
3 checks passed6 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.
- lowTopics set
GitHub topics situate the repo's domain and stack for an agent at a glance.
Fix: Add a few GitHub topics describing the domain and stack.
- 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.
- lowExamples directory
An examples/ directory gives an agent runnable, copyable references for the API.
Fix: Add an examples/ directory with small, runnable usage samples.
- lowContribution conventions are written down
A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Fix: Add a CONTRIBUTING.md stating the branch naming, commit format, and how a change gets reviewed.
- 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.
- Architecture doc — An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
Reproducible Setup
0 checks passed6 problems found
- highLockfile committed
Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
Fix: Commit your lockfile (package-lock.json / pnpm-lock.yaml / Cargo.lock / …).
- mediumRuntime / toolchain pinned
An unpinned runtime makes an agent guess the version a clean environment needs.
Fix: Pin the runtime with .nvmrc / .tool-versions / an engines field / packageManager.
- mediumContainer or dev-container
A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
Fix: Add a Dockerfile, a compose file, or a .devcontainer so the environment is declared, not assumed.
- 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.
- lowDev container
A .devcontainer gives an agent a one-command, fully-declared environment.
Fix: Add a .devcontainer so the toolchain is declared, not assumed.
Code Navigability
2 checks passed2 problems found
- mediumConventional source layout
A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
Fix: Group source under a conventional top-level directory (src/, lib/, app/, …).
- 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.
- .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
2 checks passed5 problems found
- mediumTest command defined
A `test` script is the documented, discoverable way to run the suite.
Fix: Add a `test` script (package.json / Makefile / Taskfile) that runs the suite.
- mediumCI configured
Readable CI is the feedback loop an agent reads to know what 'green' means here.
Fix: Add a CI workflow (e.g. under .github/workflows) that runs the build and tests.
- lowLint command defined
A linter an agent can run catches a class of mistakes before they ship.
Fix: Add a `lint` script and a linter config.
- lowTypecheck command
A typecheck script lets an agent catch type errors before they ship.
Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).
- lowBuild command
A documented build command is the discoverable way for an agent to produce artifacts.
Fix: Add a `build` script that produces the distributable.
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- Task runner present — A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
Agent Safety
4 checks passed4 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.
- 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.
- lowCODEOWNERS present
CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
Fix: Add a CODEOWNERS file marking the sensitive paths.
- lowAutomated dependency updates
Dependabot / Renovate keeps dependencies patched without a human in the loop.
Fix: Enable Dependabot or Renovate.
- 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 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.
59 / 1009 of 32 checks passed across 6 categories.
First Impression
85An exceptionally structured, role-targeted README that acts as a comprehensive map to kernel documentation.
The repository provides an extensive, highly structured README that clearly defines the project's purpose, scope, and target audience through dedicated role-based sections (developers, researchers, security experts, admins, maintainers). It clears the Solid band (70–89) by detailing quick start references, core documentation paths, and community links, though concrete self-contained code examples or demos are absent due to the nature of the kernel source tree.
Getting Running
60Comprehensive documentation guides the kernel build process, but standard modern setup automation and env templates are absent.
The Linux kernel repository provides extensive, well-structured documentation for building and configuring the kernel (such as Documentation/admin-guide/quickly-build-trimmed-linux.rst and Documentation/process/changes.rst), placing it firmly in the Workable band. However, it lacks standard modern repository setup artifacts like an env.example, container/docker configuration, pinned dependency lockfiles, or automated CI pipelines in the file tree, preventing it from reaching higher tiers.
Finding Your Way
60Subsystem documentation is deep and thorough via MAINTAINERS, but a high-level navigational map for the entire tree is missing.
While the Linux kernel repository features a comprehensive MAINTAINERS file and extensive subsystem documentation in Documentation/, it lacks a top-level architectural overview map or standard layout structure (conventionalLayout=no, no dedicated system-level architecture diagram or map outside the sprawling documentation tree). This lands the repository in the Workable band (50–69), where essential subsystem ownership and documentation exist, but building a mental map across tens of thousands of files remains daunting for newcomers.
Path to Contribute
15Kernel documentation is extensive, but GitHub-native machine-readable contribution routes are entirely absent.
The repository lacks a standard CONTRIBUTING guide, issue templates, PR templates, and CI workflows in the root, placing it in the Blocked band (0–29) for contribution onboarding despite extensive underlying documentation. An agent looking for standard GitHub-native contribution points will find no machine-verifiable setup instructions or automated workflows.
Signs of Life
85Actively maintained kernel source tree with continuous commits, lacking automated repository CI configs.
The repository demonstrates continuous maintenance with very recent commits (pushed September 2026) and active development, clearing the Solid band (75–89). However, because automated CI configuration is absent in the repository, it falls short of exemplary status.
Open Door
60Licensing is robustly present, but standard contribution templates and onboarding files are absent.
The repository features a clearly stated license (GPL-2.0 in the COPYING file) and detailed community guidelines referenced in the comprehensive README, clearing the Workable band (50–69). However, it lacks standard open-source newcomer files like CONTRIBUTING.md, issue templates, pull request templates, and a CODEOWNERS file, keeping it at a workable level with named gaps.
First Impression
2 checks passed4 problems 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.
- lowTopics set
Topics situate the project's domain at a glance and help a newcomer find it.
Fix: Add a few GitHub topics describing the domain and stack.
- lowStatus badges
Build/version badges signal at a glance that the project is alive and healthy.
Fix: Add a few status badges (CI, version, license) near the top of the README.
- lowExamples to learn from
An examples/ directory gives a newcomer something concrete to run and adapt.
Fix: Add an examples/ directory with small, runnable samples.
- 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.
Getting Running
0 checks passed6 problems found
- highLockfile committed
Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
Fix: Commit your lockfile so a fresh clone installs the same dependency tree.
- 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.
- mediumPrerequisite versions pinned
Unpinned prerequisites are the classic 'works on my machine' first-run failure.
Fix: Pin the required versions with .nvmrc / .tool-versions / an engines field.
- mediumOne-command environment
A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
Fix: Add a Dockerfile, a compose file, or a .devcontainer for a one-command setup.
- 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.
Finding Your Way
3 checks passed2 problems found
- mediumConventional source layout
A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
Fix: Group source under a conventional top-level directory (src/, lib/, app/, …).
- 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.
- Architecture / overview doc — An overview hands a newcomer the map instead of making them reconstruct it.
- .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
1 check passed5 problems found
- mediumCONTRIBUTING guide
A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
Fix: Add a CONTRIBUTING.md covering dev setup, the test command, and how to submit a change.
- lowIssue templates
Issue templates show a newcomer how to file something useful — and that contributions are welcome.
Fix: Add issue templates under .github/ISSUE_TEMPLATE.
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- lowTest command defined
A documented test command lets a contributor check their change before opening a PR.
Fix: Add a `test` script that runs the suite.
- lowLint command
A linter lets a first-time contributor catch style issues before review.
Fix: Add a `lint` script and a linter config.
- Task runner — A Makefile / Taskfile gives a contributor a single index of the project's commands.
Signs of Life
2 checks passed3 problems found
- mediumCI configured
Green CI on every change tells a newcomer the project is actively kept working.
Fix: Add a CI workflow that runs on every push and pull request.
- lowAutomated dependency updates
Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Fix: Enable Dependabot or Renovate.
- lowFunding configured
A FUNDING config signals an invested, sponsored project — not a one-off dump.
Fix: Add a .github/FUNDING.yml if the project accepts sponsorship.
- Tests present — A test suite signals a project that's cared for, not abandoned.
- Changelog — A maintained CHANGELOG shows a newcomer the project ships and records its changes.
Open Door
1 check passed3 problems found
- lowLicense is a standard one
A non-standard or custom license is a legal question mark a newcomer won't resolve.
Fix: Use a recognised OSI license so reuse terms are unambiguous.
- 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.
Where the grip slips
- mediumVerification Surface+8 pts if fixed
Missing Automated CI configuration
No automated CI pipeline file (.github/workflows/*) is present to verify commits or builds in an isolated environment.
Fix: Add standard CI workflows for build and test validation.
- lowCode Navigability+6 pts if fixed
Missing agent-specific code navigation index files
No strict typing enforcement or standardized automated navigation tooling configuration for AI agents.
Fix: Add editor/agent configuration files specifically tailored to code navigation helpers.
- mediumMachine Orientation+5 pts if fixed
Missing AGENTS.md / CLAUDE.md file
No AGENTS.md or CLAUDE.md file is present to orient AI coding agents on specific build/test/run commands and conventions.
Fix: Create an AGENTS.md file summarizing key build targets, test execution, and kernel development conventions.
- highReproducible Setup+5 pts if fixed
Missing Container or Devcontainer Environment
No container, dockerfile, or devcontainer is provided for automated reproducible setup.
Fix: Add a Dockerfile or devcontainer.json that provisions the required build dependencies (gcc, make, flex, bison, pahole, python3, etc.).
- lowAgent Safety+5 pts if fixed
Missing explicit .env ignore pattern
.gitignore does not explicitly ignore .env files alongside other build and signing secrets.
Fix: Add .env and .env.* to .gitignore.
- mediumReproducible Setup+3 pts if fixed
Unpinned Toolchain and Dependencies
Dependencies and toolchain requirements are documented in text files rather than pinned lockfiles or scriptable environment manifests.
Fix: Provide a setup script or container image pinning the required compiler and tool versions.
- mediumContext Economy+2 pts if fixed
Monolithic scale without agent-focused navigation manifests
Repository contains over 67,000 files across the Linux kernel source tree, which exceeds standard LLM context windows without specialized modular indexing.
Fix: Provide machine-readable subsystem maps, modular index guides, or llms.txt entry points to assist agents in scoping navigation.
Show your score
[](https://latch.fyi/torvalds/linux)Share this analysis
https://latch.fyi/torvalds/linuxFixed 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.