# OpenDirectory: sixty-four skills, five install paths, one generated table > OpenDirectory is a library of agent skills aimed at founders who dislike marketing, delivered as a folder of instruction files that you install into whichever coding agent you use. The interesting engineering is not the skills but the plumbing: eight target flags, five installation routes including a plugin marketplace and a third-party zip downloader, an installer that always runs the latest version, and a readme whose featured table is regenerated by a pre-commit hook. **Varnan-Tech/opendirectory** — AI Agent Skills built for Founders who hate Marketing - Repository: https://github.com/Varnan-Tech/opendirectory - Website: https://www.opendirectory.dev - Stars: 670 · Forks: 74 - Language: Python - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/varnan-tech-opendirectory ## Five routes to the same folder of text, and each one has a sharp edge The product is a directory. Everything else in this repository exists to get that directory into whichever agent you happen to run, and there are five documented routes because there is no single place all agents agree to read from. The primary route is the package runner: ```bash npx "@opendirectory.dev/skills" ``` which needs no global install and takes a target flag naming your agent. The second route goes through a separate skills registry, which installs the entire catalogue at once, auto-detects your agent, and takes a flag to narrow it to one skill. The third is for people whose agent has no command line, and it is the awkward one: you copy a skill folder's URL from the repository, paste it into a third-party zip-downloading website, then drag the resulting archive into the agent's own skills panel. The instructions even warn you about the sharp edge in that flow, because for some skills the main instruction file sits one folder down and you have to upload the specific folder that contains it rather than the one you clicked. The fourth route is a plugin marketplace the agent can add natively. The fifth is a separate assistant with its own flow. Five adapters is the honest cost of supporting eight agents, and it is also five code paths to keep working as those agents change. ## The installer always runs the latest version, and nothing updates what it installed One line in the quick start does more work than it appears to: the runner fetches and executes the newest version of the CLI automatically, so there is no global install and nothing to keep up to date. Node.js is the only stated requirement. Consider what that means in two halves. The half that runs is never pinned, so the code that knows where Claude Code keeps its skills, or how to shape a plugin manifest, can change on any day without you choosing to take it. The half that is installed is entirely static: a skill you installed last month is a folder of files on disk that nothing will ever update, because there is no daemon, no sync and no version marker in the target directory. So you end up with an installer that moves and an artefact that does not, and the drift is invisible until an agent silently reads an instruction file that no longer matches the tooling around it. That asymmetry is tolerable for a tool whose output is text, and it is the reason to re-read a skill file when you notice an agent behaving oddly rather than reaching for a reinstall, which will fetch new installer code and leave the old instruction file exactly where it was. ## The bulk install puts sixty-four instruction files in front of your agent The list command reports sixty-four specialised skills across go-to-market, growth and developer tooling, and one of the installation routes takes the entire set in a single command, with a flag to narrow it if you want one. Sixty-four files on disk is not the problem; sixty-four is the problem when the agent has to choose among them on every task. An agent presented with that many candidate procedures will pick the closest match rather than the best one, and the ones you never intended to use still compete for attention. The cost is not context budget in the token sense so much as selection quality: a catalogue that grows monotonically gets worse at its job as it gets bigger, unless something filters it. Nothing in the routes described here ranks or filters beyond the interactive browser's categories and search, and the featured table in the readme covers twelve entries out of sixty-four. The practical default is therefore the narrow one: install the two or three skills that map to jobs you actually have, and let the agent learn them well, rather than installing the field. The bulk route makes sense if you are evaluating the catalogue, not if you are trying to use it. ## The featured table is build output, which is why twelve of sixty-four appear The root package manifest contains the answer in a block that looks like housekeeping. A staged-file hook is configured to watch the skills directory, and when anything inside it changes, two scripts run and the regenerated readme and contributing guide are staged automatically. The popular-skills table you are reading is therefore generated from the directory rather than written by a person, and that explains a detail worth noticing: the catalogue holds sixty-four skills and the table shows twelve. The caption says the ranking is by artefact quality and practical value, which means the twelve are chosen by whatever criterion that script applies. Two things follow. A good skill can be missing from the table without anyone deciding it should be missing, so the table is a starting point rather than a shortlist. And the readme cannot drift out of step with the directory, which for a repository whose entire product is a growing pile of text files is worth more than a hand-curated page would be. The same hook means the contributing guide stays in step too, so a new skill arrives with instructions already written for it. It is a small piece of automation that removes a whole category of maintenance from a project made of dozens of independent files. ## A TypeScript toolchain whose runtime is somebody else's agent The build side is a private workspace package at version 1.0.1, with a workspace file, a lockfile and a packages directory holding what actually ships. Look at its dependency list and notice what is missing: there is no runtime dependency section at all. Everything is a development dependency, and the list is entirely tooling. A test runner, the TypeScript runner that executes the plugin build script, an image library, a schema validator, a YAML parser, a bundler, the hook manager and the staged-file linter. There is nothing to install at run time because there is no runtime; the work happens inside your agent, and this repository's job is to place files where that agent will read them. The consequence is that the toolchain carries the project's whole maintenance cost while contributing none of its behaviour, which is a good trade for a project whose value is content. Two details are worth a second look. The hook manager is wired into the prepare script, so a contributor's clone installs its own commit hooks on install. And the package pins overrides for two transitive packages, which is the fingerprint of a project that has met a resolution problem once and decided not to meet it again. ## Eight target flags, one of which is backed by a real artefact in the tree The supported list is Claude Code, OpenCode, Codex, Gemini CLI, Anti-Gravity, OpenClaw, Hermes and Manus AI, each with its own flag, and the flags are named after the agent rather than after a path or a file format. For a user that is exactly the right abstraction: you say which agent you run and the tool figures out the rest. For maintenance it is the opposite, because each flag encodes a convention about where that particular agent expects to find a skills folder, and any of those agents can move its directory without a version bump here. The repository gives one of them a stronger position than the rest. There is a plugin definition directory at the top level and a build script whose only job is producing that plugin, which is what the native marketplace route installs from. So one agent in the list is served by a first-class artefact that the build regenerates, and the other seven are served by path conventions held in the installer. That is where the bugs will be, and it is also why the installer being unpinned by default matters more here than it would in a project with a single target: a new release of the installer can quietly change what it writes into another agent's directory. ## One featured skill guesses email addresses from a spreadsheet It is worth reading the table as a menu of what a founder might delegate, and as a list of exposures you would be owning. One entry verifies cold emails, enriches lead lists and autonomously guesses addresses from a spreadsheet file. Verifying an address you already have and manufacturing one you do not are different activities with different legal exposure, and the second one is the kind of capability that gets a sending domain flagged. Others in the table lean on named external models and datasets: one analyses video hooks against a social platform's brain-imaging model, one scrapes a job board daily and reports new listings without duplicates, one scores download velocity on a package registry to find maintainers whose adoption is accelerating, one audits a pricing page against twelve named principles, and one rewrites marketing copy against eighteen named patterns of AI-generated filler with before and after notes. The last of those is the most useful shape on the list, because it names what it is removing. The first is the one to think twice about. A skill is a set of instructions, the agent executing them is yours, and the judgement about whether a particular delegation is appropriate never leaves your desk. ## Conclusion OpenDirectory is worth an hour of your time if you are the kind of founder who knows exactly which two or three marketing jobs you keep avoiding, because the skills are installable text with no runtime to maintain and you can read one before you trust it. It is not worth installing the whole catalogue, and it is not a substitute for judgement on anything that touches cold outreach. Three things to check first. Read the skill file before you install it, since a skill is a set of instructions your agent will follow and you are the one who approves it. Install per agent rather than globally if you use more than one, since the target flag is the only thing keeping two agents from sharing a directory. And check which entries in the table you actually need, because the featured twelve are produced by a script rather than chosen by a person, so the absence of a skill from that table tells you nothing about its quality. ## FAQ ### How many skills does OpenDirectory have and how do I install one? The catalogue holds sixty-four specialised skills across go-to-market, growth and developer tooling. You install one with a single package-runner command that names the skill and passes a target flag for your agent, and no global install of the CLI is required. ### Which coding agents does the OpenDirectory CLI support? Eight, each with its own target flag: Claude Code, OpenCode, Codex, Gemini CLI, Anti-Gravity, OpenClaw, Hermes and Manus AI. The interactive browser, the list command and the install command all take the same flag. ### What do I need installed to use the OpenDirectory CLI? Node.js. The instructions are explicit that the package runner fetches and runs the latest version of the CLI automatically, so there is no global install and nothing to upgrade. ### What does installing through skills.sh put on my machine? It installs the whole catalogue in one command and auto-detects your coding agent. You can narrow it to a single skill with a flag, and add a global flag to install into the user-level skills directory instead of the current project. ### How do I install an OpenDirectory skill into the Claude desktop app? Copy the skill folder's URL from the repository, paste it into a third-party zip download site to get an archive, then in the app open Customize, go to the Skills tab, press the plus button and upload the archive or the extracted folder. The instructions warn you to upload the specific folder containing the skill's main file, which for some skills is one level down. ### How is the list of popular skills in the OpenDirectory readme maintained? It is generated. A staged-file hook watches the skills directory and, whenever anything in it changes, runs scripts that regenerate the readme and the contributing guide before the commit lands. That is why twelve of the sixty-four skills appear in the featured table. ## Sources - [Issues](https://github.com/Varnan-Tech/opendirectory/issues) - [License: MIT](https://github.com/Varnan-Tech/opendirectory/blob/main/LICENSE) - [Project website](https://www.opendirectory.dev) - [README](https://github.com/Varnan-Tech/opendirectory/blob/main/README.md) - [Varnan-Tech/opendirectory on GitHub](https://github.com/Varnan-Tech/opendirectory) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/varnan-tech-opendirectory