Updated May 1, 2026
How to prompt AI coding agents
Prompt patterns that make Claude Code, Aider, Cline, Codex CLI, and similar agents more useful and safer.
Good coding-agent prompts are small project briefs. They describe the job, the boundaries, the proof step, and the review standard. The agent should know what to inspect, what not to touch, which commands matter, and what evidence to leave behind.
Bad prompts are vague: "fix auth," "clean this up," or "make it production ready." Better prompts define proof:
Reproduce the failing login test, patch the smallest server-side authorization issue, add a regression test, and run the auth test file. Do not change the database schema.
That gives the agent a target and gives the reviewer a way to judge the patch.
Put Durable Rules In Files
Prompts are for the current task. Repository rules belong in repo instructions.
| Tool family | Instruction file | Use it for |
|---|---|---|
| OpenAI Codex | AGENTS.md | Build commands, review rules, project layout, done criteria |
| Claude Code | CLAUDE.md | Persistent project instructions, local workflow, code standards |
| Mixed-agent repos | AGENTS.md plus a CLAUDE.md import | Shared rules with Claude-specific notes |
For Codex, include build, test, and lint commands; important directories; PR expectations; files to avoid; and review guidelines. For Claude Code, keep CLAUDE.md concise and specific. If your repo already has AGENTS.md, Claude can import it from CLAUDE.md with @AGENTS.md.
Use This Prompt Shape
Goal:
Fix the bug where invited users cannot accept workspace invitations.
Context:
Start in apps/web/src/invitations and packages/auth. Do not edit billing code.
Constraints:
- Keep the public API response shape unchanged.
- Do not add a new dependency.
- Keep the diff small.
Acceptance criteria:
- Add or update a regression test for expired and valid invitations.
- Run pnpm test -- invitations.
- Summarize changed files and any checks you could not run.
The format works across Codex, Claude Code, Aider, Cline, and most repo agents because it gives the model a real engineering packet instead of a wish.
Ask For Planning When The Patch Could Sprawl
Use planning for migrations, auth, billing, permissions, data deletion, infrastructure, and refactors that touch multiple packages.
Analyze the current permissions model. Do not edit files yet. Produce a plan with milestones, files likely to change, tests to update, and rollback notes.
Then choose one milestone:
Implement milestone 1 only. Keep the existing API stable. Run the tests listed in the plan and stop if the change starts touching unrelated packages.
Make Review Part Of The Prompt
Agents are better when review is not an afterthought.
After the patch, review your own diff for:
- accidental public API changes
- tenant-boundary mistakes
- missing error states
- tests that only prove the implementation rather than the behavior
For Codex, /review can inspect local changes before commit, and @codex review can review GitHub pull requests. For Claude Code, use a separate review prompt or a code-review subagent when the repo has that pattern.
Keep The Working Tree Clean
Before agent work:
- Commit or stash unrelated changes.
- Run the test command you expect the agent to use.
- Tell the agent about known flaky tests.
- Keep generated secrets and private config out of readable paths.
- Review every diff before committing.
Agents are useful because they can act. That is also why they need boundaries.