How to Do Prompt Engineering: A Practical Method

Prompt engineering is the process of writing and refining instructions for a language model until it reliably produces the output you need. "How to prompt engineer" isn't a single trick — it's a loop: define what success looks like, write a draft prompt, run it against real inputs, look at where it fails, and adjust. This article walks through that loop step by step, with concrete examples you can copy.

The short version: start specific, add structure, show examples, then test against edge cases before you trust the output in production. Everything below expands on that.

Step 1: Define the task before you write anything

Before touching a prompt, write down what "correct" looks like. Vague goals produce vague prompts. Instead of "summarize this article," decide:

• Length (2 sentences, 100 words, 5 bullet points)
• Audience (a developer, a customer, a legal team)
• Tone (neutral, formal, casual)
• What must be excluded (no opinions, no speculation, no marketing language)

If you can't describe success in a sentence, the model can't hit it either. This is the step most people skip, and it's why "the model doesn't listen to me" is usually a task-definition problem, not a model problem.

Step 2: Structure the prompt

A well-structured prompt separates three things: the role or context, the task, and the output format. A common pattern:

System: You are a technical writer who summarizes changelogs for developers.
Rules:
- Use plain language, no marketing tone.
- Max 3 bullet points per release.
- Skip internal-only changes.

User: Summarize this changelog entry:
"v2.3.0 — Fixed race condition in webhook retries, added
support for custom timeout headers, internal refactor of
the queue worker, deprecated the legacy /v1/events endpoint."

Notice the rules are explicit and enumerated, not buried in a paragraph. Models follow bullet-pointed constraints more consistently than prose instructions. If you're calling an API directly, this structure maps cleanly onto a system prompt plus a user message:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet",
    "system": "You are a technical writer who summarizes changelogs for developers. Use plain language, max 3 bullets, skip internal-only changes.",
    "messages": [
      {"role": "user", "content": "Summarize: v2.3.0 — Fixed race condition in webhook retries, added support for custom timeout headers, internal refactor of the queue worker, deprecated the legacy /v1/events endpoint."}
    ]
  }'

Keeping the system prompt separate from the per-request message means you can reuse the same rules across thousands of calls without re-explaining them each time. See /docs/messages for the full request shape.

Step 3: Show, don't just tell

Instructions describe the rule; examples show the pattern. When a task has any ambiguity — formatting, tone, edge case handling — one or two examples in the prompt (few-shot) outperform a longer instruction list.

Convert customer messages into a structured ticket.

Example:
Input: "the app crashes every time I upload a PDF over 10MB"
Output: {"category": "bug", "severity": "high", "summary": "App crashes on PDF upload >10MB"}

Now convert:
Input: "can you add dark mode please"

The example teaches the exact JSON shape and severity logic faster than a paragraph of rules would. Two examples is usually enough; more than four or five starts eating context and diminishing returns.

Step 4: Constrain the output format

If your prompt output feeds into code, a database, or another API call, ask for a strict format — JSON with a defined schema, a fixed set of labels, a specific delimiter. This removes an entire class of parsing bugs.

Respond with only valid JSON matching this shape:
{"category": string, "severity": "low"|"medium"|"high", "summary": string}
No text outside the JSON object.

If you need the model to call functions or return structured actions rather than free text, that's a separate mechanism from prompt-only formatting — worth knowing before you try to fake it with instructions alone. See /docs/tools for how tool use works when you need guaranteed structured calls rather than hoped-for JSON.

Step 5: Test against real inputs, not your best-case example

The prompt that works on your one test sentence will break on the messy, real-world input a user actually sends. Build a small set of 10–20 representative inputs, including edge cases (empty input, very long input, input in another language, adversarial input), and run the prompt against all of them before shipping. Track failures the same way you'd track a bug: what input, what output, what you expected.

This is also where streaming matters for user-facing products — if your prompt produces long output, testing only the final result can hide latency problems that only show up once you stream tokens back to a UI. See /docs/streaming if you're building a chat-style interface.

Step 6: Iterate on failures, not on the whole prompt

When something fails, change one thing at a time — add a rule, add an example, tighten the format — and re-run your test set. Rewriting the entire prompt after every failure makes it impossible to know what actually fixed (or broke) the behavior.

Where prompt engineering meets infrastructure

Good prompts are only half the job. Once a prompt works, you need to call it reliably from your application: authentication, rate limits, usage tracking per feature or team, and a stable endpoint that doesn't change under you. That's the gap SubToAPI fills — it turns your existing Claude access into an HTTPS API with application keys (sub_live_...), so the prompts you've engineered can be called from production code with proper auth and usage metadata instead of a shared personal login. Start with /docs/quickstart, check /pricing for plan details, or /signup to get a key.

FAQ

Do I need a special tool to do prompt engineering?

No. A text editor and access to a model API is enough. Tools that track prompt versions and test results help at scale, but the core skill is writing clear, structured instructions and testing them against real inputs.

How long should a prompt be?

As long as it needs to be to remove ambiguity, no longer. Short, specific prompts with 1–2 examples usually outperform long, vague ones. Trim anything that doesn't change the output.

How is prompt engineering different from fine-tuning?

Prompt engineering changes instructions at request time with no model retraining — fast to iterate, easy to reverse. Fine-tuning changes the model's weights and requires training data and infrastructure. Most teams should exhaust prompt engineering before considering fine-tuning.