Finding skills/rules in the same repo above the project root

Discussions
, ,
1

Skills docs

> Cursor also discovers skills inside nested project subdirectories. A .cursor/skills/ (or .agents/skills/) folder anywhere inside your repository is picked up, so monorepos can colocate skills with the package they apply to

There is similar language about Rules as well.

In my case, I have MonoRepo: MyApp. It has four main subdomain folder: Automation, Backend, Devops, Client.

Some users open the project in Cursor in MyApp, and some open up in a subdomain folder.

I have generalizable skills and rules in the MyApp .cursor folder that I also want the subdomain project-root users to be able to use.

I had thought that in order to do this, I would have to add symlinks in the subdomain .cursor folders for all the skills that I wanted to symlink. And this kind of works - when you open Cursor in the subdomain, you can /-reference the symlinked skills and rules. But when you look them up when opening Cursor in MyApp as the project root, you see the local one and the symlinked child ones.

The text above however adds a nuance - it talks about nested project subdirectories, and also about discovery within the repository.

Bringing to the question: if your project root in Cursor is not at the repository root (ie: you open Cursor in one of the subdomain folders), what is the contract for use and discovery of rules/skills that are located in the same repository but above the Cursor project root?

After some rough testing, it seems that the subdomain Cursor will find the repository root skills and parents, but you cant look them up or get them in /or @. And I am not sure if this is officially supported or not.

Any word on what is supported, if it is "Cursor will find parent directory (above the app root that is opened in Cursor) rules/skills from the same repo, but wont surface them with chat auto-fill? Best practice around this?

4

For monorepos, I’d generally recommend opening Cursor at the repository root rather than at a subdomain or package folder.

The main reason is context. In a monorepo, the useful context often lives across boundaries: backend response shapes, API contracts, shared schemas, generated clients, infra configs, package dependencies, domain conventions, and cross-service assumptions. If you open only a subfolder as the project root, the AI may technically discover some parent rules or skills, but it will have less reliable access to the broader architecture and relationships across the repo.

So even if nested .cursor/rules or .cursor/skills can work in some cases, I would not treat opening subfolders as the best default workflow for AI-assisted development in a monorepo. It may be okay for isolated work, but you lose a lot of the benefit of having the AI reason across the whole system.

My preferred practice would be:

  1. Open the monorepo root in Cursor.

  2. Keep global rules and skills at the root.

  3. Add package-specific or domain-specific rules inside the relevant subfolders.

  4. Let Cursor use both root-level context and localized rules depending on where the work happens.

That gives the AI the best chance to understand the full system while still allowing specific guidance per subdomain.

So my answer would be: yes, you can structure rules and skills for subdomains, but I would avoid making subfolder project roots the normal workflow in a monorepo unless the package is truly independent. For AI coding, opening the repo root is usually the stronger default.

6

@Naufaldi_Rafif thanks for the reply.

The reason some of our developers prefer to open Cursor in the domain subfolder is for when their work is 100% focused only on that section. Our backend and client sections are huge (many GB, 10K plus files), and for a backend or client developer whose work is 100% in that area, the worry is that the extra indexing burden on Cursor will lower efficiency. Is that unfounded?

I personally have found - when opening Cursor in our root - that auto-complete after @name-of-backend-rule simply fails and wont find it sometimes. But when I open Cursor in backend, it finds it no problem, fraction of a second.

So the main question is: once Cursor catches up with indexing - do you still pay a penalty (memory, perf, efficiency, risk of OOM, quality, etc) for opening in the root of the monorepo, even if your work is completely focused in a domain?

I am trying to accommodate this by putting all global rules and skills at the root AND ALSO symlink them to the domain folders - under the (mistaken?) belief that if you open Cursor in the domain folder, it wont be able to see parent root rules/skills. However, with experiment on applyAlways:true rules in the root, it looks like they are applied when opening in the subdomains (though dont know if that works for apply-intelligently or is actually supported or just accidentally supported).

I am happy to mandate that people only open at the root - but only if I know it wont come back to bite us and people doing domain-only work wont suffer (and the failures to find domain rules with auto-complete to me is a big caution sign).