A production-grade project with strong momentum, but complex local dev setup and unclear path to first code contribution will frustrate many 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.
28 of 35 checks passed across 6 categories.
Machine Orientation
6 checks passed2 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.
- 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.
- 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.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
6 checks passed0 problems found
- 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.
- Env template present — A .env.example tells an agent which configuration keys it must supply to run.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
- Dev container — A .devcontainer gives an agent a one-command, fully-declared environment.
Code Navigability
1 check passed1 problem 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.
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
Verification Surface
5 checks passed2 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.
- 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.
- 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.
- Task runner present — A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
- Typecheck command — A typecheck script lets an agent catch type errors before they ship.
Agent Safety
8 checks passed0 problems found
- 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.
- 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.
72 / 10020 of 25 checks passed across 6 categories.
First Impression
88Clear what it is, why it exists, and what maturity level to expect.
The README immediately identifies Dify as an open-source LLM app development platform with 145K+ stars and a feature-rich description covering workflows, RAG, agents, and observability. The cover image, quick-start Docker snippet, and hosted cloud option give instant credibility and multiple entry points. However, it assumes some familiarity with AI/LLM concepts and doesn't explain *why* you'd choose Dify over alternatives.
Getting Running
58Docker quick-start works, but local development setup is steep and underdocumented.
The Docker Compose quick-start is copy-pasteable and straightforward (3 lines, clear port), which is excellent. However, for local source development (the Makefile shows this is the intended dev path), the setup demands multiple steps across `make dev-setup`, Python uv, Node 22.22.1 pinned, multiple .env files, and implicit knowledge of which services to start first. The Makefile has helpful targets but no README explaining the orchestration or what each step does—a newcomer must reverse-engineer docker-compose.middleware.yaml to understand the full stack.
Finding Your Way
68A massive, multi-language codebase with some structure, but no architecture overview or module map for newcomers.
The file tree shows clear separation (api/, web/, docker/) and sensible naming (configs/, controllers/, models/), and there are agent skill directories with references (e.g., architecture-rule.md, testing.md). However, no architecture document exists at the root or in docs linking these layers, no dependency graph, and 12,565+ files make it easy to get lost. The README links to full docs (which may have this), but within the snapshot, there's no mental model for a newcomer to grab.
Path to Contribute
62CONTRIBUTING.md exists and links are present, but the path from clone to first PR is not explicit.
The README mentions a CONTRIBUTING.md and points to GitHub Discussions and Issues for bug reports and features. The Makefile has linting and type-check targets that show quality standards. However, the snapshot does not include the full CONTRIBUTING.md content, so it's unclear if it covers: how to pick a beginner-friendly issue, how to set up for *contribution* vs. just local testing, what tests to run before submitting, or PR conventions. The `make lint`, `make test`, and `make type-check` targets exist but assume familiarity with the dev setup flow.
Signs of Life
86Highly active—many recent commits, 750 open issues, active Discord, and a visible contributor base.
The README includes commit-activity and discussion badges, mentions 50+ contributors visible in the contrib.rocks image, and shows active community channels (Discord with 1000s of members, Reddit, GitHub Discussions). The file tree includes a .github/dependabot.yml and numerous workflows (ci, e2e, deploy), indicating continuous maintenance. Last push is 2026-06-15 (future-dated, likely an error in the snapshot, but recent). This is clearly not a stalled project.
Open Door
72Open-source licensed and community-focused, but the license file is vague and social gating exists.
The repo has a LICENSE file and CODE_OF_CONDUCT.md (.github/CODE_OF_CONDUCT.md present in file tree), and multiple community channels are listed (Discord, GitHub Discussions, Reddit, X). However, the snapshot says 'License: Other,' which is red flag—the actual license text is not shown, so a newcomer cannot verify it's truly open-source-compatible (could be proprietary or restrictive). The enterprise license note ('Send us an email') and AWS Marketplace upsell suggest a commercial model that may deter some contributors. The Discord and hosted cloud create some friction vs. pure GitHub-only community.
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
6 checks passed0 problems found
- 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.
- Env template present — A .env.example shows a newcomer exactly which settings they must fill in to run it.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
- One-click dev container — A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
1 check passed2 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.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
Path to Contribute
4 checks passed2 problems found
- 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.
- 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.
- Lint command — A linter lets a first-time contributor catch style issues before review.
- Task runner — A Makefile / Taskfile gives a contributor a single index of the project's commands.
Signs of Life
3 checks passed0 problems found
- 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.
Open Door
3 checks passed1 problem 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.
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- 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
- highOpen Door+15 pts if fixed
Missing or ambiguous license statement in snapshot
The snapshot lists 'License: Other,' which does not clearly indicate to a newcomer whether this is truly open-source and reusable. Visitors cannot verify legal safety on GitHub without reading the LICENSE file, and the 'Other' tag creates friction and doubt.
Fix: Display the exact SPDX license identifier (e.g., 'Apache-2.0', 'MIT') in the GitHub UI and prominently in the README. Add a one-line license shield badge to the top of the README (e.g., `[`).
- highGetting Running+14 pts if fixed
Local source development setup is underdocumented and complex
The Makefile shows the dev setup (docker middleware, web, api), but newcomers must infer the sequence and tooling. The Makefile targets don't explain *why* three separate environments are needed, what docker-compose.middleware.yaml does, or how to run the full stack locally. The README only mentions Docker Compose for the all-in-one setup and a generic link to 'deploying from source code' in docs.
Fix: Add a DEVELOPMENT.md file at the repo root with: step-by-step local setup (e.g., 'Run `make dev-setup`, then `make dev-api` and `make dev-web` in separate terminals'), explanation of what each Makefile target does, a checklist to verify the stack is running (e.g., 'curl http://localhost/api/health'), and troubleshooting for common failures. Link from README.
- highFinding Your Way+12 pts if fixed
No architecture or codebase overview for newcomers
With 12,565+ files across api/, web/, and docker/, and no high-level architecture document in the root or README, a newcomer cannot build a mental map. The agent skills directory hints at internal structure, but there's no diagram or guide explaining how api, web, and backend-services interact.
Fix: Add an ARCHITECTURE.md file at the repo root with: a brief ASCII or Mermaid diagram showing api → backend → web data flow, a 2–3 sentence summary of each major module, and where to find more detail. Link it prominently from the README.
- highPath To Contribute+11 pts if fixed
CONTRIBUTING.md content not visible; path to first PR unclear
The README references CONTRIBUTING.md, but the snapshot does not include its content. Without seeing it, a newcomer cannot verify whether it covers: issue selection, dev setup for contributions, test expectations, PR conventions, or code-review norms. The Makefile shows `make lint` and `make test` but no guidance on when/how to use them in a PR workflow.
Fix: Ensure CONTRIBUTING.md includes: (1) a quick checklist for setting up a dev environment for contributors, (2) how to pick a beginner-labeled issue, (3) step-by-step PR workflow (fork, branch, test, lint, submit), (4) what tests and linting checks must pass, and (5) expected review time. Reference Makefile targets by name.
- mediumPath To Contribute+9 pts if fixed
No beginner-labeled issues or explicit issue-selection guidance
The README directs newcomers to GitHub Issues and GitHub Discussions, but the snapshot does not show labels like 'good-first-issue' or 'beginner-friendly' in the .github/ISSUE_TEMPLATE files or issue triage strategy. With 750 open issues, a newcomer must manually scan to find work at their level.
Fix: Add labels 'good-first-issue' and 'help-wanted' to the GitHub label schema, and triage existing issues (at least 5–10 recent ones) with these labels. In CONTRIBUTING.md, add a link: 'Start here: [Issues labeled good-first-issue](https://github.com/langgenius/dify/labels/good-first-issue)'.
- mediumGetting Running+8 pts if fixed
Multiple required .env files with no unified template or env setup script
The Makefile copies docker/.env.example, web/.env.example, and api/.env.example, but a newcomer must manually understand which env variables are critical for local dev. There's no single script or checklist explaining which vars are required vs. optional, or what happens if they're wrong (e.g., does the app fail to start, or silently degrade?).
Fix: Create a setup script (e.g., `scripts/setup-dev-env.sh`) that copies all .env.example files and validates required variables are set. Output a summary of what each var does and where to get values (e.g., 'OPENAI_API_KEY: Get from https://platform.openai.com'). Mention it in DEVELOPMENT.md.
- lowGetting Running+5 pts if fixed
Unpinned minor versions in package.json and dev dependencies
package.json uses 'catalog:' for all devDependencies, which likely points to a workspace catalog (e.g., pnpm workspace), but the snapshot does not show the catalog definition. A newcomer cannot verify pinned versions without inspecting pnpm-lock.yaml, and the 'catalog:' reference is opaque to someone unfamiliar with pnpm workspaces.
Fix: In package.json or a linked docs file, explain the 'catalog:' pattern (e.g., 'Versions are pinned in pnpm-workspace.yaml'). Better: show exact versions in package.json itself for clarity, or add a comment in the README explaining that the workspace uses a shared version catalog and link to it.
- lowFirst Impression+4 pts if fixed
README assumes LLM domain knowledge without context
The README uses jargon like 'RAG,' 'ReAct,' 'LLMOps,' and 'Function Calling' without definitions. Someone new to LLMs or AI frameworks will not understand what Dify does or why they need it, even though the pitch is clear for insiders.
Fix: Add a short 'What is Dify?' glossary section in the README or link to a 'Glossary.md' file explaining: RAG, agents, workflows, LLM, function calling, observability, and LLMOps in 1–2 sentences each. Or add tooltips in the feature list (e.g., '**RAG Pipeline**: Retrieval-Augmented Generation—tools to...').
Show your score
[](https://latch.fyi/langgenius/dify)Share this analysis
https://latch.fyi/langgenius/difyFixed 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.