Set up your tools

Most of the difference between an engineer who gets a day’s work out of an agent and one who gets a demo out of it is setup. The agent that knows your build command, your conventions and your tools does not need to be told them every session. The table above is where each tool looks for that.

Pick one agent

Claude Code, Codex and Cursor all read an instruction file, all speak MCP, and all load skills in the same format. The workflow transfers. Pick the one your team already pays for, and switch only if you hit a wall.

Write the instruction file

This is the highest-value hour in this guide. The file is plain Markdown at the repo root. Put in it:

• How to build, test and lint, as exact commands. The agent will run them.
• Where things live: the two or three directories that matter and what is in them.
• Conventions the linter cannot enforce: naming, error handling, how you structure a module.
• What not to touch: generated files, vendored code, the migration folder.
• Gotchas: the flaky test, the env var that has to be set, the thing that looks dead but is not.

Keep it under a page. Long files get skimmed, by agents as much as by people. Anything task-specific belongs in a skill, not here.

Write AGENTS.md, since Codex and Cursor read it directly. For Claude Code, add a CLAUDE.md containing only:

@AGENTS.md

Claude Code does not read AGENTS.md on its own, and this import makes one file serve every tool. Cursor also accepts rules files under .cursor/rules with frontmatter, which lets you scope a rule to a file glob. Start with the plain file.

Connect the tools you already have

An MCP server gives the agent a capability it cannot get from the shell. Connect only what your stack has:

• Your source host, for issues and pull requests.
• Your database, read-only.
• Your issue tracker.
• Your docs or design system, if they live somewhere searchable.

Use the project-scoped config from the table and commit it. Everyone on the team then gets the same tools, and the file is reviewable like any other change. Keep user-scoped config for personal things.

Two cautions. Every server adds tool descriptions to the context on every turn, so ten servers make the agent slower and vaguer. And a server’s tool descriptions are input to the model, so treat a third-party server like a dependency. See prompt injection.

Put it in your editor

Cursor is an editor. Claude Code and Codex are terminal programs with VS Code and JetBrains extensions, and both run inside Zed and other editors through ACP adapters that Zed maintains. Running the agent inside the editor means it sees unsaved buffers, and its file edits show up as diffs you can accept or reject. Use that. Reviewing a diff is faster than reviewing a terminal transcript.

Do this today

1. Write AGENTS.md with build, test and lint commands and the three directories that matter.
2. Add CLAUDE.md with the one-line import if anyone on the team uses Claude Code.
3. Connect your source host’s MCP server at project scope and commit the file.
4. Open the agent in your editor and have it run the test suite. If it cannot, fix the instruction file until it can.