claude-code-survival-kr Keeps Agents From Breaking Code

claude-code-survival-kr is an open-source copy-paste rule set by GitHub user avenna01-ceo for Claude Code, Anthropic's coding agent; Claude, Anysphere's AI code editor; and Codex, OpenAI's coding agent. It deals with the awkward moment when an AI coding agent fixes one thing and quietly breaks another. The takeaway is simple: put sharp boundaries near the agent before you ask for bigger changes. It also answers a practical review question for ai coding training for teams: how to implement code review habits for ai-generated code without turning every patch into a ceremony.

See what the Show HN repo actually ships

The repository is small on purpose. As of July 26, 2026, it was last pushed the same day and described itself as rules and prompts that stop Claude Code, Claude, and Codex from wrecking code that already worked.

The README's core move is to create a project rule file and paste in constraints. For Claude Code, that means a root CLAUDE.md; for Claude, .cursorrules; for Codex-style agents, AGENTS.md.

A repository rule file is durable context that the coding agent reads before or during work, so the human does not need to retype the same project boundaries in every chat. The repo's point is not that one magic prompt makes agents safe. It is that local, explicit limits are easier for a model to obey than vibes like be careful.

A concrete example from the project is the difference between positive wishes and negative boundaries. Write clean code has no testable edge. Do not modify files I did not ask about does.

Notice why negative rules landed

Developers cared because the failure mode is familiar. The first week with an agent feels fast, then the codebase gets larger than the model's useful working set, and the agent starts making global edits from partial context.

The repo's opinion is that this is not mainly a talent problem. It is a structure problem. Prompting harder does not create a boundary if the agent still has permission, context, and confidence to edit the wrong place.

That is why the phrasing matters. Do not touch legacy/ is operational. Please keep it organized is a mood.

Here is the comparison that makes the Show HN project interesting:

Verdict: hard prohibitions win when the problem is accidental code churn, soft prompts win when you are still exploring, and permission boundaries win when the agent can touch systems outside the working tree. The best setup is usually boring: a few durable repo rules, a narrow task prompt, and no write access to dangerous systems until the diff is reviewed.

Add one boundary where the agent can do damage

The repo starts with text rules, but Claude Code users should think one step past text. If a rule says do not touch generated files, the safer version is a hook or review check that catches generated-file changes before commit.

A hook boundary is a small automated stop placed at a risky lifecycle point, such as before commit, after file write, or before a command that changes external state. It matters because agents are good at sounding certain after they have already crossed the line.

Keep the first boundary tiny. For example: block commits if the diff touches legacy/, migrations/, or generated files unless the PR description names that path. The trap is building a grand safety system before you know which mistake actually repeats.

For MCP, the same idea applies. If Claude Code can reach GitHub, Slack, a database, or a private document store through Model Context Protocol, start with read-only access for discovery. Let write tools require a human checkpoint, especially on issues, pull requests, production data, and secrets.

Try it when fixes start spreading sideways

Use claude-code-survival-kr when the agent's diffs are technically plausible but wider than the task. That usually looks like a bug fix that edits unrelated modules, a refactor that cleans up half the repo, or a test update that changes behavior instead of proving behavior.

This is the right moment to implement code review habits for ai-generated code as a lightweight guardrail, not a heavyweight process. Ask for a plan before edits, review the file list before accepting, and make the agent explain why each touched file belongs in scope.

It is overkill for throwaway scripts, prototypes, and isolated sandboxes. It is also not enough for regulated systems, production migrations, or agents with broad write access. In those cases, pair repo rules with permissions, tests, and human approval gates.

If you want the broader pattern, our related page on claude-code-survival-kr Rules Stop Agent Breakage connects this repo to agentic coding review habits across tools. The wider AI coding governance topic is useful when you need to compare guardrails, MCP permissions, and review conventions without losing the plot.

Copy this try-it-safely review receipt

Paste this into the PR body, a Claude Code handoff, or a local review note after an agent-generated change. It is deliberately small. If it takes longer than reading the diff, people will skip it.

Agent change receipt

• Task requested: What did I ask the agent to change?
• Files touched: Are all touched files inside the requested scope?
• Protected paths: Did the diff touch legacy/, generated files, migrations, auth, billing, or deployment code?
• Tests run: Which exact tests or checks passed?
• Behavior proof: What output, screenshot, failing-before test, or reproduction shows the fix works?
• Unrelated cleanup: Did the agent rename, reformat, or refactor anything not needed for the task?
• MCP or external access: Did the agent read or write GitHub, Slack, databases, docs, tickets, or other systems?
• Human decision: Accept, request a narrower diff, or revert and retry with tighter rules?

A small slash-command workflow can make this feel natural in Claude Code: ask for a plan, allow a narrow edit, then ask for a receipt before review. The important bit is not the command name. It is that the agent must account for scope before you merge its work.

Try one hard boundary tonight

Pick the agent mistake you have seen twice, write one do not rule for it, and use the review receipt on the next diff. If it catches even one unrelated file change, keep it and make the boundary enforceable later.

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.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about ai coding training for teams?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of ai coding training for teams. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “claude-code-survival-kr Keeps Agents From Breaking Code.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• claude-code-survival-kr — source
• Claude — Agent
• Claude Code — getting started
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.