claude-code-survival-kr Rules Stop Agent Breakage

claude-code-survival-kr is an open-source rule-and-prompt repo by GitHub user avenna01-ceo for Claude Code, Anthropic's coding agent, Cursor, Anysphere's AI code editor, and Codex, OpenAI's coding agent. It deals with the familiar agentic coding failure mode where the assistant fixes one thing and quietly breaks another. The useful takeaway is small: put hard boundaries in a repo-level rules file, then review the diff against those boundaries before merging. That is also the cleanest way to implement code review habits for ai-generated code without turning every change into a ceremony.

The project was last pushed on July 26, 2026, and its pitch is refreshingly blunt. The first two weeks with an AI coding agent feel magical, then the repo grows beyond what the model can safely hold in its working context. claude-code-survival-kr argues that this is not mainly a skill problem. It is a structure problem.

Read the repo as a breakage manual

The repo is not a framework. It is a copy-paste survival kit: short rules, short prompts, and minimal explanation for people whose coding agent has started making drive-by edits.

A breakage rule is a durable instruction that forbids a risky class of changes, such as modifying unrelated files, merging without tests, or touching legacy code. The important bit is the edge. A model can wiggle around a fuzzy request like keep the code clean, but do not modify files I did not ask about is easier to check.

That is why developers noticed it. The repo names the thing many people hit after the demo phase: the assistant is still helpful, but its blast radius grows. In Cursor, this shows up when Agent mode follows a plausible path through too many files. In Claude Code, it shows up when a session keeps enough context to be confident, but not enough to be correct.

The trap is treating this as a better-prompt problem. Prompting harder can help for one task. Repo rules help every task after that.

Put the boundary where the agent starts

claude-code-survival-kr starts with a root CLAUDE.md because Claude Code reads it automatically at the start of a conversation. The same content can move into .cursorrules for Cursor or AGENTS.md for Codex-style workflows. Cursor users can also turn the idea into a small .mdc rule in .cursor/rules when they want narrower scope.

Here is the shape I would use in a real Cursor repo:

---
description: Prevent drive-by edits in feature and bug-fix work
alwaysApply: true
---

Do not modify files outside the requested feature, bug, or test boundary.

Before editing, list the files you plan to touch.

If a change requires touching shared auth, billing, migrations, or legacy code,
stop and ask for confirmation.

After editing, summarize every file changed and why it was necessary.

This is not magic. It is a speed bump in the right place. The agent still has to reason, but now it has to reason inside a smaller box.

The trap is stuffing the file with taste. Prefer concrete prohibitions over vibes. Do not touch legacy/ beats preserve architecture. Do not change public API signatures without approval beats be careful with interfaces.

Compare rules, prompts, and review checklists

The project is interesting because it does not pretend one artifact solves the whole problem. A rule file changes what the agent attempts. A prompt changes what it does in this session. A review checklist changes what you allow into the branch.

Verdict: repo rule files win when the same mistake keeps recurring, one-off prompts win when the risk is unique to the task, and review checklists win when you need a final human gate. The useful pattern is not choosing one forever. It is using the smallest artifact that catches the failure where it happens.

This is where the related training topic connects without swallowing the story. The repo is not an ai coding training for teams curriculum. But it is exactly the kind of small, repeatable artifact that makes engineering team ai adoption less chaotic.

Try it when the repo has a real blast radius

Try claude-code-survival-kr when your agent is productive but a little too adventurous. Good signs: it edits neighboring files without being asked, rewrites working code while fixing tests, or changes a shared utility because it is easier than understanding the caller.

It is overkill for tiny prototypes, throwaway scripts, or branches where the whole point is exploration. In those cases, a short prompt may be enough. Constraints pay off when the code already has users, tests, migrations, permissions, or legacy seams.

The practical move is to start with one rule, not a constitution. Pick the rule that would have prevented the last bad diff. Then make review check that exact thing.

That is also the answer to what are the best ways to implement code review habits for ai-generated code? Start by reviewing the agent's changed files against the task boundary, then check tests, public APIs, and risky directories. Make the checklist boring enough that you will actually use it.

Copy this safe-try review checklist

Use this after an agent-generated diff, before you merge or even before you ask the agent for another pass. It is intentionally small.

• Task boundary: Do the changed files match the request? If not, ask why each extra file changed.
• Risky paths: Did the diff touch auth, billing, migrations, permissions, generated files, or legacy/? If yes, stop for manual review.
• Public surface: Did any exported function, API route, database schema, CLI flag, or config name change? If yes, require an explicit note.
• Tests: Is there a test for the behavior that changed? If not, ask the agent to add or identify the missing test before refactoring more.
• Regression check: Can you run the narrow test command first, then the broader suite if the narrow one passes?
• Diff explanation: Can the agent summarize every changed file in one sentence each? If it cannot, the diff is probably too wide.
• Follow-up prompt: Ask for a review of the final diff, not a replay of the chat.

A lightweight command workflow looks like this:

git status --short
git diff --stat
git diff -- src/app/auth src/lib/permissions
npm test -- --runInBand auth

The trap is letting the agent fix the review findings immediately without narrowing the next task. If the review finds a boundary breach, revert or isolate that part first. Otherwise the second agent pass can compound the first mistake.

For a neighboring example of why routing and review need to be measured rather than assumed, see Echo Tests Cheaper Open-Weight Routing.

Common questions

• What are the best ways to implement code review habits for ai-generated code?

  The best way is to review AI-generated diffs against explicit repo rules, not against general taste. Use three checks every time: changed files match the request, risky paths were approved, and tests cover the changed behavior. This keeps the habit small enough to survive normal developer pressure.

• Should I use CLAUDE.md, .cursorrules, or AGENTS.md?

  Use the file your agent actually reads at startup. claude-code-survival-kr points Claude Code users to CLAUDE.md, Cursor users to .cursorrules, and Codex-style workflows to AGENTS.md. If you are working in Cursor, a scoped .cursor/rules/*.mdc file can be cleaner for one package or boundary.

• Are prohibitions really better than positive instructions?

  Prohibitions are better when the risk has a clear edge. Do not touch legacy/ is easier to obey and review than keep legacy code stable. Positive instructions still help for style and intent, but safety rules work best when a reviewer can say pass or fail from the diff.

• When does this become too much process?

  It becomes too much process when the checklist is larger than the change. For a one-file prototype, a short prompt and a quick diff read are enough. For production code with tests, migrations, or shared modules, a few durable rules are cheaper than debugging agent-created regressions later.

Best ways to use this research

• Best for: Developers using Cursor Agent or Claude Code on repos where working code already matters and accidental neighboring edits have become common.
• Best first artifact: Add one rule that forbids the last harmful behavior you saw, then pair it with the review checklist above.
• Best comparison angle: Treat rules, prompts, and review as different control points: before the session, during the task, and before merge.
• Best limitation to remember: Rules reduce blast radius, but they do not prove correctness. Tests and human review still carry the final responsibility.

Further reading

• claude-code-survival-kr — source
• Cursor — Agent
• Claude Code — getting started
• Model Context Protocol — specification

Next step

Pick one boundary your agent crossed last week and write it as a concrete do-not rule. Then run the next AI-generated diff through the checklist before you let the agent continue.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.