# opensource.builders: an alternatives directory that compiles its findings into agent skills > opensource.builders is a Next.js site that catalogues open-source alternatives to proprietary software, compares them feature by feature, and then turns a selection of those features into a skill file that an AI coding agent can use, with links to the reference code. The directory half is the obvious part; the skill generator is the idea that makes it more than a link list. **junaid33/opensource.builders** — Find and build open-source alternatives - Repository: https://github.com/junaid33/opensource.builders - Website: https://opensource.builders - Stars: 1,317 · Forks: 195 - Language: TypeScript - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/junaid33-opensource-builders ## A directory, a comparison table and a code generator opensource.builders does three things, and the README lists them as the feature set. Browsing alternatives lets you discover open-source alternatives to proprietary applications. Comparing applications gives you feature by feature comparisons between apps. The Skill Builder generates AI coding agent skills from curated features, with implementation details and code references. And there is multi-agent support, so the generated skill can be installed in Claude Code, Cursor, Droid or Codex CLI. The framing sentence in the README is that you can find open-source alternatives to popular software, compare features side by side, and generate skills with code references that help an AI build those features in your project. The interesting move is the third one. A directory of alternatives is a page of links, and links are of limited use to a coding agent that needs to know how a feature is actually implemented. Reframing the same curation as a skill, with pointers into the source repositories, is what turns a reference site into something a tool can consume. ## What a generated skill actually contains The Skill Builder lets you select features from multiple open-source projects, and then generates a skill, which the README defines as a guide with specific code references that your AI coding agent can use to build those features in your project. The contents of a skill are enumerated, and the list is short and precise. It includes feature descriptions and implementation notes, links to reference code in GitHub repositories, and documentation URLs for deeper context. That is a deliberate composition. The descriptions tell the agent what the feature is and what it does, the implementation notes capture the approach, the repository links are the ground truth an agent can read, and the documentation URLs are there for the cases where the code alone is not enough. Selecting features across multiple projects is the other important detail, because real applications borrow from each other, and a skill that draws a scheduling approach from one project and a data model from another is closer to what a developer would actually assemble. The output is a single file, `SKILL.md`, which is what the install instructions copy around. ## Four agents, four file conventions Installing a generated skill is four different commands, because the agent ecosystems disagree about where a skill lives. The install step is the same in each case, taking the downloaded `SKILL.md` from the downloads folder and putting it where the agent looks, but the destination and the mechanism differ. For Claude Code you create a skills directory in the project and copy the file in. For Cursor you append the content to a rules file, which is the markdown rule format. For Droid you create a skills directory under the factory directory and copy the file. For Codex CLI you append the content to the `codex.md` file in the project. ```bash mkdir -p .claude/skills && cp ~/Downloads/SKILL.md .claude/skills/ cat ~/Downloads/SKILL.md >> .cursor/rules/skill.mdc mkdir -p .factory/skills && cp ~/Downloads/SKILL.md .factory/skills/ cat ~/Downloads/SKILL.md >> codex.md ``` The pattern is worth noting as a fact about the ecosystem rather than about this project. Two of the four install paths are a copy into a directory with a name the agent scans, and two are an append to a file the agent reads, and only one of the four preserves the structure of the skill directory. That is a small tax on the user, and it is the tax that any tool producing agent instructions currently pays. ## A headless CMS with a curated data model The stack is Next.js with Keystone as a headless CMS, PostgreSQL for storage and Tailwind CSS for styling, with the Radix UI primitives in the dependency list. What that combination tells you is that the content, not the page, is the product. The repository layout backs that up with a `features/` directory holding Keystone feature modules, a `config/` directory, `actions/`, `hooks/`, `lib/`, `pages/`, `app/`, `types/`, a `skills/` directory, a `migrations/` directory and both `schema.prisma` and `schema.graphql` at the root, plus a `keystone.ts` entry point and a `.keystone/` directory for generated types. The `migrate:gen` script is instructive, since it runs the Keystone build, then a script at `features/keystone/view-order/generate-view-order.ts`, and then the Prisma migration command, which means the project has a notion of an explicit view order for records and generates it as part of the schema pipeline. Curated ordering is exactly what a directory needs, since a list of alternatives sorted by nothing is a list, and one ordered by usefulness is a product. The contributing document is named CONTRIBUTING_TO_OSB.md and covers adding applications, capabilities and improving the platform, which tells you the catalogue is maintained by contribution. ## Running it locally takes a database, and deployment is one click The getting started section is short, and the development script does more than it looks. The `dev` script is `keystone build --no-ui && npm run migrate && next dev`, so starting the app first builds the CMS schema, then applies the database migrations, and only then starts the Next.js development server, with a separate `migrate` script that runs `prisma migrate deploy`. You then open `http://localhost:3000`. The README lists the usual package manager variants, so `npm run dev`, `yarn dev`, `pnpm dev` and `bun dev` are all equivalent. The practical consequence is that you need a PostgreSQL instance before the app will start, which is the one piece of setup a newcomer will not guess from a README that says only run the dev server. For deployment there are two one-click paths, a Vercel button that clones the repository and provisions a Postgres store, and a Railway button, with a `railway.toml` in the tree for the latter. The licence is stated as MIT in the README, and the repository also carries a `THIRD_PARTY_NOTICES.md` file for the licences of the components it builds on. ## The site itself is built on model providers and MCP The dependency list contains several entries that are unusual for a content site and tell you what the Skill Builder is doing under the hood. There is `@ai-sdk/mcp` and `@modelcontextprotocol/sdk`, so the project speaks the Model Context Protocol, `@openrouter/ai-sdk-provider` for model access, and `@ai-sdk/react` for the React side of the AI integration, alongside the GraphQL tooling from `@graphql-tools/schema` that the headless CMS needs. In other words the site does not merely link to reference code, it hosts a model backed generation step that produces the skills. That is the risk to hold in mind when using it. A generated skill is a model output that points at source code, so the quality of the output depends on the model, the prompt and the curation behind it, and the repository does not document an evaluation or review process for generated skills. The package manifest also carries the name `weekday-keystone`, which is a leftover from an earlier project, and a version of 0.1.0 with the package marked private, since the deliverable is the site rather than a library. ## The curation is the product, and it needs maintainers The final thing to weigh is the shape of the work. Everything else in the repository is plumbing, and the thing a user actually gets is a set of alternatives with honest comparisons and links to code that implements the features. That is maintained by people, not by software, and the contributing guide exists because the catalogue only stays useful if applications are added, capabilities are described accurately and comparisons are kept current as projects move. The last push was on 2026-09-01 and the repository publishes no GitHub releases, so there is no version history to read and the site is deployed from the main branch. The licence position deserves a note as well, since the README states MIT while GitHub's own classification of the repository's licence is one it cannot categorise, and the presence of the third party notices file suggests a mixture of licence terms inside the tree. For a reader deciding whether to trust a generated skill, the useful checks are unglamorous. Read the linked source, check that the comparison matches the project as it is today, and treat the skill as a starting point for an agent rather than as reviewed advice. ## Conclusion Adopt opensource.builders if you are choosing an open-source replacement for a proprietary tool and want the comparison and the implementation pointers in one place, or if you want your coding agent to have a concrete reference for a feature you are about to build. Do not adopt it as a dependency, since it is a site and a content pipeline rather than a library, and treat its catalogue as a starting point rather than a verdict, because the value is only as good as the curation behind it. Before you rely on it, read CONTRIBUTING_TO_OSB.md to see how applications and capabilities are added, and check the licence position yourself, since the README states MIT while GitHub classifies the repository's licence as one it cannot categorise. The last push was on 2026-09-01 and the repository publishes no GitHub releases. ## FAQ ### What does the Skill Builder in opensource.builders produce? It generates a skill file from features you select across multiple open-source projects. Each skill includes feature descriptions and implementation notes, links to reference code in GitHub repositories, and documentation URLs for deeper context. ### Which AI coding agents does opensource.builders support? Claude Code, Cursor, Droid and Codex CLI. The install paths differ: a copy into `.claude/skills/` for Claude Code, an append to `.cursor/rules/skill.mdc` for Cursor, a copy into `.factory/skills/` for Droid, and an append to `codex.md` for Codex CLI. ### How do I run opensource.builders locally? Run `npm run dev`, with yarn, pnpm or bun as alternatives, and open http://localhost:3000. The dev script builds the Keystone schema, applies the Prisma migrations and then starts the Next.js development server, so a PostgreSQL database has to be reachable first. ### What tech stack does opensource.builders use? Next.js as the React framework, Keystone as the headless CMS, PostgreSQL as the database and Tailwind CSS for styling, with Radix UI primitives. The content is modelled with Prisma and exposed through GraphQL, and the repository carries migration scripts and a Keystone feature directory. ### How do I add an application to the opensource.builders catalogue? The contributing document, CONTRIBUTING_TO_OSB.md, covers the guidelines for adding applications and capabilities and for improving the platform. The repository carries a THIRD_PARTY_NOTICES.md file and the README states an MIT licence. ## Sources - [Issues](https://github.com/junaid33/opensource.builders/issues) - [junaid33/opensource.builders on GitHub](https://github.com/junaid33/opensource.builders) - [Project website](https://opensource.builders) - [README](https://github.com/junaid33/opensource.builders/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/junaid33-opensource-builders