Understanding the Three Concepts

Rules or project descriptions address the issue of what should always be known. For example, how the project is built, the coding style, which directories should not be modified, and what tests to run before submission. This content should be short, stable, and long-lasting.

Skills address the issue of tasks that need to be initiated only under certain conditions. For instance, generating release notes, checking commit messages, organizing MR descriptions, or conducting code reviews according to team processes. Skills are not always part of the context but are automatically selected by the tool when relevant or manually invoked by the user.

MCP, or Model Context Protocol, resolves the issue of connecting external tools and data sources. For example, allowing AI to access Feishu documents, GitHub, Figma, browsers, databases, and internal knowledge bases. MCP does not tell AI how to perform tasks; it is responsible for integrating tools and data.

Claude Code: Based on CLAUDE.md, Skills Manage Processes, MCP Connects Tools

The core project description file for Claude Code is CLAUDE.md. It can be placed in the project root directory or in .claude/CLAUDE.md. The project-level CLAUDE.md is suitable for writing shared team rules, such as architecture descriptions, build commands, test commands, and common workflows. Personal preferences can be stored in CLAUDE.local.md and added to .gitignore.

If there is already an AGENTS.md in the project, Claude Code officially recommends creating a CLAUDE.md and importing it using @AGENTS.md. This avoids maintaining duplicate content while allowing additional Claude Code-specific instructions in CLAUDE.md.

Claude Code also has .claude/rules/. This functions like breaking CLAUDE.md into multiple maintainable small files, with path range control via paths frontmatter. For example, src/api//*.ts applies only API development rules, while frontend//*.tsx applies only frontend component specifications.

Claude Code’s skills are located in .claude/skills//SKILL.md or ~/.claude/skills//SKILL.md. Project-level skills are effective only for the current project, while personal skills apply to all projects. They can also be manually invoked using /skill-name or automatically loaded by Claude based on the description.

In terms of MCP, Claude Code supports adding remote HTTP, SSE, or local stdio servers via claude mcp add. Currently, HTTP is more recommended; SSE has been marked as deprecated in the official documentation. The MCP’s scope can differentiate between local current projects, project sharing, and user global scenarios.

Codex: AGENTS.md as Project Agreement, Skills as Process Packages, Rules Not the Same Type of Rules

The project description file for OpenAI Codex is AGENTS.md. Codex reads global and project-specific AGENTS.md during startup and merges from the repository root directory to the current working directory. The closer to the current directory, the more specific the description, which overrides the more general descriptions above it.

Codex also supports AGENTS.override.md. This file is suitable for temporarily overriding the normal AGENTS.md, such as when a subdirectory has special test commands or when you want to conduct an experiment that differs from the usual process. The official documentation also mentions that additional fallback filenames can be configured via project_doc_fallback_filenames.

Codex’s skills use the Agent Skills standard. Typically stored in .agents/skills in the repository, personal global skills are located in $HOME/.agents/skills. A skill is a directory that must contain SKILL.md and may include scripts, references, and assets. Codex first checks the name and description, and only loads the complete SKILL.md when the task matches, which is known as progressive disclosure.

A common misunderstanding is that Codex also has Rules, but they are not the same as Cursor’s “project behavior rules.” Codex’s official rules are primarily used to control which commands can bypass the sandbox, essentially serving as execution policies. For example, allowing certain gh commands, blocking dangerous commands, or requiring confirmation for each execution. They are closer to security approval rules and are not suitable for writing project backgrounds or coding styles.

In terms of MCP, Codex places MCP configuration in config.toml, defaulting to ~/.codex/config.toml, but it can also be used in trusted projects with .codex/config.toml. Servers can be added using codex mcp add, or the [mcp_servers.] table can be manually edited. This configuration is shared between CLI and IDE extensions.

Cursor: Mature Project Rules, Supports AGENTS.md, Agent Skills, and MCP

Cursor’s Rules are the most familiar set for many users. Project rules are placed in .cursor/rules, and the files can be .md or .mdc. .mdc supports frontmatter, allowing for description, globs, and alwaysApply, thus controlling whether rules are always effective, file-matching, Agent-judged, or manually triggered with @.

Cursor also supports AGENTS.md, positioning it as a simple alternative to .cursor/rules. For teams that only need a plain project description, AGENTS.md is more intuitive; if fine control over triggering conditions is needed, .cursor/rules/*.mdc is more suitable. Cursor supports AGENTS.md at the root and subdirectory levels, with subdirectory descriptions being effective when processing corresponding directory files.

Cursor now also has Agent Skills. Project-level skills can be placed in .agents/skills or .cursor/skills, while personal global skills can be found in ~/.agents/skills or ~/.cursor/skills. To ensure compatibility with other tools, Cursor’s official documentation states that it will read from .claude/skills, .codex/skills, and the corresponding user directories.

In terms of MCP, Cursor uses mcp.json. Project-level configurations are stored in .cursor/mcp.json, while global configurations are in ~/.cursor/mcp.json. It supports stdio, SSE, and Streamable HTTP, with tools appearing in the Agent’s Available Tools. By default, it usually requests user confirmation but can also enable Auto-run.

Choosing Among the Three

A Practical Configuration Sequence

If a team is just starting to systematically use these AI programming tools, it is not advisable to write many skills or connect many MCPs right away. A more stable sequence is: first write project descriptions, then break down rules, then consolidate skills, and finally connect MCP.

1. Write the project background that needs to be explained each time into AGENTS.md, CLAUDE.md, or Cursor Rules.
2. Break down the differences by directory, language, or module into path-level rules.
3. Consolidate repetitive operations into skills, such as submission processes, MR descriptions, version releases, and online issue troubleshooting.
4. Only configure MCP when AI truly needs to access external systems.
5. Handle security boundaries separately, such as Codex’s command rules, Cursor’s Auto-run permissions, and Claude Code’s MCP scope.

Example with a Game Project

Suppose a mobile game project needs to help the AI assistant understand team processes. The project background, repository structure, build commands, and submission specifications can be written into AGENTS.md or CLAUDE.md; client code style, activity module specifications, and resource directory rules can be written as path rules; checking commit messages, generating MR descriptions, and looking up requirement documents by task number can be written as skills; and MCP can be connected when accessing Feishu, Jenkins, GitLab, Figma, or internal tools.

The benefit of this approach is clear boundaries. Project descriptions handle long-term memory, rules manage persistent or path-triggered rules, skills handle reusable processes, and MCP connects to external systems. When AI tools change, configurations are easier to migrate. For example, AGENTS.md can be read by both Codex and Cursor; Claude Code can import AGENTS.md through CLAUDE.md; and skills are also moving towards a cross-tool format like Agent Skills.

Final Advice

If there’s only one principle to remember, it is to avoid cramming everything into one large file. Always-necessary content should be placed in project descriptions; rules that only apply to certain types of files should be placed in rules; processes that need to be executed step by step should be placed in skills; and anything that requires reading external systems or calling external actions should be placed in MCP.

The true utility of AI programming tools lies not in their extensive knowledge but in knowing the right information at the right time. The goal of configuration is not to pile up context but to transform team knowledge into a reusable, maintainable, and transferable work system.