Skill, rule, or memory file: picking the mechanism

In Claude Code

In terms of this harness, all three of these are available under their own names — the most separated I've seen

As said, rules can be conditional by defining an array of paths in the file's frontmatter

---
paths:
  - "src/api/**/*.ts"
---

# API rules

- Every endpoint validates its input.
- Errors use the standard response shape.

Without paths, it'll be loaded upon tool's start with the same priority as CLAUDE.md so you get a tidier setup, not save any context. With paths — it'll only load when a file with path matching any of the rules is accessed.

Skills can have a frontmatter flag to indicate it's meant to be used only when you ask

---
description: Deploy the application to production
disable-model-invocation: true
---

Only for this harness, two things:

• Claude Code reads CLAUDE.md, not AGENTS.md. If you already have the latter for other tools, put @AGENTS.md at the top of a CLAUDE.md instead of maintaining two files

• @imports don't save tokens — they're inlined during the tool's start as if you were to just paste the imported content; splitting a big memory file into multiple ones helps with its readability and that's all

To see which memory files were loaded by the current session, run /context

In Codex CLI

The Codex CLI uses two mechanisms, not three, which are AGENTS.md and skills from the .agents folder. There's no separate rules file, instead the scope of an agent is defined by where you put its AGENTS.md

AGENTS.md                       ← the whole repo
services/payments/AGENTS.md     ← sessions launched inside services/payments/
.agents/skills/release/SKILL.md ← the release procedure

In this example you can see that there's a file in the root of the project which will be used for all the sessions started in it, another one under services/payments which will be used for sessions started there for payments-related code, and a skill file for release under .agents/skills.

Whenever you run the CLI, it looks into the project root directory and then walks down to the cwd (current working directory) picking up at most one file per directory and merging them in a way that what's located deeper wins. That's how OpenAI recommends to address the case when multiple teams in an organisation need their own sets of rules

Although it's not as granular as with rules, it's worth to mention that the scope here is defined by the directory where you launch the session from (not what code you're working on), so all the AGENTS.md files from the root to cwd will be loaded no matter if the session operates in this area; and even if you were to set up a payments-specific one, it wouldn't have any effect for sessions started in the project's root

That said it doesn't mean that you can't nest memory files. It just means that this way you can configure which instructions will be loaded, but not when they'll actually consume the context (as they always do so during session's start). So still, even with well organised nested AGENTS.md files, it's always good to keep your procedures in skills

The CLI searches for skills in .agents/skills folders of all the directories from cwd up to the project's root as well as in $HOME/.agents/skills and /etc/codex/skills. In terms of a skill's metadata, the only thing you can set there is its name and description via SKILL.md frontmatter; if you want it to be invocable only manually, you can set that up in an adjacent agents/openai.yaml file:

policy:
  allow_implicit_invocation: false

That will make sure Codex won't invoke this skill automatically but you'll still be able to use it with the $deploy command. This file also serves to display the skill's metadata and its tool dependencies

The only thing to keep in mind is that the CLI stops loading AGENTS.md files once the combined size of them reaches project_doc_max_bytes, which is set to 32 KiB by default. Past that the instructions are simply not there, and the only note of it is a troubleshooting entry in the docs suggesting you raise the value

In GitHub Copilot CLI

Three types of mechanisms are all there — even though the names are GitHub's own, they don't represent the whole industry.

You can run copilot init in a project and it will create the file .github/copilot-instructions.md by analysing your codebase without modifying anything. This is the starting point but keep in mind that the result is only a draft as it is based on already stated in the repo information, which is the kind of data the memory file should omit.

Path-scoped instructions - placed in .github/instructions/ and named like <name>.instructions.md — have globs defined in the frontmatter. It's good to focus on single topic per file to make it easily digestible.

For example, a glob for .ts and .tsx files with an instruction saying that under strict you shouldn't add any to make an error go away:

---
applyTo: "**/*.ts,**/*.tsx"
---

TypeScript in this repo compiles under `strict`. Do not add `any` to make an error go away.

The repo-wide and path-scoped instructions are stacked instead of being replaced, so if the file being worked on matches, both sets are used.

Skills — the most important part is the list of sources, check for yourself what the binary outputs under its help section for the skill subcommand.

copilot skill --help

You can see it fetches skills from Anthropic's .claude/skills/, GitHub's own places and the vendor-neutral .agents/skills/ location. If you are using multiple tools in a team I recommend to standardise on .agents/skills/ to make it easier for all of them to find the skills you create there.

Finally, worth noting that the subcommand for listing skills outputs what it has actually found, grouped into project, personal and builtin.

In Cursor

Cursor is the harness where these three arrived bundled into a single mechanism, and it's now on its way to splitting them, so it's good to follow it as it does it exactly the same way as I suggest here. It stores rules as .mdc files under .cursor/rules/, versioned in git. There are three frontmatter fields that control how the rule is loaded:

---
description: TypeScript conventions for this project
globs: **/*.ts
alwaysApply: false
---

These are the four behaviours Cursor describes:

• Always Apply

• Apply to Specific Files

• Apply Intelligently

• Apply Manually

The first two are connected with the frontmatter fields I mentioned. For the first one — alwaysApply: true — the rule is loaded in every session, for the second — a globs pattern — if any of the files matching the given pattern is opened. The third behaviour — "Apply Intelligently" — is connected with having a description and not having globs. In this case, it's up to the model to decide based on the description if the rule applies.

Given the third behaviour above, Cursor has changed its mind compared to its past self. It turns out that for rules with a description but without globs or alwaysApply: true, it moves them to .cursor/skills/ using a built-in migrate-to-skills skill.

This way it's obvious that skills are all about having a description and for the model to decide if they apply based on it (the same as for the "Apply Intelligently" behaviour). They can either live in .cursor/skills/ or ~/.cursor/skills/. The same for slash commands in .cursor/commands/, they too get moved and have disable-model-invocation: true set so they stay type-invoked.

The line is now very clear — rules are about always-applied or glob-scoped features, skills either live in .cursor/skills/ or ~/.cursor/skills/ and are about the model deciding to use them based on their description. We can even replace a simple list of rules with AGENTS.md if it's more convenient for a team using multiple tools; generally, it's best to aim to keep rules under 50 lines which is stricter than in other tools but also very helpful.

In Gemini CLI

In the Gemini CLI, GEMINI.md covers the first of these jobs and partly the second, while skills cover the third — a top-level subcommand as of 0.46.0.

There's actually few levels of the GEMINI.md file: the one in ~/.gemini/, and for every project the ones in workspace directories and in their parent directories up to the trusted root. It's all get concatenated and used as the context in every prompt; also, there's a little feature in place that whenever a tool touches a file it tries to find a GEMINI.md in the directory of that file and in the higher-level directories until it finds the trusted root — so a nested GEMINI.md can be seen as an analogue of a rule bound to a path, being "activated" once the work touches some area. You can't target patterns with it, just directories though, but if you already have a repo on AGENTS.md you can point the context.fileName setting at both instead of maintaining copies.

{
  "context": { "fileName": ["AGENTS.md", "GEMINI.md"] }
}

In the GEMINI.md file there's also a special syntax for @file.md includes which you can use within the context, and the /memory show command shows you the current state of the memory.

The skills. They live in ~/.gemini/skills/ or ~/.agents/skills/, and .gemini/skills/ or .agents/skills/ within projects, with .agents/skills/ taking precedence over .gemini/skills/ inside each tier. There's gemini skills list, install, link, enable and disable.

Just a note that before assuming that some skill is bugged you should check if the project is trusted — there's a behaviour that if the project is not trusted it ignores project skills, showing a notice about skipping project agents until the project root is trusted:

Skipping project agents due to untrusted folder. To enable, ensure that the project root is trusted.

Given that in such case the skills defined on the user level are loaded anyway, it creates an impression that some of the skills are missing instead of a trust issue.

In Kimi Code CLI

2 main parts of Kimi Code CLI are supported:

• Persistent instruction file (it's AGENTS.md, which is what the majority of other tools use as well)

• Skills

Memory file.

It supports it on a per-project basis (by having AGENTS.md file either in the root of the project or in .kimi-code/ subdirectory) and globally (using $KIMI_CODE_HOME/AGENTS.md — defaulting to ~/.kimi-code/AGENTS.md); if you use more than one harness, consider using ~/.agents/AGENTS.md in your actual home directory.

Skills.

It also supports skills, and their locations span the project level (.kimi-code/skills/ and .agents/skills/), the user level (~/.kimi-code/skills/ and ~/.agents/skills/) as well as any other directories listed under extra_skill_dirs in your config.toml.

You can invoke them using /skill:<name> and even pass some arguments to them, like here:

/skill:review-pr #1234

There are two frontmatter fields that are responsible for the automatic triggering of instructions:

name: deploy
description: Push the current build to production.
type: flow
whenToUse: Only when the user explicitly asks to deploy.

• type — set it to flow (it's human-only, the model can't call it)

• whenToUse — this is an inverse control property, so here you can limit cases in which you want this instruction to be run by the model

No rule layer.

There's no rules layer here (no support for globs that would allow it to automatically load an instruction file when the agent enters a file with a given path), so we can't use the middle row of the table. There are two ways one could go about creating their own convention for a subdirectory:

• add it to the always-loaded AGENTS.md file, and bear the cost on every turn

• create a skill with whenToUse set to the name of the subdirectory, and make peace with the fact that the model will trigger it based on the description instead of the path

The latter is the best solution if it's a lengthy instruction, the first one might work for single-lines conventions (which is what majority of such conventions are about).