instructa/ai-prompts targets five editors with five different file conventions

Five tools, five ways of carrying the same text

The usage table is the most useful part of the project and also the most awkward, because each editor takes the same instructions by a different route.

Cursor takes project rules inside a .cursor/rules/ directory, with a file such as .cursor/rules/cursorrules.mdc, and applies them automatically. GitHub Copilot takes a .github/copilot-instructions.md file in the repository root holding natural language instructions in Markdown. Zed takes a .zed/ directory with a .zed/settings.json file for project specific settings. Windsurf takes a .windsurfrules file in the project root. Cline takes no file at all: you open the extension settings, find the Custom Instructions field, and paste.

So three of the five are directories with a named file inside, one is a single root file, and one is a paste into a UI field. There is no format that works across all five, and a prompt written for one is not portable to another without editing.

The table also links each tool's own documentation rather than restating it, which is the right call given how fast those conventions move. One of the links points at a blog post about Cursor rules in version 0.45, so the guidance behind this table was written against a specific Cursor release.

The repository's own format is Cursor's format

The contribution flow is four steps: create a folder under prompts/, add metadata in aiprompt.json following the example in prompt-template/, include .mdc files with YAML front-matter for rules, and open a pull request.

That third step decides the shape of everything else. .mdc is Cursor's Markdown-with-front-matter extension, which is the same convention the usage table tells you to use for Cursor project rules. So the native format of this collection is Cursor's format, and the other four tools are secondary targets reached by editing.

The repository also carries a .cursor/ directory at its own root, which means the project uses the convention it documents rather than only describing it.

Alongside prompts/ there are data/, images/, public/, scripts/, prompt-template/, and a .github/ directory, with pnpm-lock.yaml and pnpm-workspace.yaml at the top. A workspace file in a content repository means the collection is laid out as a package tree, which is more structure than a folder of Markdown needs on its own and is explained by the scripts below.

The table of contents links a section the page does not have

The table of contents lists five entries: Usage, Contributing, Community and Support, Related Projects, and License.

Four of them exist. The page has a Usage section, a Contributing Prompts section, a Community and Support section, and a License section. There is no Related Projects section anywhere in it.

The page also has a Social section, listing an X account and a Bluesky account, that the table of contents does not mention.

So the navigation is wrong in both directions: one anchor points at nothing, and one section is unlisted. Small thing, and the kind of thing that survives because nobody clicks every entry in a five item list. It does mean the Related Projects entry is the one to check before assuming there is a companion repository to look at.

No install or build instruction appears anywhere in the README

The README covers two workflows, using the prompts in an editor and contributing new ones. It never explains how to build or validate the collection, and it gives no command for either.

Those commands exist. package.json defines three: test:structure, which runs node scripts/validate-structure.js, build-index, which runs node scripts/build-index.js, and all-scripts, which runs test:structure followed by build-index.

Two details stand out. The package entry point is declared as scripts/build-index.js, so the main field of a content repository points at the index builder rather than at anything importable. And both scripts are undocumented in the page, which means anyone who wants to check the collection before trusting it has to read package.json to find out that a check exists.

The README does link CONTRIBUTING.md for the full contribution details, so the gap is specifically about running the tooling, not about contributing a prompt.

test:structure validates the folder layout, not the prompt text

The name of the script says structure, and the dependency list says how it works. There is exactly one runtime dependency, zod at 3.24.2, pinned to an exact version with no range.

For a repository whose entire output is Markdown, one schema validator is the whole toolchain. That means the thing being enforced is the shape of each entry: a folder under prompts/, an aiprompt.json carrying metadata, and .mdc files with YAML front-matter. What is not being enforced is anything about the prose inside those files, which is the part that actually changes how an editor behaves.

So the collection has a machine-checked contract for its packaging and a human contract for its content. The contribution guide covers the second, and there is no automated check described for it.

The three script names also explain why the workspace file is there. A validation step and an index build step are two packages' worth of behaviour in a repository with one package.json.

The toolchain is pinned through devEngines with onFail set to download

The package manager and the runtime are both declared in a devEngines block rather than in the usual engines field. pnpm is pinned at 11.1.1 and Node at 24.15.0, and both carry onFail set to download.

That setting is the notable part. It means a machine without the right package manager or runtime does not fail, it fetches them. For a repository whose contribution flow is four manual steps, that is a deliberate convenience: you clone, you run, and the exact tool versions arrive.

It also means the pinned versions are not the versions most contributors have. Node 24.15.0 and pnpm 11.1.1 are specific point releases, so a contributor on a different patch release is switched rather than accommodated, and a machine that cannot reach the download source is stuck where a plain version range would have let it proceed.

The lockfile is pnpm-lock.yaml, consistent with the package manager declaration. Between the workspace file, the lockfile, and devEngines, this repository pins three things about its own tooling, which is more rigor than a Markdown collection strictly needs.

Version 1.0.0, no releases, and a last push in May

package.json reports version 1.0.0. The repository has no GitHub releases, and the last push to it is dated 2026-05-13.

So a 1.0.0 that was never cut as a release and has not moved since May. For a collection of static text that is defensible, since there is nothing to release and content is versioned by the folder it lives in. It does mean there is no artifact to pin, no changelog tied to a tag, and no signal that tells a user whether the copy they cloned matches what the site is serving.

The hosted version lives at instructa.ai/ai-prompts, and the README points there as the place to try the collection before using it in an editor. Two copies, one on the site and one in the repository, with the repository as the one under version control and no stated relationship between their update cadence.

The rest of the project surface is small and conventional: community support through GitHub Discussions for ideas and help and GitHub Issues for bugs and new prompt categories, a social section with an X account and a Bluesky account, and an MIT license that permits use, modification, and distribution under those terms.

Editorial conclusion

ai-prompts fits someone assembling project rules for one editor who wants a starting set to edit rather than a framework to install. Three things to settle before you adopt it. Which editor you actually use, since the repository's native format matches Cursor and the other four need conversion by hand. Whether you want the content or the tooling, because the two scripts that validate and index the collection are discoverable only from package.json. And how much of the collection you will read, since a curated folder of prompts is only as good as the review you do of each file you drop into your repository, and a rules file is code that runs on every prompt you type from then on.

Frequently asked questions

Official sources

1. instructa/ai-prompts on GitHub
2. Issues
3. License: MIT
4. Project website
5. README