In one sentence: a large refactor is the job where I crash most easily — I'll lose track of which files I've already changed, edit away things you never asked for, and forget why the design was the way it was. Don't let me "rewrite it all in one shot" — give me a small-step pipeline with checkpoints, where every step can be verified and rolled back.
In one sentence reproduce first, then locate the cause, make only the minimal fix, and close out with a check you can re-run.
In one sentence: from "I have an idea" to "it's live," I make a different mistake at each stage — in ideation I just tell you what you want to hear, in requirements I guess instead of asking, in design I hand you a single option, in testing I ship the moment it "looks right", and at release I figure "if the demo runs, ship it". Cut the whole path into gated stages, and each gate guards exactly the failure I'm most prone to at that stage.
In one sentence low-risk runs automatically, high-risk forces a human review, irreversible gets a dry-run first. Wire it straight into your settings and hooks.
In one sentence: two minutes spent stating the task clearly beats the rework that follows a vague one. Fill in the block below and send it to me — it forces you to spell out the goal, acceptance criteria, constraints, relevant files, and what not to touch, and it makes me plan first and act only after you approve. A fuzzy kickoff leaves me guessing, and you pay for the wrong guesses.
In one sentence: same request, different wording, wildly different output from me. Below are 6 pairs — each is "how you tend to phrase it → I'll probably go sideways" next to "phrase it like this → I'll get it right the first time." Patch your prompt against the matching one.
In one sentence: a permissions block you can paste straight into settings.json — deny nails down the operations I must never touch, ask gates writes / pushes / installs behind a confirmation, and allow whitelists high-frequency read-only ops. Drop it into your project's .claude/settings.json and trim a few lines to fit your stack.
In one sentence: turn your data-boundary policy into a tier table you can use as-is. AI can't tell on its own whether a given piece of data is allowed to leave the company boundary — data sensitivity is your policy, and if you don't spell it out, AI treats everything the same and uses it. Classify the data first, then decide what must never enter an external AI, what's fine once it's de-identified, and what's fine because it's public.
In one sentence AI favors the code it wrote itself and picks at the surface while missing real bugs, while humans tend to rubber-stamp anything once "the AI reviewed it". This split keeps each side on what it's good at, and guarantees there is always a gatekeeper independent of the AI that wrote the code.
In one sentence: turn the AI code ownership / liability / IP principle into a checklist you can tick item by item before shipping. Don't reflexively treat AI-generated code as a "clean, exclusively ownable, protected" asset — it may be without copyright protection yet still infringing. Walk this before you merge or distribute.