Prompt Engineering — Iniciante

Introduction: Why Prompt Engineering Matters

Prompt engineering is the practice of crafting inputs to AI language models to reliably get the outputs you want. It's the difference between an AI that frustrates you and one that functions as a genuine force multiplier for your work.

This guide is grounded in Anthropic's official documentation for Claude. The techniques here apply whether you're using Claude.ai directly or building via the API.

Golden Rule: Show your prompt to a colleague with minimal context and ask them to follow it. If they'd be confused, Claude will be too.

Chapter 1: Basic Prompt Structure

Every interaction with Claude has two core layers: System Prompt — sets context, persona, and rules; persistent across the whole conversation. This is your control panel. User Message — the actual task or question for this turn.

Flow: System Prompt → Who Claude is, rules, format preferences. User Message → The specific task. Assistant Turn → Claude's response.

System prompts answer

• What role is Claude playing?
• What are the rules and constraints?
• What format should output take?
• Who is the audience?

Key facts

• Claude has no memory between separate conversations — only within one. Use the system prompt for persistent context.
• Claude Sonnet 4.6 has a 200,000-token context window (~150,000 words). Beyond this, earlier parts of the conversation fall out.
• For long documents, put them near the top of your prompt. Put your questions and instructions at the end — Anthropic's testing shows this can improve quality by up to 30% on complex inputs.

Chapter 2: Being Clear and Direct

This is the single most important skill. Claude is extremely capable, but it cannot read your mind. Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Specify Output Explicitly

VAGUE: "Summarize this article". SPECIFIC: "Summarize this article in exactly 3 bullet points. Each bullet should be one sentence. Focus on the key business implications. Audience: non-technical executives." The specific version eliminates ambiguity on length, format, focus, and audience.

Positive Instructions Over Negative Ones

Tell Claude what TO do, not what to avoid. NEGATIVE: "Don't use markdown. Don't make it too long. Don't be formal." POSITIVE: "Write in plain prose paragraphs. Under 200 words. Conversational, friendly tone."

Provide Context and Motivation

Explain WHY. Claude will generalize intelligently from your explanation. WITHOUT: "Keep responses short." WITH: "Keep responses under 100 words. This output appears inside a mobile push notification where space is extremely limited."

Use Sequential Steps for Complex Tasks

Example: Analyze this contract using the following steps: 1. Identify all payment terms and amounts. 2. Flag any clauses that could limit liability. 3. List all deadlines and notice periods. 4. Summarize termination conditions. 5. Rate overall risk: Low / Medium / High with justification.

The Colleague Test

Before sending a prompt, mentally hand it to a smart colleague with no prior context. Would they know exactly what to do? If they'd have questions, add those answers to your prompt. Exercise: Take a prompt you've used recently that gave a disappointing result. Apply the colleague test: What was ambiguous? What context was missing? Add those elements and compare the output.

Chapter 3: Assigning Roles

Giving Claude a specific role to inhabit changes everything: vocabulary, assumed expertise level, depth of analysis, what it takes for granted, and how it frames responses.

Why Roles Work

When you tell Claude it's a "senior Python developer," it doesn't just add technical words. It shifts its entire frame of reference: it assumes you can read code, skips basic explanations, considers edge cases, follows software engineering conventions. Example system prompt: "You are a senior Python developer specializing in data pipelines and distributed systems. You write clean, well-documented code and always consider performance implications."

Strong vs. Weak Roles

WEAK: "You are a helpful assistant." STRONG: "You are an experienced B2B sales consultant specializing in AI consulting for Spanish SMBs. You communicate directly, use concrete examples, and focus on ROI. Your clients are business owners, not tech experts — translate jargon into business language."

Types of Roles

• Professional roles: Domain experts (lawyer, doctor, financial analyst) — adjust technical depth and vocabulary.
• Functional roles: Task-specific (editor, Devil's advocate, interviewer) — focus Claude on a specific mode.
• Brand/character roles: Named personas for products ("You are Sofia, assistant for BateauBillet").

Best Practices

• Put the role in the system prompt, not the user message.
• Be specific — "senior tax attorney specializing in Spanish corporate law" beats "legal expert".
• Add context about the user/audience so Claude can calibrate communication style.
• Include relevant personality traits (concise, empathetic, direct, data-driven).

Role + Context = Power

System: You are a grant consultant specializing in Spanish public funding programs (CDTI, ENISA, Horizon Europe). You help consulting firms identify grants for their clients. User: My client is a 12-person SaaS company in Valencia. They've been profitable for 2 years and want to expand to 3 new EU markets. What grants should we explore?

Warning: Don't ask Claude to play roles that conflict with its values. Claude is very good at expert, analytical, and creative roles — it's not suited for impersonating specific real people or roles designed to deceive.