Skip to content

Knowledge base

Prompt Engineering

For anyone writing prompts for Claude Code: format levels, a section-by-section structure for agentic prompts, and Anthropic's recommended techniques.

Written by

Updated:

Tools 4

Our position. We treat prompt engineering as the smaller lever: prompt engineering is how you ask, context engineering is what the model sees (opens in a new tab). So stop optimizing prompts in isolation and engineer the context.

Most engineers need a workflow prompt with some control flow or delegation, level 3 or 4 on a seven-level ladder (Agentic Prompt Engineering with Claude Code (opens in a new tab)). Consistency does the rest: the same few sections, named the same way every time, keep a prompt readable for people and executable for agents.

Who does a prompt have to serve?

Every prompt you write serves three audiences:

  1. You – needs to be readable and maintainable
  2. Your team – needs to be shareable and consistent
  3. Your agents – needs to be executable and unambiguous

“We’re now engineering for three audiences. You, your team, and your agents. This is the agentic shift that most engineers haven’t yet made.” – Agentic Prompt Engineering with Claude Code (opens in a new tab)

Which prompt format level do you need?

Which prompt format level do you need?
Level Format Capability added
1 Ad-hoc Simple one-off prompt
2 Workflow Sequential steps (most important)
3 Control flow Conditionals, loops, early returns
4 Delegation Kicks off sub-agents/background agents
5 System prompt Identity and behavior definition
6 Template meta-prompt Prompt that builds prompts
7 ADW (AI Developer Workflow) Full pipeline orchestration

“90% of the time for most engineers, all we need is one of the seven levels. Usually level 3 or 4.” – Agentic Prompt Engineering with Claude Code (opens in a new tab)

How should an agentic prompt be structured?

Every well-structured agentic prompt follows this three-part pattern:

# Title

## Purpose

One-two sentence direct description of what this prompt does.

## Variables (Input)

- $1: user-prompt (dynamic, from argument)
- plan_output_dir: specs/ (static, hardcoded)

## Workflow (Processing)

1. Step one with specific actions
2. Step two with tool calls
   - Sub-detail if needed
3. Step three with validation

## Report (Output)

Format for the response: JSON/YAML/markdown/structured.

“Input, workflow, output. This is a very consistent three-step pattern for designing your prompts.” – Agentic Prompt Engineering with Claude Code (opens in a new tab)

Which prompt sections are worth adding?

Each section is a swappable “Lego block” (Agentic Prompt Engineering with Claude Code (opens in a new tab)):

Which prompt sections are worth adding?
Section Usefulness Difficulty Purpose
Workflow S-tier C-tier Step-by-step play for the agent
Variables A-tier B-tier Dynamic and static parameters
Report B-tier C-tier Output format specification
Instructions B-tier C-tier Auxiliary info for workflow steps
Metadata C-tier C-tier Model, tools, description
Codebase structure C-tier C-tier Quick map of relevant files

Rule: Only add sections you need. If you don’t need output formatting, skip the report section.

Which prompting techniques does Anthropic recommend?

From official Anthropic guidance, compiled in Anthropic releases method to 10x Claude Code (opens in a new tab):

Which prompting techniques does Anthropic recommend?
# Technique How to apply
1 Tone of collaboration Friendly, clear, firm. Not aggressive. Not passive.
2 Principle of explicitness Use action verbs, specify quantity, define target audience
3 Define boundaries Constrain length, style, character, forbidden words
4 Draft, plan, then act Step 1: propose outline. Step 2: refine. Step 3: execute.
5 Demand structured output “Present as a markdown table with columns: X, Y, Z”
6 Explain the why Provide context for intent, audience, and purpose
7 Control verbosity “Be concise and use bullet points” OR “Explain in detail step by step”
8 Provide a scaffold Give a template with placeholders for AI to fill in
9 Speak the language Use power phrases: “think step by step”, “critique your own response”, “adopt the persona of an expert in X”
10 Divide and conquer Break complex tasks into subtasks, prompt for each, then synthesize

How do you get better output from Claude Code?

XML Formatting for Structured Input

When providing complex prompts (especially for front-end design), wrap sections in XML tags:

<goal>Build a responsive dashboard with real-time data visualization</goal>
<inspiration>
  <image>screenshot-airbnb-dashboard.png</image>
  <image>screenshot-notion-kanban.png</image>
</inspiration>
<guidelines>
  - Use 8px spacing grid
  - Primary: #1A7285, Secondary: #9333EA
  - Smooth 0.2s transitions on hover states
</guidelines>
<context>
  <app-overview>YouTube production manager for managing videos and sponsors</app-overview>
  <philosophy>Clean, minimal, focused on data density</philosophy>
  <specific-task>Build the sponsor pipeline view with three modes: calendar, table, kanban</specific-task>
</context>

“Language models perform better when you have structured data. If you’re trying to build really meaningful advanced stuff, you should double down on providing structured prompts.” – I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)

Providing Concrete Examples

The single highest-impact prompting technique: provide a filled-out example of exactly what you want.

For a style guide: Give a complete example style guide (colors, typography, component styling, spacing system, motion/animation), then say: “Based on this app and its philosophy, build me a design system that follows this example specifically.”

For tests: Show an example of a well-written test from an expert backend engineer, then ask Claude Code to follow that pattern.

“The best thing you could possibly do if you did nothing else on this list is to provide very concrete examples.” – I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)

Explicit Over Implicit Instructions

“Create an analytics dashboard” produces mediocre output. This produces quality:

Create an analytics dashboard. Include as many relevant features and
interactions as possible. Go beyond the basics to create a fully featured
implementation.

Even better: use a /improve-prompt command that runs Socratic dialogue to extract specifics before execution.

“Explicit instructions unlock the above-and-beyond behavior of Claude models.” – Anthropic docs, cited in I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)

Motivating Context

Tell Claude why something matters. Context about intended use improves output quality (I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)).

# Bad:
Never use ellipses in responses.

# Good:
Your response is going to be read aloud by a text-to-speech engine,
so never use ellipses since the TTS engine will not know how to process them.

Clear Direction Against Overengineering

Claude loves backwards compatibility, graceful fallbacks, and enterprise-ready patterns. Counter this explicitly (Master Claude Code: Proven Daily Workflows from 3 Founders (opens in a new tab); I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)):

Only make changes that are directly requested.
Keep the solutions simple and focused.
No backwards compatibility. No graceful fallbacks.
Delete code that is no longer needed.

“It loves backwards compatibility, which I don’t. It’s like ‘we’ll have graceful fallbacks’ and I’m like ‘no, that’s just junk. That will break. And then it will gracefully fall back. That means the app is going to silently fail.’” – Master Claude Code: Proven Daily Workflows from 3 Founders (opens in a new tab)

A widely shared CLAUDE.md turns the same direction into four principles. Think before coding: state assumptions, present competing interpretations instead of picking one silently, and stop to ask when something is unclear. Simplicity first: no features, abstractions or configurability beyond the request. Surgical changes: match the existing style, remove only what your own change made unused, and mention unrelated dead code instead of deleting it, with the test that every changed line traces to the request. Goal-driven execution: turn an imperative task into a verifiable goal, so “fix the bug” becomes “write a test that reproduces it, then make it pass”. The file states its own tradeoff, caution over speed, and says to use judgment on trivial tasks (multica-ai - Claude Code guidelines against LLM coding pitfalls (opens in a new tab), as of September 2026).

RL Bias Awareness (New Code Over Edits)

Due to reinforcement learning training, Claude prefers writing new code over editing existing code. It was trained on “write code, does it compile, does it pass?” – not “elegantly edit existing code.”

Symptoms:

  • Writes new methods instead of modifying existing ones
  • Copies code rather than refactoring
  • Creates new files instead of editing in place

Counter-prompt:

Edit the existing code. Do not write new methods or files.
Figure out where to integrate this into the existing codebase.

“Claude is still really tuned into ‘I’m gonna write some new code. This is gonna be fun. We’re gonna do a new method, guys.’ You really have to prompt editing.” – Master Claude Code: Proven Daily Workflows from 3 Founders (opens in a new tab)

Explore-First Custom Command

Build a slash command that forces thorough exploration before implementation:

# .claude/commands/explore-first.md

Before implementing anything:

1. List the entire directory structure
2. Read all related files
3. Go deep into reading those related files
4. Summarize the patterns you found
5. THEN determine what needs to change and proceed with implementation

“Claude Opus is actually very conservative at exploring your codebase before it decides to do something. You just need to tell it not to do that.” – I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)

Minimizing Hallucinations

Add to system prompt:

Never assume or speculate about what is inside a file.
You must actually read what is inside a file and investigate it fully
before implementing something based on what you think is inside of it.

“A surprising flaw of Claude Code is that it would speculate about what’s inside of a file. It builds something entirely disconnected from what the reality of this file is.” – I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)

Controlling Proactivity

Set how far Claude acts on its own inference, depending on the stakes of the task (I Didn’t Know These Claude Code Rules (Big Mistake) (opens in a new tab)).

More proactive (for simple tasks):

If my intent is unclear, infer what I most likely meant,
fill in the details yourself, and execute.

More conservative (for critical tasks):

Do not jump into implementation or changes unless
I explicitly tell you to.

“Agent Smell” Evaluation

Surface-level metrics for sanity-checking agent quality:

  • How many tool calls did it make?
  • How many retries?
  • How long did it take?
  • Did it go in circles?

Use these to compare different prompts, models, or configurations without deep eval infrastructure.

“Run an agent and see how many times does it call a tool call. How many times does it retry? How long does it take? These are surface level metrics but really good for sanity checking.” – How Claude Code Works (opens in a new tab)

Resources

Behavioral guidelines

Talks and videos