A high-traffic AI chat project with good docs and tests, but contributors hit friction quickly: vague contributing guide, 240 open issues unreviewed, and stalled maintenance signals.
last scored 2026-06-15
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.
20 of 34 checks passed across 6 categories.
Machine Orientation
2 checks passed5 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.
- 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.
- 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.
Reproducible Setup
3 checks passed3 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.
- 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.
- Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
Code Navigability
2 checks passed0 problems found
- 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.
Verification Surface
5 checks passed2 problems found
- 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.
- 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.
- 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
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
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.
62 / 10012 of 25 checks passed across 6 categories.
First Impression
82Clear purpose, active demo, and maintained by a known maintainer, but missing depth about the 2.0 rewrite and current capability scope.
The README immediately answers 'what' (AI chat UI) and 'why' (open-source alternative), links to a live demo, and includes a screenshot. However, the prominent message 'I'm working on a big update... Be back soon' signals maintenance pause and creates uncertainty about the project's current state and stability. A newcomer might hesitate, unsure if the codebase is in flux.
Getting Running
68Step-by-step commands are present and copy-pasteable, but heavy dependencies (Docker, Supabase CLI), undocumented Node version gotcha, and SQL file editing requirements create friction.
The README covers local and hosted setup with explicit commands and even links a video tutorial—strong scaffolding. However, setup requires Docker, Supabase CLI, Ollama (optional), and manual SQL edits in migration files. The `.nvmrc` file hints at Node version constraints but the README only casually mentions 'compatible node version (i.e. v18)' inline. A newcomer running Node 16 or 20 will hit silent failures without clear error messages.
Finding Your Way
55Codebase is well-structured by feature (app/, components/, db/, lib/) and uses TypeScript, but no architecture doc, no entity relationships explained, and deep nesting makes navigation opaque.
The file tree shows clear organization: chat components, database layers (db/), API routes, and sidebar items. However, there's no diagram, no doc explaining the data model (what is a 'workspace'? 'assistant'? 'collection'?), and no README section describing how pieces fit together. A newcomer opening `db/assistants.ts` has no context for how it connects to `components/sidebar/items/assistants/` or the API layer.
Path to Contribute
40CONTRIBUTING.md is a stub ('We are working on a guide'), no issue labels or templates, and issues policy discourages involvement—actively hostile to newcomers.
The README explicitly tells users 'Issues unrelated to the codebase will likely be closed immediately' and redirects them to Discussions, signaling the maintainer is overwhelmed. There are 240 open issues but no beginner-friendly labels, no PR template, no code style guide beyond ESLint config, and no example of an accepted contribution. A newcomer has no safe path to a first PR.
Signs of Life
48Recent commits (Aug 2024) and high star count suggest visibility, but 240 unreviewed issues, 'big update coming soon' message, and no visible PR velocity signal maintenance burden and stall.
Last push was 2024-08-03, which appears recent, but the README's prominent 'working hard on a big update... Be back soon' message (with no date) and a backlog of 240 open issues imply the project is paused for refactoring or the maintainer is stretched. No visible release notes, no recent PR merges (based on snapshot), and no clear resolution rate suggest the project is in maintenance limbo rather than actively evolved.
Open Door
78MIT license is clear, but no code of conduct, and issue triage policy feels discouraging rather than welcoming—legal is safe, but social safety is questionable.
The license file is present and MIT is explicitly stated in metadata, so legal reusability is solid. However, there's no CODE_OF_CONDUCT.md, and the README's tone on issues ('Issues unrelated to the codebase will likely be closed immediately') sets an unwelcoming tone for first-time contributors. The Discussions tab is recommended as the help channel, which is good, but the lack of a formal CoC and explicit mention of how to get unstuck leaves a newcomer uncertain whether their question is 'allowed.'
First Impression
2 checks passed1 problem found
- 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.
- 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
3 checks passed3 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.
- 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.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
2 checks passed1 problem 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.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
- No oversized source file — A single thousand-line file is a wall a newcomer bounces off.
Path to Contribute
2 checks passed4 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.
- 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.
- 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
1 check passed2 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.
- Tests present — A test suite signals a project that's cared for, not abandoned.
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
- highPath To Contribute+18 pts if fixed
CONTRIBUTING.md is a stub—no dev setup, testing, or PR guidance
The README says 'We are working on a guide for contributing,' meaning newcomers have no roadmap for environment setup beyond the quickstart, no testing instructions, no code review expectations, and no PR process. This is the primary barrier to a first contribution.
Fix: Create a CONTRIBUTING.md with sections: (1) Dev environment setup (node version, npm install, supabase local setup), (2) How to run tests (npm test command and what to test), (3) Code style (ESLint/Prettier rules), (4) PR process (branch naming, commit messages, PR checklist), (5) Where to ask for help (Discussions, Discord, etc.).
- highPath To Contribute+15 pts if fixed
240 open issues with no triage, labels, or beginner-friendly starters
The issue backlog is massive and the README actively discourages filing issues ('will likely be closed immediately'), yet there's no evidence of triage, no 'good first issue' labels, and no beginner-friendly starters. A newcomer cannot identify a safe, scoped contribution opportunity.
Fix: Add GitHub issue labels: 'good first issue' (5-20 minute tasks), 'help wanted' (small features), 'bug' (verified issues), 'discussion' (design questions). Triage the 240 issues: close duplicates/invalid, label as above, pin 3–5 good-first-issue candidates in the README. Create an issue template (use GitHub's built-in) to guide reporters toward codebase-only issues.
- mediumFinding Your Way+14 pts if fixed
No architecture or data model documentation; codebase navigation is opaque
The file tree is well-organized, but there's no README section or separate doc explaining the data model (Workspace, Assistant, Chat, Collection, File relationships), request flow (frontend → API → DB), or module purpose. A newcomer cannot build a mental map without diving into code.
Fix: Create a ARCHITECTURE.md with: (1) Entity-relationship diagram or ASCII diagram showing Workspace → Chat, Assistant, File relationships; (2) Request flow diagram (frontend input → API route → DB query → response); (3) Module breakdown (app/ = Next.js routes, components/ = UI, db/ = Supabase queries, lib/ = utilities); (4) Key entry points (e.g., 'To add a new model provider, extend app/api/chat/'). Reference this file in the main README.
- mediumSigns Of Life+12 pts if fixed
'Working on a big update... be back soon' message signals maintenance pause with no timeline
The prominent README notice 'I've heard your feedback and am working hard on a big update... Be back soon' with no date creates uncertainty about project stability and maintenance status. A newcomer may hesitate to invest time if the codebase is under major refactoring or the maintainer is unavailable.
Fix: Either (1) replace the message with a specific ETA and a brief roadmap (e.g., 'Planned for Q4 2024: simplified deployment, better backend compatibility'), or (2) remove it and create a GitHub Discussion pinned as 'Project Status' explaining the current state, what's paused, and when it resumes. Add a CHANGELOG.md with date stamps for recent releases.
- mediumGetting Running+8 pts if fixed
Node version constraint buried in inline text; .nvmrc suggests stricter requirement
The README says 'Be sure to use a compatible node version (i.e. v18)' as a casual aside. The `.nvmrc` file (v18) suggests a strict requirement, but it's not enforced and newcomers on Node 16 or 20 may hit silent failures without understanding why.
Fix: Add a prerequisites section early in the Local Quickstart: 'Prerequisites: Node.js 18 (check with `node --version`; we recommend nvm for version management).' Add a setup validation script (`npm run validate-env`) that checks Node version and reports a clear error if it's wrong. Consider adding an .npmrc with `engine-strict=true` to fail fast on npm install if Node is wrong.
- lowOpen Door+8 pts if fixed
No code of conduct; issue policy feels unwelcoming
There's no CODE_OF_CONDUCT.md, and the README's firm tone on issues ('Issues unrelated to the codebase will likely be closed immediately') creates a chilling effect on participation. A newcomer may fear their question is 'dumb' or will be rejected.
Fix: Add CODE_OF_CONDUCT.md (use Contributor Covenant 2.1 as a template). In the README's 'Discussions' section, reframe the tone: 'Please use Discussions for questions and feature requests—we'd love to help! Issues are for confirmed bugs and code improvements.' Optionally pin a Discussion post: 'Ask Anything Here—No Question Is Too Simple.'
- mediumGetting Running+6 pts if fixed
SQL migration file requires manual editing; error-prone onboarding
Setup instructions require the user to manually edit `supabase/migrations/20240108234540_setup.sql` lines 53–54 with two values from `supabase status`. This is error-prone, and if they paste the wrong value, silent storage bugs result. No validation step is documented.
Fix: Refactor the migration to accept environment variables instead: use `${SUPABASE_PROJECT_URL}` and `${SUPABASE_SERVICE_ROLE_KEY}` placeholders, then write a setup script (e.g., `scripts/setup-migrations.sh`) that reads these from `.env.local` and substitutes them before applying the migration. Document: 'Run `npm run setup:db` to auto-configure migrations.' This eliminates manual editing and makes the flow deterministic.
Show your score
[](https://latch.fyi/mckaywrigley/chatbot-ui)Share this analysis
https://latch.fyi/mckaywrigley/chatbot-uiFixed 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.