Skip to content

Towards self-improvement

A large part of becoming productive with agents is learning how to blend them with code. Your agents need to adapt to the codebase, and your codebase needs to adapt to the agents. For example, you might not like the commit message an agent has just produced.

One way to steer agents toward the right behavior is to keep an AGENTS.md file in the repository root. This file is read by the agent in each thread and defines basic guidance for how it should operate.

You might see different variants of this file across tools — GEMINI.md, COPILOT.md, AGENT.md, CLAUDE.md, and others. In practice, one file is enough: AGENTS.md. It’s supported by nearly all coding agents except Claude Code, which still expects a separate CLAUDE.md.

The simplest way to keep both files in sync is to create a symlink (symbolic link) from AGENTS.md to CLAUDE.md using the command below.

Keep this file minimal. Its role is to make sure the agent “does the right thing” every time, not to over-specify every step.

# [Project name]
## Rules
- you may be running in parallel with other agents; cooperate to avoid
conflicts, but avoid committing changes made by others
- add test coverage for new logic and regression fixes where practical
- run `npm lint` to format code and run linters; run `npm test` to run tests
- ignore any backward compatibility - break stuff everywhere if needed

Source: Marek Kaput ’s template.

Create a symbolic link for Claude:

ln -s AGENTS.md CLAUDE.md

This command creates a file CLAUDE.md that points to AGENTS.md. Claude will then read the same rules as all other agents without needing a separate copy.

If possible, commit both files to your repository.

AGENTS.md is the simplest place to start because it gives you immediate leverage without adding much complexity.

As you get comfortable with that baseline, you can introduce more advanced utilities around the agent: skills for reusable workflows, more structured guidance such as Cursor Rules for larger codebases, and MCP integrations for connecting the model to external tools and services.

You do not need all of that on day one. For now, it is enough to know these mechanisms exist and become more useful once you already have a stable basic workflow.

When you are ready, continue with Harness engineering, which covers these more advanced building blocks in detail.

Attribution

Authors

Contributors