A well-structured TypeScript codebase with strong agent navigation and test coverage, though held back by fragmented verification and a lack of containerized setup.
last scored 2026-09-14 · 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.
71 / 10017 of 40 checks passed across 6 categories.
Machine Orientation
85Clear and comprehensive agent guidance across root README and CLAUDE.md, with minor localized gaps.
The repository provides a clear README and a comprehensive CLAUDE.md file detailing repo layout, stack, domains, and build/run commands for all subcomponents (api, app, marketing). It clears the Solid band (70–89) by offering explicit instructions and structured documentation, though minor sub-readme gaps prevent it from reaching exemplary status.
Reproducible Setup
60The setup is workable via Node and Just scripts, but lacks containerization and automated environment bootstrapping.
The repository provides package-lock.json and explicit API backend scripts via Node, but lacks containerization (no Dockerfile, docker-compose, or devcontainer), and frontend configuration relies on manual .env copying and build-time --dart-define files rather than unified lockfiles. While tests and tasks run via npm and just, the absence of container/environment automation keeps setup in the Workable band.
Code Navigability
85Clear module boundaries, clean TypeScript layout, and well-separated services make this codebase very easy for an agent to navigate.
Code Navigability is solid and well-structured, with clear module boundaries across api/ (Hono backend), app/flutter/ (client), and instant/ (InstantDB schema), supported by typed TypeScript signatures in api/src/ and a clean file tree. The repository uses consistent naming and separation of concerns (e.g., prompt.ts, auth.ts, safety.ts), though strict null-checks or lint rules are partially implicit rather than uniformly enforced across all subprojects. Overall, an agent can reliably localize and edit the exact modules needed.
Verification Surface
65Comprehensive test suites and CI workflows exist, but verification is fragmented across subdirectories without a unified task runner interface.
The repository features extensive test files under `api/test/` (Vitest) and multiple CI workflows in `.github/workflows/`, but lacks explicit runnable check/lint scripts in a root package.json or task runner, placing it solidly in the Workable band.
Agent Safety
75Secret hygiene is solid with env templates, though security policies and ownership boundaries lack explicit configuration.
Secret hygiene is maintained via gitignored env files and an api/.env.example template, and the repo lacks committed env files or secret-shaped hits. However, it lacks a SECURITY.md file and CODEOWNERS, leaving security policies and ownership unestablished for agents. Therefore, this clears the Solid band with minor gaps.
Context Economy
60Workable context economy, weighed down by untagged media assets and ideation bulk.
The repository includes large generated asset directories, marketing videos, and ideation drafts (`ideation/`, `video/`) without explicit `.gitignore` exclusion tuning or linguist markers to isolate build/asset bulk from AI agent context. The detected signals indicate clean node_modules and build outputs, but the extensive unindexed media and documentation weigh down navigation. This clears the 50–69 Workable band.
Machine Orientation
2 checks passed8 problems found
- lowAgent instructions stay lean
A bloated instructions file burns context and measurably hurts more than it helps.
Fix: Trim AGENTS.md to the load-bearing commands and conventions; link out to the rest.
- lowRepository description set
The one-line description is the fastest orientation signal an agent reads.
Fix: Set the GitHub repository description to a single clear sentence.
- 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.
- 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.
- 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.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
Reproducible Setup
3 checks passed3 problems found
- 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.
- 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.
- Env template present — A .env.example tells an agent which configuration keys it must supply to run.
- 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
3 checks passed4 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.
- 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.
- 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.
Agent Safety
5 checks passed3 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.
- 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 covers env files — An ignore rule for .env is what keeps the next careless commit from leaking secrets.
- .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.
73 / 10010 of 32 checks passed across 6 categories.
First Impression
95An exemplary, comprehensive README that instantly clarifies purpose, scope, and architecture.
The README provides an exceptional first impression, clearly explaining the project's purpose, scope, architecture, and live links, comfortably earning an exemplary score in the 90–100 band.
Getting Running
85Getting running is solid with clear multi-subproject guides and `.env.example` templates, though lacking explicit version manager configuration.
The repository provides clear setup instructions and dependency templates in the README and subdirectories (`api/.env.example`), complete with lockfiles (`api/package-lock.json`, `app/flutter/pubspec.lock`), but exact tool versions (Node 24, Flutter SDK) are only mentioned in prose rather than pinned in machine-readable version files like `.nvmrc` or `pubspec.yaml` SDK constraints. It clears the Solid band because setup and run commands are explicit, copy-pasteable, and cover multiple subprojects (`api`, `app/flutter`, `marketing`), with minor gaps in version pinning.
Finding Your Way
65The layout is well-documented in text across subproject guides, but lacks an explicit high-level system diagram for rapid newcomer orientation.
The repository provides a clear and structured overview in its README and CLAUDE.md files, detailing the multi-domain monorepo layout (marketing, api, and app/flutter), request flows, and configuration boundaries. While subprojects like `api/` and `app/flutter/` have their own READMEs and entry points, the lack of an overarching architecture diagram or formal directory map slightly impedes rapid mental-model building. This places the repository solidly in the Workable band.
Path to Contribute
45Valuable code and local scripts exist, but without a CONTRIBUTING guide or templates, the path for contributors is rough and undocumented.
The repository has strong code and tests but lacks a CONTRIBUTING guide, issue templates, and PR templates, placing it in the 30–49 Rough band. Although `api/` and `app/` have internal README files and CLAUDE.md provides developer guidance, there is no explicit, machine-readable route for external contributors to set up, test, and submit PRs.
Signs of Life
85Actively maintained with robust CI and recent commits, though lacking external contribution channels.
The repository shows strong signs of life with multiple active CI workflows, recent commits up to August 2026, and a fully fleshed-out test and deploy pipeline across components, clearing the Solid band (70–89). However, because issues and PR activity cannot be directly verified from the static file snapshot alone, it falls just short of exemplary.
Open Door
60An explicit license is present, but missing contributor guidelines and code of conduct hold back full open-source readiness.
The repository includes a license file presence signal but lacks a CODEOWNERS file, contributing guide, and code of conduct, making it difficult for newcomers to know how to contribute safely. Although the README outlines the project and setup, the absence of crucial open-source onboarding policies places this in the Workable band.
First Impression
1 check passed5 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.
- lowRepository description set
The one-line description sets expectations before a newcomer even opens the README.
Fix: Set the GitHub repository description to a single clear sentence.
- 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.
Getting Running
3 checks passed3 problems found
- 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.
- 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.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- Env template present — A .env.example shows a newcomer exactly which settings they must fill in to run it.
- 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
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
- lowAutomated dependency updates
Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Fix: Enable Dependabot or Renovate.
- 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).
- 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.
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
- lowVerification Surface+7 pts if fixed
Missing unified root verification scripts
No root-level package.json or task runner scripts to unify verification across the subprojects (api, app, marketing).
Fix: Add a root package.json with workspace scripts for running tests and type-checking across all packages.
- mediumReproducible Setup+5 pts if fixed
Missing containerized setup
Missing Dockerfile or docker-compose setup for reproducible environment containerization.
Fix: Add a Dockerfile and docker-compose.yml to containerize the API and client services.
- mediumContext Economy+4 pts if fixed
Bulk generated assets and ideation artifacts lack linguist markers
Large media and ideation artifact directories (`video/`, `ideation/results/deck.pdf`, MP4s) consume context window space without linguist exclusion markers.
Fix: Add `.gitattributes` with `linguist-generated` rules for binary assets, PDFs, and generated video files.
- lowReproducible Setup+2 pts if fixed
Unpinned runtime versions and missing devcontainer
No pinned dependencies or container definitions for deterministic execution across environments.
Fix: Pin core runtime versions in a tool-versions file and provide a standard devcontainer.
- lowAgent Safety+2 pts if fixed
Missing SECURITY.md
Missing SECURITY.md vulnerability reporting policy and instructions.
Fix: Add a SECURITY.md file explaining how to report vulnerabilities securely.
- lowMachine Orientation+2 pts if fixed
Subdirectory READMEs missing
Missing dedicated README files inside subdirectories like app/flutter/ or infra/ relying solely on root-level guidance.
Fix: Add brief README files in subdirectories or consolidate all onboarding instructions cleanly into root documentation.
- lowCode Navigability+2 pts if fixed
Inconsistent strictness across monorepo boundaries
tsconfig.json sets strict: true in api/, but flutter lint rules and strictness vary in app/flutter/.
Fix: Enable strict analysis options across all subprojects and add explicit code-nav architectural notes in a CONTRIBUTING or ARCHITECTURE doc.
- lowAgent Safety+1 pts if fixed
Missing CODEOWNERS
Missing CODEOWNERS file for explicit ownership boundaries.
Fix: Add a .github/CODEOWNERS file defining ownership boundaries for sensitive paths.
Show your score
[](https://latch.fyi/yarnia-quest/yarnia)Share this analysis
https://latch.fyi/yarnia-quest/yarniaFixed 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.