Breaking tasks into clear steps
For complex tasks, break them into numbered steps. Claude follows step-by-step instructions better than vague requests.
Vague:
"Analyze this code and tell me about it."
Structured:
Analyze this code in the following order:
- First, summarize what the code does in 2-3 sentences
- Then, identify any potential security issues
- List performance problems and their impact
- Finally, suggest concrete fixes for each issue
Specifying output format
Tell the AI exactly how you want the output formatted. JSON, Markdown, plain text, tables — be specific.
Example: Output as JSON
"Return your analysis as JSON with keys: summary, security_issues (array), performance_issues (array), fixes (array). For each issue, include: type, severity (high/medium/low), description, fix."
Example: Output as Markdown
"Use this format: # Summary, ## Security Issues (with | tables), ## Performance Issues (with code examples), ## Recommended Fixes"
Imperative vs permissive language
Use imperative (commanding) language for strict requirements, permissive (optional) for flexibility.
Imperative (strict):
- "Always check for SQL injection"
- "Never use deprecated APIs"
- "Return results as JSON"
Permissive (flexible):
- "Consider checking for edge cases"
- "You may use newer APIs if available"
- "Prefer JSON but other formats OK"
Conditional logic in prompts
You can express if/then logic to handle different scenarios.
IF the code contains SQL queries:
- Check for SQL injection vulnerabilities
- Suggest parameterized queries
IF the code has loops with complexity O(n²) or higher:
- Flag for performance review
- Suggest optimization strategies
IF you find security issues:
- Explain the impact
- Provide a fix
- Rate severity (critical/high/medium)
IF you find no issues in a category:
- Say "No issues found in X"Chaining: Multi-step workflows in one prompt
You can chain instructions to handle complex workflows within a single prompt. The AI processes them in order.
STEP 1: Parse the input
Extract user intent, key requirements, constraints
STEP 2: Analyze feasibility
Is this request reasonable? Does it conflict?
STEP 3: Generate options
Propose 3 approaches with tradeoffs
STEP 4: Recommend
Pick the best approach and explain why
STEP 5: Provide code
Show implementation with commentsUsing examples in instructions
Examples are powerful. They show, not tell. A good example is worth a paragraph of explanation.
Example:
"When I ask you to review, respond like this:"
# Summary: [2-3 line summary] # Security Issues: [none/list issues] # Performance Issues: [none/list issues] # Recommended Fixes: [specific code changes]
Ordering and priority of instructions
Long system prompts suffer from what researchers call the lost-in-the-middle effect — models pay closer attention to instructions near the start and end of the context than to instructions buried in the middle. That has practical implications for how you order your rules.
A reliable ordering pattern
- Identity (one or two sentences)
- The single most important rule, stated bluntly
- Operational instructions (numbered steps, format, tone)
- Edge cases and conditional logic
- Constraints and safety rules
- Restate the most important rule one final time
Two anti-patterns to avoid: a bulleted list of fifteen equally-weighted rules (the model treats none of them as primary), and a wall of prose with the key constraint buried in the third paragraph. If a rule absolutely cannot be broken, it should appear at least twice.
Few-shot examples inside the system prompt
Telling the model what good output looks like with two or three concrete examples beats describing the format in prose. Embed them directly in the system prompt for any task where the output shape is unusual, structured, or hard to specify in words.
When extracting structured data from text, follow these examples:
Input: "Sarah, 34, joined as Senior PM in Berlin on March 3rd."
Output: {"name": "Sarah", "age": 34, "role": "Senior PM", "city": "Berlin", "start_date": "2026-03-03"}
Input: "Alex starts at our SF office next Monday as a designer."
Output: {"name": "Alex", "age": null, "role": "designer", "city": "San Francisco", "start_date": "2026-06-01"}
Input: "We hired no one this week."
Output: null
Now extract data from the user's input following the same schema.Three examples is usually the sweet spot — one shows the pattern, the second shows a variation, the third shows what to do when no data is present. More examples consume tokens without proportional accuracy gains. For deeper coverage of one-shot, few-shot, and many-shot prompting tradeoffs, see our zero-shot vs few-shot prompting guide. For JSON and other structured output patterns, see structured output techniques.
Instruction Structuring FAQ
What is instruction chaining in a system prompt?
Instruction chaining is a technique where you define a multi-step workflow inside a single system prompt. Each step builds on the previous one — for example, parse input, analyze feasibility, generate options, recommend, then provide code. The AI processes them in order.
How do I specify output format in a system prompt?
Tell the AI exactly what format you need — JSON, Markdown, plain text, or tables. Include the keys, structure, and field names. For example: 'Return your analysis as JSON with keys: summary, security_issues (array), performance_issues (array), fixes (array).'
Should I use imperative or permissive language in prompts?
Use imperative language (always, never, must) for strict requirements like security checks. Use permissive language (consider, prefer, you may) for flexible guidelines where the AI should exercise judgment. Mixing both gives the best balance.
Can I use if-then conditional logic in a system prompt?
Yes. Express conditions naturally: 'IF the code contains SQL queries, check for injection vulnerabilities. IF you find no issues, say No issues found.' This makes prompts handle diverse inputs robustly without separate prompts per scenario.
Why do numbered steps improve AI system prompt results?
Numbered steps give the AI a clear execution order. Instead of guessing what to do first, the model follows your sequence — summarize, then analyze, then suggest fixes. This produces more structured, complete, and predictable output.
Where should the most important instruction go in a system prompt?
Put your single most important rule at the top, immediately after the identity, and restate it at the bottom. Models weight tokens at the start and end of a prompt more heavily than tokens in the middle — the so-called lost-in-the-middle effect. Critical rules that sit only in the middle of a long prompt are the ones most likely to get dropped.
Should I include few-shot examples inside the system prompt?
Yes when the output format is structured or unusual. Two or three short input-output pairs inside the system prompt establish the pattern far more reliably than describing the format in prose. Skip few-shot examples when the task is straightforward or when the examples would consume tokens you need for actual user content.
Related tutorials
Good instructions build on a solid prompt foundation. Review system prompt anatomy for the three-part structure that frames every prompt. Then learn how persona and role-based prompting shapes the Identity section. To avoid common mistakes, check our guide on system prompt anti-patterns.
For deeper coverage of instruction techniques across the prompt-engineering side, see chain-of-thought prompting for multi-step reasoning and prompt patterns for reusable instruction recipes.
Quick summary
- Break complex tasks into numbered steps
- Specify output format explicitly (JSON, Markdown, tables, etc.)
- Use imperative language for strict requirements, permissive for flexibility
- Express conditional logic: "If X, then do Y"
- Chain instructions for multi-step workflows
- Use examples to show exactly what you want