Prompt Writing for Technical Work: The 5 Parts of a Good Request

When an AI gives an irrelevant or generic answer, the first reaction is "this model is useless." But in most cases the model answered exactly what it was asked: a vague question.

Prompt writing isn't magic and doesn't need strange formulas. It's the same thing you do when you write a good ticket for a coworker.

A simple test: the new teammate#

Before sending any request, ask yourself:

If I gave this exact text to a smart colleague who knows nothing about my project, could they do the job?

If the answer is "no," the model can't either. The model hasn't seen your project, doesn't know what host you're on, and doesn't know what you tried yesterday.

The five parts of a good request#

1. Context#

The model needs to know where it is. For technical work that means:

• The software and its version (WordPress, Laravel, PHP)
• The runtime environment (shared hosting, VPS, local)
• Any limits of the environment (no SSH access, a certain function is disabled)

2. Goal#

Not just "what," but why. "Write a function that converts a date" gets a completely different answer from "I need to show the database's UTC dates in the visitor's local timezone inside a WordPress template, and I don't want to install a plugin."

3. Data#

The error message, the code snippet, the command output. The exact text, not a description of it. "It gives a database error" helps nobody; the full error text changes everything.

4. Constraints#

Things that must not happen:

• "Don't change the table structure"
• "No external libraries"
• "It must also work on PHP 8.1"

5. Output format#

If you don't say, the model decides for itself and usually over-explains. Say what you want: code only, code with a line-by-line explanation, a list of steps, or a comparison table.

Before and after#

Before:

My site is slow, what do I do?

What you get: a list of twenty generic tips found in every SEO article.

After:

Context: WordPress store on shared cPanel hosting, PHP 8.2,
about 400 products. No caching plugin installed.

Problem: the homepage takes about 4 seconds to deliver the first
byte (TTFB). Single product pages are fast.

Data: in Query Monitor the homepage runs 310 queries, and most of
them come from the theme's "Best sellers" widget.

Constraints: I can't change hosts and I have no SSH access.

I want: three solutions in order of impact, each with a one-line
explanation of why it works. Code only for the first solution.

This request is ten lines and takes two minutes to write. The answer goes straight to caching that widget, not "compress your images."

Three popular patterns#

Ask first, answer later#

When you aren't sure yourself what information is needed:

Before answering, ask me any questions you need to give an accurate answer.

Plan first, code later#

For any task that touches more than one file:

First, only tell me which files you would change and why. Don't write code until I approve.

This one step prevents most pointless rewrites.

Give an example#

If the output must have a specific shape, give one real example. One example works better than ten lines of explanation.

Common mistakes#

We wrote separately about the last one: what you should never give to AI.

A ready template#

Keep this and fill it in each time:

Context: [software and version, runtime environment]
Goal: [what I want and why]
Data: [error text, code, output]
Already tried: [what I did and what happened]
Constraints: [what must not change]
Output: [code only / step by step / comparison]

Continue on this path#

If this article helped, these pieces go deeper on the same topic with more practical detail:

Summary#

• The model doesn't know your project; you have to supply the context.
• Give the exact error and code, not a description of them.
• State constraints and output format explicitly.
• For big work, ask for a plan first and code second.
• When a conversation goes bad, don't patch it; start over.