The Best Claude Code Prompt Is Still a Code Review Process
The best Claude Code prompt is not a prompt. It is a code review process that the agent can read.
Anant Agarwal’s HackerNoon piece lands because it rejects the laziest version of AI coding advice: type “production-ready” into the box and hope the model absorbs your engineering culture by vibes. His opening failure case is painfully familiar. Claude generated Java and Spring Boot code that looked plausible and passed tests, but review found a REST endpoint returning a JPA entity despite DTO conventions, duplicated validation, and exception handling that was almost right in the most dangerous way. The code worked. It was not production code.
That distinction is the whole story. Production readiness is not a model setting. It is the output of local conventions, domain constraints, test quality, security review, dependency discipline, and humans willing to reject a polished diff. Claude Code can read files, edit a repo, run commands, and work through terminal or IDE flows. But if the repository does not tell it how the team works, it will infer the rules from whatever happens to be nearby. That is a polite way to say it will guess.
CLAUDE.md should be a contract, not a junk drawer
The most useful recommendation is also the least glamorous: keep CLAUDE.md short. Anthropic’s memory docs describe CLAUDE.md files as persistent project instructions loaded at the start of sessions, and Agarwal cites Anthropic’s guidance to keep them concise, ideally under 200 lines. That constraint matters. Teams often respond to agent mistakes by appending another rule to the global instruction file. After a month, the file becomes context compost: stale architecture notes, one-off debugging scars, rejected plans, verbose checklists, and rules that apply to only one package.
A good CLAUDE.md should read like onboarding notes for a strong engineer on day one. Inspect related files before editing. Follow package structure. Explain the plan before changing code. Keep controllers thin. Use DTOs for REST APIs. Do not expose JPA entities from controllers. Put business logic in services. Do not add dependencies without explaining why. Update tests for behavior changes. Run mvn test before the final response. That is not magic. It is a review contract in plain text.
The important architectural move is separating always-on context from task context. Keep the standing rules in CLAUDE.md, then move longer material into focused docs or skills: architecture notes, API style guides, database conventions, testing recipes, security review checklists, release procedures. Anthropic’s skills docs make the same point from the tooling side: skills load when relevant, so long procedures do not burn context on every session. That is not just token thrift. It reduces contradiction. The less stale guidance you preload, the fewer ghosts the agent has to negotiate.
Plan mode is where expensive mistakes are cheapest
Plan mode deserves more adoption than it gets because it changes when humans intervene. Anthropic’s permission-mode docs describe plan mode as a read/explore/propose flow before editing. That sounds slower than asking Claude to “just implement it,” and in serious repos it is usually faster. The costliest agent mistakes happen before the first file is modified: wrong package boundary, wrong abstraction, wrong dependency, wrong error contract, wrong test strategy. A plan catches those while they are still cheap text.
Once the agent has generated a 14-file diff, humans become bad reviewers. We start negotiating with the patch. We salvage. We say “mostly fine” because deleting the whole thing feels wasteful. Plan-first work preserves the right to say “no, smaller” before sunk cost distorts judgment. That is the same reason good teams insist on design sketches for cross-cutting changes and not just hero commits from senior engineers.
The Spring Boot examples generalize cleanly. In Rails, the rule might be: follow existing service objects, policies, and JSON error shapes. In TypeScript, use the existing API client, schema validation, and testing pattern; do not invent a parallel fetch wrapper. In infrastructure code, identify stateful resources, show the plan, avoid destructive actions, and require human review before apply. The framework changes. The review contract does not.
The security pass should not depend on memory
Agarwal’s workflow includes a security review, and that is where teams should be stricter than the average blog post. Asking Claude to check for missing authorization, sensitive logs, secrets, stack traces in error responses, insecure direct object references, unsafe deserialization, and unparameterized queries is not polish. It is table stakes when an agent can create endpoints quickly enough to outrun human attention.
Better: turn the security pass into a reusable skill or checklist and make it part of the pull-request habit. The agent should review its diff against behavior, security, and local conventions before handing it back. Humans should still review the work, but the first pass should catch the dumb misses that automation is good at finding. If your team already has Semgrep rules, dependency scanners, or custom linters, tell Claude when to run them and what failures mean. Do not leave security review as a prompt someone remembers after lunch.
There is a subtle governance benefit here. A small CLAUDE.md, focused skills, plan mode, tests, and explicit review passes create an auditable workflow. They make it easier to answer why the agent made a choice, which rule it was following, which tests it ran, and which checks were skipped. That matters more as Claude Code moves from individual productivity tool to team runtime. The question is no longer “can it write code?” It is “can the team tell whether the code fits the system?”
The action plan is simple enough to do this week. Create or trim CLAUDE.md to the rules that should apply every session. Move long procedures into docs/claude/ or skills. Require plan mode for multi-file changes. Ask for tests by behavior, not by file count. Make Claude review its own diff before revising. Add a security pass that names the failure modes your product actually cares about. Compact or restart context after each vertical slice instead of dragging yesterday’s assumptions into today’s task.
The winning teams will not be the ones with the cleverest Claude incantation. They will be the ones whose repositories are legible enough that a capable agent stops guessing. Production-ready code has always come from process. Claude Code just makes the absence of process faster, shinier, and easier to merge by accident.
Sources: HackerNoon, Claude Code memory docs, Claude Code skills docs, Claude Code permission modes, Claude Code common workflows