Solid foundation with excellent setup docs, but lacks contribution guidance and architectural clarity for newcomers.
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.
19 of 33 checks passed across 6 categories.
Machine Orientation
3 checks passed4 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.
- 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.
- Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
Reproducible Setup
2 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.
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
3 checks passed4 problems found
- highTests present
Runnable tests are the ground truth an agent checks its own edits against.
Fix: Add a test suite an agent can run to verify a change.
- 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.
- 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.
- lowTypecheck command
A typecheck script lets an agent catch type errors before they ship.
Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).
- 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.
- 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
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.
76 / 10011 of 24 checks passed across 6 categories.
First Impression
85Clear, ambitious project with visuals and immediate context about what it does.
The README leads with polished images, explains the core purpose (AI-generated app builder like Claude Artifacts), lists key features upfront, and provides a live demo link. However, it lacks brief architectural context (where the code lives, how pieces fit) that would help a newcomer mentally map the project before diving deeper. The feature list is thorough but could be more concise.
Getting Running
88Deterministic, copy-pasteable setup with clear prerequisites and dependency pinning.
The README walks through clone → npm install → .env.local setup → dev/build with explicit commands. Dependencies are pinned via package-lock.json and package.json, and the .env.template file is present. The only gap is that the README doesn't mention the .env.template file directly (newcomer might not discover it), and no mention of whether Node.js version matters beyond 'recent'.
Finding Your Way
62File structure is logical but no overview docs explain where to go or how pieces talk to each other.
The file tree shows standard Next.js layout (app/, components/, lib/, sandbox-templates/), and naming is clear (e.g., fragment-code.tsx, chat-input.tsx), but there is no architecture.md, STRUCTURE.md, or docstring-heavy entry point that explains module boundaries, data flow, or the relationship between the E2B SDK, API routes, and components. A newcomer would need to reverse-engineer the Chat → API → E2B pattern.
Path to Contribute
48Contributing section is minimal; no CONTRIBUTING.md, issue templates, or beginner labels.
The README mentions 'feel free to open an issue or pull request' but offers no dev setup steps, code conventions, testing approach, or PR template. The repository shows 22 open issues, but without a CONTRIBUTING.md or beginner-labeled issues, a newcomer won't know what they can realistically tackle first or how to align their work with the project's expectations. No CODEOWNERS guidance on review flow either.
Signs of Life
88Active maintenance with recent commits, solid star count, and clear dependency management.
Last pushed 2026-06-11 (very recent), 6318 stars, 22 open issues suggest ongoing engagement. Package.json shows a recent version (0.1.0) with modern Next.js 14, TypeScript, and well-maintained dependencies. Renovate config present for automated updates. The repository is not stalled, though the snapshot doesn't show PR/issue response times or release cadence explicitly.
Open Door
92Apache 2.0 license is clear and welcoming; no code of conduct, but low friction otherwise.
LICENSE file is present (Apache 2.0), which is permissive and unambiguous, making the project legally reusable. No explicit code of conduct, but the tone in README is friendly and inviting ('Make sure to give us a star!'). No obvious barriers to asking questions; the repo links to E2B's broader ecosystem. The homepage and linked GitHub organization suggest professional backing and accountability.
First Impression
3 checks passed0 problems found
- 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.
Getting Running
2 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.
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
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.
- 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.
- Lint command — A linter lets a first-time contributor catch style issues before review.
Signs of Life
1 check passed2 problems found
- mediumTests present
A test suite signals a project that's cared for, not abandoned.
Fix: Add a test suite — it's the clearest sign the project is maintained.
- lowAutomated dependency updates
Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Fix: Enable Dependabot or Renovate.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
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+20 pts if fixed
No CONTRIBUTING.md or contribution guidelines
A newcomer wanting to contribute has no reference for dev setup beyond the public getting-started steps, no coding conventions, no testing expectations, no PR review process, and no label system for good-first-issues. The Contributing section in the README is a 2-line placeholder. Without this, contributors either copy-paste env setup meant for users or give up.
Fix: Create a CONTRIBUTING.md at the repo root. Include: (1) Dev setup (npm i, npm run dev, npm run lint, npm run test if tests exist); (2) Code style (ESLint config is present, call it out); (3) How to run tests and validate changes; (4) PR/issue etiquette (link to existing open issues to help contributors find good starting points); (5) Branch naming and commit conventions if any.
- highFinding Your Way+18 pts if fixed
No architecture or module overview document
The file tree is logical (app/, components/, lib/) but there's no overview explaining how the E2B SDK, API routes, chat components, and templates interact. A newcomer won't know where a feature request belongs, how to trace a bug, or why certain modules exist. Reverse-engineering the flow (Chat → API route → E2B → Sandbox) takes time.
Fix: Create an ARCHITECTURE.md or ADD-FEATURE.md (1–2 pages) that sketches: (1) High-level flow (User → Next.js chat UI → API route → E2B SDK → sandbox execution); (2) Key module responsibilities (app/api/* for backend, components/* for UI, lib/* for shared logic, sandbox-templates/* for custom environments); (3) Example: where to add a new LLM provider or a new UI component; (4) Pointer to E2B docs for the SDK dependency.
- mediumPath To Contribute+12 pts if fixed
Missing issue/PR templates and no good-first-issue labels
The GitHub issues list has no visible filter for beginner-friendly tasks. No PR or issue templates exist to guide submitters on what information is needed (reproducible steps, environment details, desired outcome). Newcomers may open low-quality issues or not know what to fix.
Fix: Add GitHub issue and PR templates (.github/ISSUE_TEMPLATE/bug.md, .github/ISSUE_TEMPLATE/feature.md, .github/pull_request_template.md) with sections like 'Environment', 'Steps to Reproduce', 'Expected Behavior'. In existing open issues, retroactively tag easy wins with a 'good-first-issue' or 'help-wanted' label and link to them from CONTRIBUTING.md.
- lowGetting Running+4 pts if fixed
Node.js version requirement is vague
The README says 'recent version of Node.js' without specifying minimum or recommended version (e.g., v18, v20). A newcomer on an older LTS might hit silent failures or cryptic errors, especially with modern packages like Next.js 14 and TypeScript 5.5.
Fix: In the README Prerequisites section, add: 'Node.js >= 18.x (LTS recommended)' or match the version specified in a .nvmrc or .node-version file if one exists. Add an optional setup step: 'Use nvm or similar to ensure the right version.'
- lowOpen Door+3 pts if fixed
No code of conduct or community guidelines
While the Apache 2.0 license is clear and the README is friendly, there is no CODE_OF_CONDUCT.md. For a 6K-star open-source project with a public chat/code interface, a code of conduct signals professionalism and sets expectations for civil collaboration.
Fix: Add a CODE_OF_CONDUCT.md at the repo root (e.g., Contributor Covenant) and link to it from the README under a 'Community' or 'Getting Help' section.
- lowGetting Running+2 pts if fixed
.env.template exists but is not referenced
The README explicitly lists all env vars to set in a code block, which is good, but doesn't mention the .env.template file that already exists in the repo. A newcomer might manually type them instead of using cp .env.template .env.local and filling it in, wasting time and inviting errors.
Fix: In README step 3 (Set the environment variables), add a line before the env var listing: 'You can copy the template file: `cp .env.template .env.local`, then edit it with your API keys.' This avoids duplication and is less error-prone.
Show your score
[](https://latch.fyi/e2b-dev/fragments)Share this analysis
https://latch.fyi/e2b-dev/fragmentsFixed 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.