An exceptionally clean, agent-ready TypeScript repository with exemplary orientation, safety, and navigability.
last scored 2026-09-12 ยท 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.
92 / 10031 of 44 checks passed across 6 categories.
Machine Orientation
98Exemplarly machine-readable orientation with crystal-clear entry points, specs, and keyless testability.
The repository is exemplary for machine orientation, featuring a pristine README with explicit CLI commands, a comprehensive CLAUDE.md operating manual, an architecture doc, and fully reproducible keyless build and test instructions. Verified signals include `README=yes`, `agentFile=yes`, `architectureDoc=yes`, and structured CI scripts (`npm ci`, `npm test`, `npm run build`, `npm run typecheck`, `npm run lint`). It clears the 90-100 Exemplary band with zero friction.
Reproducible Setup
85Solid setup with clean keyless commands and version pinning, missing only a container environment.
The repository provides clear setup instructions, node version pinning via .nvmrc (with engines.node), a deterministic keyless test/build invariant, and clean CI workflows, clearing the Solid band. However, it lacks a container or devcontainer configuration to achieve completely machine-verifiable end-to-end containerized setup. Solid (85).
Code Navigability
98An exceptionally navigable, well-partitioned TypeScript codebase with crisp module boundaries and types.
The repository exhibits exemplary code navigability: modules follow a strict conventional layout (`lib/gmail/`, `lib/derive/`, `lib/store/`, `lib/engine/`) with clean domain boundaries, consistent and explicit TypeScript typing (`lib/types.ts`), and manageable, well-factored files with colocated tests. Cross-cutting concerns are neatly isolated (e.g., side effects and storage behind explicit ports), enabling an agent to localize and navigate code with precision.
Verification Surface
90Solid verification surface with robust test, lint, typecheck, and CI workflows that an agent can execute locally and verify keyless.
Solid verification surface is present with a complete test runner (Vitest with colocated *.test.ts files), typechecking (tsc strict for app and e2e), linters (eslint), builds (next build + esbuild CLI), and fully defined CI workflows (.github/workflows/ci.yml and e2e.yml) that run keyless. Ground truth is fully machine-verifiable by an agent running npm test, npm run lint, and npm run typecheck.
Agent Safety
98Exemplary agent safety posture with static egress bounds and complete secret hygiene.
The repository exhibits exemplary agent safety standards, featuring a comprehensive egress scan (`lib/egress.ts`) that statically inspects source code for unauthorized outbound network fetches, correct gitignore handling for secret stores (`.bly/`), and rigorous documentation of safety invariants. There is no committed `.env` file, and environment variables are strictly optional to maintain a keyless local-first invariant.
Context Economy
85Clean layout and explicit boundaries give an agent high signal-to-noise, with only minor historical plan overhead.
The repository has a clean file tree (244 files) without vendored build outputs, committed node_modules, or bloated generated noise, achieving a Solid Context Economy (85) score. All sources are cleanly organized under standard directories (`lib`, `app`, `cli`, `scripts`), and extensive planning docs are neatly contained in `docs/superpowers/`. Minor deduplication of test fixtures or streamlining historical architecture spec phases could further improve agent signal density.
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.
- 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.
- Architecture doc โ An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
- Contribution conventions are written down โ A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
3 checks passed4 problems found
- 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.
- 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.
- README documents setup โ Explicit install/setup steps are what let an agent go from clone to running.
Code Navigability
3 checks passed2 problems found
- lowFormatter configured
A formatter config (Prettier/Biome/rustfmt/โฆ) keeps style uniform across the tree.
Fix: Add a formatter (Prettier, Biome, rustfmt, โฆ) and commit its config.
- 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.
Verification Surface
6 checks passed1 problem 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.
- 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.
- 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
9 checks passed2 problems found
- 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.
- 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.
- .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.
- Security policy โ A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
- Policy names the threat model โ A scanning agent aims at what the repo says it is defending, and where untrusted input crosses in.
- 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
- 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).
- 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.
- No oversized source file โ A single file in the hundreds of KB blows past an agent's effective context window.
How ready the repo is for a human newcomer to understand, set up, and contribute.
90 / 10024 of 33 checks passed across 6 categories.
First Impression
85A stellar, crystal-clear first impression with a comprehensive README, architectural guides, and immediate developer orientation.
The project's README, architecture docs, and package configuration clearly establish Bly as a local-first, open-source AI career agent running via Gmail sync or Takeout imports. The orientation provides exact setup commands, clear behavioral boundaries, and verified test/CI verification signals, placing it solidly in the Solid band.
Getting Running
85Solid, keyless-first setup with clear CLI commands and rigorous prerequisites, though live Gmail sync requires a one-time Google Cloud project.
The repository achieves a solid 85 score for Getting Running, backed by explicit Node 24 version requirements (.nvmrc, engines.node), clear npm install and run commands in the README and CONTRIBUTING guide, and zero-env-var keyless test capability. Minor deductions apply due to the required external Google Cloud OAuth setup walk-through for Gmail integration, though it includes a functional fallback mbox ingest method.
Finding Your Way
95Cleanly structured, thoroughly mapped, and straightforward to navigate from first clone.
The repository provides an exemplary architecture map (`docs/ARCHITECTURE.md`), clear module boundaries (`lib/` versus `app/`), and consistent descriptive naming, scoring it solidly in the 90โ100 Solid/Exemplary band. Every core unit has a colocated test, and explicit operational instructions (`CLAUDE.md`, `CONTRIBUTING.md`) make navigation intuitive for any newcomer.
Path to Contribute
100Exceptional contribution path with clear developer ergonomics and rigorous automated checks.
The repository provides an exemplary Path to Contribute, featuring a comprehensive CONTRIBUTING.md guide with setup steps, ground rules, and test instructions, structured issue and pull request templates, and a lightweight keyless dev environment. All requirements for a friction-free newcomer journey are completely satisfied, clearing the Exemplary band.
Signs of Life
85Active and fully tooled maintenance with automated releases and robust CI.
Solid โ the repository demonstrates active maintenance with recent commits (last pushed Sept 2026), full CI/e2e workflow coverage, automated release tooling via release-please, and clear contribution guidelines. Automated checks and dependabot show healthy project infrastructure.
Open Door
90Legally reusable, socially structured, and fully welcoming for newcomers.
The repository provides an explicit Apache-2.0 open-source license, a comprehensive code of conduct, a security policy (`SECURITY.md`), CODEOWNERS, issue templates, and obvious onboarding/contributing guides, easily clearing the Solid band. Solid band (70โ89) is cleared because all necessary legal, safety, and community interaction prerequisites are fully present and machine-verifiable.
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
3 checks passed4 problems found
- 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.
- 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.
- README documents setup โ Explicit install steps are the difference between a 5-minute start and giving up.
Finding Your Way
4 checks passed1 problem found
- lowFormatter configured
An auto-formatter means a newcomer never guesses the house style.
Fix: Add a formatter (Prettier, Biome, rustfmt, โฆ) and commit its config.
- Conventional source layout โ A familiar src/ ยท lib/ ยท app/ layout lets a newcomer guess where things live.
- Architecture / overview doc โ An overview hands a newcomer the map instead of making them reconstruct it.
- No oversized source file โ A single thousand-line file is a wall a newcomer bounces off.
- .editorconfig present โ Consistent indentation/encoding keeps the code readable and diffs clean for newcomers.
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
- 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.
- 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.
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
- lowReproducible Setup+3 pts if fixed
Missing container or devcontainer configuration
No Dockerfile or devcontainer configuration is provided for containerized environment setup.
Fix: Add a Dockerfile or .devcontainer/devcontainer.json configuration.
- lowContext Economy+1 pts if fixed
Historical phase plans add repository text overhead
Numerous historical phase plans and design specs in docs/superpowers/ add to token overhead without active execution relevance.
Fix: Consolidate or archive completed historical phase plans into a single directory or summary file to reduce noise.
- lowCode Navigability
Clean architecture and structure
None; code organization, module encapsulation, and naming conventions are best-in-class.
Fix: None needed.
Show your score
[](https://latch.fyi/yellow-pine/bly)Share this analysis
https://latch.fyi/yellow-pine/blyFixed 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.