Skip to content

Since the last run

Overall +20 points

mckaywrigley/chatbot-ui (opens in a new tab)

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.

TypeScript★ 33,268240 open issuesMIT License
Overall score: 62 out of 100
Slipping

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.

Where the grip slips

  1. 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.).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.'

  7. 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

Latch badge
[![Latch score](https://latch.fyi/api/badge/def4490d-2052-4b40-8cc4-ea9de1f3bad5)](https://latch.fyi/mckaywrigley/chatbot-ui)

Share this analysis

https://latch.fyi/mckaywrigley/chatbot-ui

Fixed 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.

Was this verdict fair?

One tap helps — or tell us more.