AI Tips Ladder · Full Guides

The complete walkthroughs from that post

WED · JUL 22 · ED 567
BEGINNER PROMPTING

01 · Your Agent Prompt Only Gets One Shot

Agents run start-to-finish with no chance to ask a clarifying question, so every gap in the prompt becomes a silent guess — and guesses are where runs fail. Packing role, context, task, format, and limits into one structured prompt cuts failed runs and stops you from hand-fixing output after every execution. Use it any time an automation gives inconsistent results or fails on inputs you didn't anticipate.
  1. 01Open the instructions of an agent that recently failed or produced inconsistent output — in most tools this lives in the agent's settings under a field named Instructions, System prompt, or Prompt (if you can't find it, search the tool's settings for 'instructions' or 'prompt').
  2. 02Paste the current prompt into a scratch document and mark every spot where the agent would need to ask you a question mid-run — each mark is context you must supply up front.
  3. 03Rewrite the prompt as five labeled blocks in this order: ROLE (who the agent is), CONTEXT (facts, data sources, and definitions it needs), TASK (the job as numbered concrete actions), FORMAT (the exact output structure with a filled-in example), LIMITS (what it must never do).
  4. 04Inside LIMITS, add an explicit missing-data rule such as 'If required information is missing, write NEEDS_REVIEW in that spot and continue' — the agent cannot stop to ask, so give it a safe fallback.
  5. 05Paste the rewritten prompt back into the agent's instruction field and save.
  6. 06Re-run the agent on the exact input that failed before and compare the new output against the old one line by line.
  7. 07If output still drifts, tighten one block at a time — usually FORMAT or LIMITS — and re-run the same input after each single change so you know which edit worked.
  8. 08Keep that failing input as a permanent test case and re-run it after every future prompt edit before trusting the agent unattended.
ROLE You are a [specific job title] with expertise in [domain]. CONTEXT - Audience: [who consumes the output] - Source data: [where the input comes from and what it looks like] - Key definitions: [terms the agent must interpret your way] TASK 1. [First concrete action] 2. [Second concrete action] 3. [Final action that produces the output] FORMAT Return exactly this structure, with no extra text before or after: [paste a filled-in example of one perfect output here] LIMITS - Never [your top observed failure, e.g. invent numbers, URLs, or names]. - If required information is missing, write NEEDS_REVIEW in that spot and continue — do not stop or guess. - Output nothing outside the FORMAT above.
Watch out: Describing the format with adjectives like 'clean' or 'professional' — paste a literal example output instead; agents imitate examples far more reliably than they obey adjectives. · Omitting the missing-data rule in LIMITS — without it the agent fills gaps with plausible invented values instead of flagging them. · Editing several blocks at once after a bad run — you won't know which change fixed it; change one block, re-run the same input, repeat.
INTERMEDIATE WORKFLOW

02 · Explore, Plan, Then Let It Code

You get an implementation built against an approach you reviewed, not the model's first guess — the payoff is largest in large or unfamiliar codebases, where a plausible-looking fix often targets the wrong file or layer. Plan mode makes the exploration phase safe because file edits and state-changing commands are blocked until you approve the plan. Use it for anything multi-file (features, refactors, gnarly bugs); skip it for one-line changes.
  1. 01Open a terminal in your project root and start Claude Code by running: claude (or continue an existing session).
  2. 02Press Shift+Tab until the indicator under the input box says plan mode is on (the cycle is: default, accept-edits, plan mode). To start a session already in plan mode, run: claude --permission-mode plan.
  3. 03Paste the snippet below with your change described. In plan mode Claude can read files, search, and run read-only commands but cannot edit anything, so let it explore as long as it needs.
  4. 04Read the plan it proposes critically: check that the file paths are real ones it actually read, the order of changes makes sense, and there is a concrete verification step with exact commands.
  5. 05If anything is off, reply with corrections and ask for a revised plan — you stay in plan mode while iterating, so nothing gets touched.
  6. 06When the plan is right, approve it at the exit-plan prompt Claude shows (it always asks before leaving plan mode). Choose the auto-accept option if you want it to implement without per-edit confirmations.
  7. 07Let it implement while you review the diffs. If it drifts from the approved plan, press Escape to interrupt, name the plan step it is violating, and redirect it.
  8. 08Ask it to verify against its own plan: run the test or build commands from the plan's verification step and show the output. Only accept 'done' backed by passing results.
We need to <describe the change here>. Do NOT write any code yet. 1. Explore: read the relevant parts of this codebase and identify the files, modules, and tests involved and how they interact. Cite real file paths you actually opened. 2. Plan: propose a step-by-step implementation plan — files to change, order of changes, risks or unknowns, and how we will verify each step (exact test/build commands). Ask me clarifying questions first if anything is ambiguous. I will review and approve the plan before you implement.
Watch out: Shift+Tab cycles through several modes — confirm the UI actually shows plan mode before sending your prompt, or Claude may start editing immediately. · A plan can still be a guess: if it lists generic or nonexistent file paths, it did not explore enough — send it back with 'read the actual files first'. · On long tasks the approved plan can fall out of the context window; ask Claude to save the plan to a markdown file and reference that file during implementation.
↳ tool: Claude Code · official docs · original source
ADVANCED AGENTS

03 · Give The Agent A Test It Can Run

An agent stops when work *looks* done — unless it has a pass/fail check to run. Give it tests, a build, or a screenshot to match and it iterates until green while you walk away.
Implement X. After each change run `npm test` and iterate until ALL tests pass. Show the final output.
↳ tool: Claude Code · original source
PRO AUTOMATION

04 · One Loop, Two Thousand Migrations

Headless mode turns the agent into a batch tool: loop a one-line prompt over a file list and it migrates, fixes, or audits each one — scoped by --allowedTools so it can't go rogue.
for f in $(cat files.txt); do claude -p "Migrate $f. Reply OK or FAIL." \ --allowedTools "Edit,Bash(git commit *)" done
↳ tool: Claude Code · original source
🛠️ We build the AI systems & automations behind tips like these.
Follow @conon.ai for the daily brief — news + tips, every day.
@conon.ai · automated daily AI brief