What is the difference between AGENTS.md and a fenbs decision?

AGENTS.md holds the current rule Claude Code follows in this repository. A fenbs decision records why that rule exists, who chose it and when. You need both: the rule tells Claude Code what to do; the decision tells the next session whether the rule still makes sense.

Does Claude Code remember what I corrected in a previous session?

Only through what is written in files it reads. A correction you made verbally during a session disappears when the session ends. To make it permanent, write the resulting rule in AGENTS.md and record the reasoning in a decision or lesson outside the repository.

How many rules can I put in AGENTS.md?

There is no hard limit, but longer files are harder to follow consistently. Keep rules specific and current. A short, accurate AGENTS.md produces better results than a long one full of outdated or contradicting entries.

Can Claude Code use rules from a file other than AGENTS.md?

Claude Code reads AGENTS.md and CLAUDE.md natively. You can point to other files inside those—for example, a style guide or a testing conventions document—and Claude Code will read them when they are referenced.

Should I write rules for every project or reuse them?

Some rules apply everywhere (test before committing, name functions with verb-noun pairs). Keep those in a shared document and reference it from each project's AGENTS.md. Project-specific rules belong in that project's file only, so they do not accidentally constrain other work.

How to Train Claude Code With Rules and Feedback

Repository instructions, coding conventions and verified feedback all shape how Claude Code behaves across sessions. Here is how to build a set of rules that sticks—and where to record the decisions and lessons behind them.

June 13, 2026Updated October 21, 20265 min read

Claude Code learns from what you put in its configuration files and from the feedback you give it during a session. You cannot change the model, but you can shape its behavior reliably by writing clear rules in AGENTS.md or CLAUDE.md, showing it good examples, and recording the decisions that explain why those rules exist. Tools like fenbs keep that record of decisions and lessons outside any one repository, so future sessions start with the knowledge already in place.

This matters most on long-running projects. The first session you spend correcting Claude Code's style choices is not wasted time—it is the raw material for a rule set that prevents the same corrections from happening again.

How Claude Code reads its instructions

Claude Code reads AGENTS.md (and CLAUDE.md, which it treats as a pointer) natively. These files load at the start of every session in that repository. Write your project conventions there: naming patterns, file structure rules, testing requirements, anything the assistant should follow consistently.

Instructions in these files apply to every session without you having to paste them again. If a rule applies only to a subdirectory, put a separate AGENTS.md inside that folder. Claude Code loads the nearest file first. For broader guidance on installing and using Claude Code, see how to install Claude Code and Claude Code docs.

Write rules that are specific and testable

A rule is useful only if Claude Code can follow it without guessing. "Write clean code" is not actionable. "Each function must do one thing; name it with a verb and a noun; keep it under 40 lines" is.

State the pattern, not the principle: "use the repository's existing error type rather than creating a new one."
Say when a rule applies: "for any new API endpoint, add a corresponding test before opening a pull request."
Include the reason: a rule with a reason is easier to apply correctly in edge cases and easier to update when requirements change.

Keep the AGENTS.md focused. A long file with contradicting or out-of-date rules is harder to follow than a short, current one. Review it at the end of each project phase and remove rules that no longer apply.

Use examples alongside rules

Where a rule describes a pattern, point to a real file that demonstrates it: "see src/handlers/user.ts for the pattern to follow." Claude Code can read that file and apply the same structure without needing every detail spelled out in prose.

You can also paste a short before-and-after example in a session: "Here is the old version; here is what I want instead." Claude Code treats that as a concrete target. Once you have confirmed it works, extract the rule and add it to AGENTS.md.

Give verified feedback, not just corrections

Corrections during a session shape that session. To make them permanent, you need to verify the result and write the rule down. The loop is: Claude Code proposes something, you test it, it passes (or fails), you record the decision.

Unverified feedback ("I think the tests will pass now") is not a lesson—it is a guess. When you have run the tests and seen the result, that outcome is worth recording. Claude Code sandboxing and checkpoint features help you test proposals safely before committing; see Claude Code sandbox and Claude Code checkpoints.

How fenbs helps

Record what you learn so the next session starts smarter

In fenbs, Lessons learned hold what happened, what you learned and what to do differently. A connected Claude Code session reads them at the start of the project context alongside your Decisions and rules. Add one lesson per verified discovery: the issue you hit, the fix that worked, and the condition under which it applies.

Create a free account

Free for one person · No credit card · Works with Claude, ChatGPT, Cursor and more

Handle sessions that ignore a rule

If Claude Code ignores a rule from AGENTS.md, check two things first: whether the rule is specific enough to apply unambiguously, and whether the file was loaded. Claude Code reads AGENTS.md in the working directory at session start; if the session was opened from a different directory, the right file may not have loaded.

If the file loaded correctly and the rule is specific, the rule may conflict with a pattern Claude Code defaults to strongly. In that case, make the rule more explicit: instead of "avoid unnecessary abstractions," say "do not create a helper function for code called only once." The more concrete the rule, the harder it is to ignore.

Record decisions where rules come from

Rules in AGENTS.md say what to do. Decisions explain why, who chose it and when. Keeping both matters because rules go stale: a new dependency, a team preference change, a performance finding can all make an old rule wrong. A decision with a reason tells the next session what the rule was trying to achieve, so it can flag a conflict rather than blindly following an outdated instruction.

For the broader question of how instructions shape Claude AI output in any context, see how to train Claude AI.

How to do this with fenbs

Create a free account and add a project for the repository you are working on.
Write the standing decisions—why the architecture is structured this way, which library was chosen and why, what the testing requirement covers—in Decisions and rules.
Record each verified lesson from a session in Lessons learned. Include the symptom, what caused it, and the fix. Link it to the relevant task.
Connect Claude Code to fenbs from Integrations and ask it to read the project context at the start of each session. Your decisions and lessons load alongside the code.
Review AGENTS.md and fenbs Decisions and rules together at the end of each project phase. Remove rules that no longer apply; update decisions that have changed.