For anyone building with coding agents: understand the risk, apply a concrete rule, then use a prompt to inspect your own project.
Risk: A function called handleData hides whether it reads, writes or deletes.
Rule: Name its actual effect, such as saveUserProfile, then check callers before renaming.
See the full example →Review names in this code for vague terms, hidden side effects and inconsistent file or component names. Do not rename yet. Propose a small plan and its risks.Risk: Frontend bundles are downloaded by visitors; a key compiled into one can be read and reused.
Rule: Keep provider credentials on a server endpoint and let the browser call that endpoint.
See the full example →Inspect the frontend diff and configuration for keys, tokens, connection strings and private endpoints. Report exact exposures; propose a server-side design. Do not print secret values.Risk: Renaming a real .env to .env.example can publish the same credentials under a friendlier filename.
Rule: Commit placeholders only. If a key reached Git, revoke it; .gitignore does not erase history.
See the full example →List tracked configuration files and likely secret-bearing files. Suggest only relevant .gitignore entries and a placeholder-only .env.example. Do not reveal values.Risk: A new ignore rule does not untrack a file already committed.
Rule: Inspect git ls-files and git check-ignore -v before assuming a local secret is protected.
See the full example →Review this repository's .gitignore for build output, dependencies, cache, local databases and environment files. Identify tracked files the ignore rule cannot protect.Risk: Mixing a formula fix with a dependency update and redesign makes regressions hard to isolate.
Rule: Keep code and tests for one fix together, and split independent changes.
See the full example →Review local changes and propose coherent commit groups by purpose. Do not stage or commit. Explain any file that does not fit the requested task.Risk: A package adds maintenance, compatibility and supply-chain costs; the project may already have what you need.
Rule: Compare framework features, existing utilities, a small local function and a new package.
See the full example →Before adding a package, check the runtime requirement, existing project utilities, framework built-ins and the package's maintenance. Explain the smallest maintainable choice.