claude-code-survival-kr Guards Working Code

claude-code-survival-kr is avenna01-ceo’s open-source GitHub project with copy-paste rules and prompts for Claude Code, Anthropic’s coding agent; Codex, Anysphere’s AI code editor; and Codex, OpenAI’s coding agent. It deals with the familiar failure mode where an agent fixes one bug while breaking code that already worked. The answer is not a better pep talk for the model; it is tighter repo-local constraints plus review of the actual diff. For Codex users, it is also a clean way to implement code review habits for ai-generated code without turning every small change into ceremony.

Read the repo as a boundary file, not a prompt pack

The project’s main idea is wonderfully blunt: put rules next to the code, then make the agent obey those rules before it edits. As of July 26, 2026, the repository describes itself as a copy-paste survival kit for Claude Code, Codex, and Codex, with English and Korean material and minimal explanation.

A repo rule is a durable instruction stored with the repository so an agent sees the same boundary every time it works there.

That matters because chat prompts disappear into the task. Repository files do not. In Claude Code the suggested home is CLAUDE.md; in Codex it is .cursorrules; for Codex-style workflows, the same idea maps naturally to AGENTS.md.

The trick is the project’s bias toward prohibitions. “Write clean code” is too soft. “Do not modify files I did not ask about” has an edge the agent can detect.

The trap is treating the repo as a bag of magic words. The useful part is not the exact prose. It is the move from preference to boundary.

Why Hacker News developers cared

The project landed because it names the breakage people hit after the first week of agentic coding. The demo phase feels fast. Then the codebase grows past the model’s working context, and the agent starts making plausible edits in places it only half understands.

That is the boring, expensive failure: not a spectacular hallucination, just a small regression in a stable path. A changed import. A “helpful” refactor. A migration touched while fixing a button.

The repo’s opinion is that this is a structure problem. You do not solve it by asking the model to be more careful. You solve it by narrowing what it is allowed to touch, requiring tests, and making the agent ask before it crosses a boundary.

There is a fair objection. Negative rules can become a cage. If every file is protected, the agent stops being useful for real refactors.

The answer is scope. A good boundary says “do not touch legacy/payments/ for this task” or “do not change public API shape without approval.” A bad boundary says “never change anything important,” which is just anxiety in markdown.

Compare chat prompts, repo rules, and review checks

The project is useful because it separates three things developers often blend together: task prompts, repository rules, and review habits. They work best together, but they do different jobs.

Verdict: chat prompts win when the task is small and disposable, repo rules win when the same boundary should apply every time, and review checklists win when you need proof that a working path still works. claude-code-survival-kr is strongest in the middle column, but it becomes much more useful when paired with a short review habit.

That is the part Codex Workshop readers should keep. The repo is not a replacement for code review guardrails. It is the earlier guard that keeps the diff small enough for review to be sane.

Try it in a Codex repo without giving it the keys

Start with one narrow rule file. Do not paste in a constitution. Pick the part of the codebase where accidental edits would hurt most.

A small AGENTS.md boundary might look like this:

# AGENTS.md

- Do not modify files outside the task area unless you ask first.
- Do not change public API names, database schema, or auth behavior without explicit approval.
- Before editing, summarize the files you plan to touch.
- After editing, list every changed file and the test command you ran.
- If an MCP tool can write to an external system, ask before using it.

Then keep the verification loop boring:

git status --short
git diff --stat
npm test
git diff --check

If you use MCP, the useful boundary is simple: read-only tools are fine for discovery; write-capable tools need an explicit ask. That keeps a coding agent from turning a code edit into a Jira, GitHub, or database side effect you did not intend.

This is the practical place to implement code review habits for ai-generated code. Ask the agent for a diff receipt, not a diary of its thoughts. A good receipt says what changed, what did not change, what was tested, and where the reviewer should look first.

For a broader map of these patterns, keep this next to the AI coding governance topic. For a shorter companion note on the same repository, see claude-code-survival-kr Keeps Agents From Breaking Code.

Copy this small review checklist

Use this when you want the benefit of claude-code-survival-kr without building a big process around it.

• Before the agent edits, ask it to name the files it plans to touch.
• Add one hard “do not” rule for the risky area of the repo.
• Reject diffs that modify unrelated files without explanation.
• Require a test command, even if the command is “not run, because …”.
• Ask for a changed-files receipt after the edit.
• Review public API, schema, auth, payments, and migration changes manually.
• Keep the rule file short enough that a human will actually maintain it.

This is a fit when the repo already has tests, clear ownership boundaries, or a few directories that must not be casually refactored. It is overkill for throwaway prototypes, spike branches, or solo scripts where the cheapest review is to read the whole file.

Common questions

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

  The best way is to combine repo rules before the edit with a short diff review after the edit. Use one boundary file, one changed-files receipt, and one required test command. The caveat is that review habits only work if the diff stays small enough for a human to inspect.

• Does claude-code-survival-kr only work with Claude Code?

  No. The repository is written for Claude Code first, but its own README points the same content at Codex rules and AGENTS.md-style agent instructions. The portable idea is the rule shape: concrete prohibitions, local scope, and verification, rather than tool-specific prompt decoration.

• Are negative rules really better than positive prompts?

  Negative rules are better for boundaries, not for every instruction. “Do not touch legacy/” is easier to enforce than “be careful with legacy code.” Positive prompts still help for goals, style, and explanation; the project’s useful claim is that safety-critical constraints need a clear edge.

• Where does ai coding training for teams fit into this?

  It fits after developers have felt the breakage in a real repo. A short workshop can use claude-code-survival-kr as a concrete artifact: write one rule, run one agent edit, review one diff. The limitation is that training cannot replace ownership; someone still has to maintain the repo rules.

• When is this too much process?

  It is too much when the code is disposable, the blast radius is tiny, or the agent is only generating a draft you will rewrite. The checklist earns its keep when the agent can touch shared code, production behavior, migrations, auth, payments, or anything with users behind it.

Best ways to use this research

• Best for: developers using Codex, Claude Code, or Codex in a real repository where agent edits can create regressions outside the requested task.
• Best first artifact: a five-line AGENTS.md, CLAUDE.md, or .cursorrules file with one risky directory, one approval boundary, and one test requirement.
• Best comparison angle: treat chat prompts as task intent, repo rules as standing constraints, and review checklists as proof after the diff exists.
• Best next experiment: run the same small bug fix twice, once with only a chat prompt and once with a repo rule, then compare changed files and tests run.

Further reading

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

Start with one guard

Create the smallest rule file that would have prevented your last annoying agent regression. If it works, keep it; if it blocks useful edits, narrow the rule instead of adding more prose.

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.