An exceptionally agent-ready browser automation framework with pristine documentation, robust safety boundaries, and clear multi-language structures.
last scored 2026-09-20 · 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.
88 / 10028 of 41 checks passed across 6 categories.
Machine Orientation
95Exceptionally well-documented and structured for AI agents across TypeScript, Python, and Go.
The repository provides exceptional machine orientation with a comprehensive README, a focused AGENTS.md detailing stacked PR workflows, a clear justfile, and full multi-language package instructions. Essential build, test, and generation commands are explicitly machine-readable via the justfile and root package.json. This securely clears the Solid band.
Reproducible Setup
85Solid setup driven by just and robust lockfiles, with minor gaps in node version pinning and devcontainers.
The repository provides a comprehensive setup workflow via just and make commands, supported by multiple lockfiles (uv.lock, go.sum, pnpm-lock.yaml), a Dockerfile, and clear contributor guidelines in CONTRIBUTING.md. Minor friction stems from floating Node engine requirements in package.json and the lack of a pre-configured devcontainer, placing it firmly in the Solid band.
Code Navigability
85Solid monorepo layout with clear module boundaries and explicit tooling, easily navigable by an agent.
The repository features a conventional monorepo layout with clear module boundaries (`packages/protocol`, `packages/sdk-ts`, `packages/sdk-python`, `packages/sdk-go`, `packages/extension`), a robust task runner (`justfile`), and explicit types and naming across its TypeScript, Python, and Go codebases. This places the repository firmly in the Solid band (70–89), where an agent can easily navigate and localize code changes without stumbling.
Verification Surface
85Comprehensive multi-language verification suite backed by just and CI workflows.
Solid verification essentials are fully defined via justfile, package.json scripts, and a 6-workflow GitHub Actions CI pipeline covering TypeScript, Python, and Go checks, tests, and formatting. The repository clearly provides end-to-end runnable verification commands (`just check`, `just test`), clearing the Solid band.
Agent Safety
95Exemplary secret hygiene and agent safety boundaries, landing safely in the top tier.
The repository exhibits strong agent safety hygiene with a proper .env.example template, zero secret-shaped hits, gitignore coverage for environment files, and clean CODEOWNERS boundaries. It securely supports autonomous coding agents without exposing hardcoded secrets or destructive unfiltered operations.
Context Economy
85Solid context economy with a clear AGENTS.md and monorepo structure, missing only an llms.txt index.
The repository provides strong context-economy essentials, including a dedicated AGENTS.md, clean ignore configurations, and modular monorepo packages, though it lacks an explicit llms.txt. This places it solidly in the 70–89 band.
Machine Orientation
6 checks passed4 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.
- lowExamples directory
An examples/ directory gives an agent runnable, copyable references for the API.
Fix: Add an examples/ directory with small, runnable usage samples.
- 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.
- 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
- 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.
- 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.
- Env template present — A .env.example tells an agent which configuration keys it must supply to run.
- 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
7 checks passed0 problems found
- 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.
- Task runner present — A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
- Typecheck command — A typecheck script lets an agent catch type errors before they ship.
- Build command — A documented build command is the discoverable way for an agent to produce artifacts.
Agent Safety
6 checks passed2 problems 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.
- 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 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.
- .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.
84 / 10021 of 33 checks passed across 6 categories.
First Impression
95Exemplary first impression with comprehensive multi-language documentation and setup guidance right from the README.
The repository's README provides a pristine first impression with a clear purpose, multi-language examples (TypeScript, Python, Go), installation steps, and quick start demos. It easily clears the 90–100 exemplary band because of its comprehensive overview, clean layout, and rich context.
Getting Running
85Multi-language setup is exceptionally well-documented via justfile and lockfiles, missing only a pinned Node version.
The repository provides exceptionally explicit, multi-language setup instructions using `just install`, a clear `.env.example` file, and proper lockfiles (`uv.lock`, `go.sum`, `pnpm-lock.yaml`) across its TypeScript, Python, and Go monorepo. This earns a Solid score of 85, just shy of exemplary due to floating Node engine requirements in package.json.
Finding Your Way
80Well-structured monorepo with clear contributor mapping, though missing a standalone architecture doc.
With a solid repository layout, a comprehensive CONTRIBUTING.md that maps out the monorepo architecture, and clear task runner configs, newcomers can readily build a mental map and navigate the code. The solid score of 80 reflects these strengths, with minor deductions due to the absence of a dedicated architecture overview document in the repository root.
Path to Contribute
85Comprehensive contribution and setup documentation makes getting started straightforward.
The repository provides an explicit CONTRIBUTING.md guide with setup instructions and test commands, issue templates, and a pull request template, clearing the Solid band. While there is no explicit PR template file ending in .md (it is named .github/pull_request_template without an extension), the guidance and contribution pathways are robust and well-documented.
Signs of Life
85Actively maintained with robust CI, workflows, and recent commits.
The repository demonstrates strong signs of life with recent commits (last pushed Sept 20, 2026), active CI workflows, issue templates, code owners, and a responsive contributor community. It easily clears the Solid band (70–89) and approaches exemplary standards due to comprehensive GitHub actions and tooling.
Open Door
70MIT license and contribution guides are present, but a Code of Conduct and security policy are missing.
The repository has a clear MIT license and a contributing guide, but lacks a Code of Conduct and SECURITY.md file. This places it firmly in the workable band as essentials exist with real named gaps.
First Impression
4 checks passed2 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.
- 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.
- 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.
Getting Running
5 checks passed2 problems found
- 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.
- Env template present — A .env.example shows a newcomer exactly which settings they must fill in to run it.
- 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
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- 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.
- Task runner — A Makefile / Taskfile gives a contributor a single index of the project's commands.
Signs of Life
3 checks passed2 problems found
- 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.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
- Changelog — A maintained CHANGELOG shows a newcomer the project ships and records its changes.
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+3 pts if fixed
External dependency reliance in tests
Integration tests and some browser evals depend on external API keys or headless browsers that might fail in disconnected agent environments without setup.
Fix: Ensure documentation or pre-check scripts cleanly skip or mock external keys when offline.
- lowCode Navigability+2 pts if fixed
Missing architecture document
Architecture document explaining cross-package protocol generation flow is missing.
Fix: Add an architecture document (e.g., ARCHITECTURE.md) explaining how protocol changes propagate to generated SDK clients.
- lowContext Economy+1 pts if fixed
Missing llms.txt
The repository lacks an llms.txt file to guide coding agents on compact context summaries and architectural conventions.
Fix: Add an llms.txt file at the root providing high-level architecture pointers and token-efficient guidelines for agents.
- lowReproducible Setup+1 pts if fixed
Floating Node engine version
The engines.node setting in package.json is floating rather than strictly pinned.
Fix: Pin engines.node to an exact patch release in package.json.
- lowReproducible Setup+1 pts if fixed
Missing devcontainer config
No devcontainer configuration is provided for instant containerized agent environments.
Fix: Add a .devcontainer/devcontainer.json file to standardise the agent container environment.
Show your score
[](https://latch.fyi/browserbase/stagehand)Share this analysis
https://latch.fyi/browserbase/stagehandFixed 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.