Overview
What “Prompt Engineering” Actually Is
Prompt engineering is not about secret keywords or magic phrases. It is:
- Designing an interface between your brain and the model.
- Making the contract explicit: what goes in, what must come out.
- Turning chaos into patterns that you can reuse and share.
Within E (English Language Programming), a “prompt” is a program. You describe a role, list inputs, spell out a process, define an output shape, and add checks. Same structure every time.
Minimal E Skeleton
Role:
[Who is the model pretending to be?]
Inputs:
- [Bullet list of what the user/system will provide.]
Process:
1. [Step 1...]
2. [Step 2...]
3. [Step 3...]
Output:
- [Exact structure and length limits.]
Checks:
- [What to verify before returning.]
Every pattern on this page is just a thicker version of this skeleton.
Principles
Core Principles of Prompt Engineering in E
- One job per prompt. Don’t ask for ten unrelated things at once.
- Interfaces, not vibes. Think like an API designer: inputs and outputs.
- Concrete over clever. “Give me 5 bullet points” beats “summarize elegantly”.
- Constrain where it matters. Length, structure, style—say it out loud.
- Check your work. Make the model list what it verified.
When a prompt “doesn’t work,” it’s almost always because one of these principles was violated. The rest of this page is about fixing that.
Patterns
Reusable Prompt Patterns
These are generic patterns you can paste, rename, and adapt. Each one is a reusable E program for a common class of tasks.
Pattern
Explainer: Teaching Something New
▶
Role:
You are a patient teacher who explains concepts clearly to [target audience].
Inputs:
- Topic to explain.
- Target audience (age, background).
- Context (exam prep, casual learning, professional).
Process:
1. Identify what the audience likely already knows and does not know.
2. Explain the topic in 3–7 short paragraphs:
- Start with a simple analogy or hook.
- Add one concrete example.
- Name any key terms and define them in context.
3. End with 3–5 questions the reader can answer to test themselves.
Output:
- A short explanation (400–700 words).
- A "Quick Check" section with 3–5 questions.
Checks:
- Avoid unexplained jargon; define any technical term you introduce.
- If the topic is too broad, narrow it and say what you focused on.
Pattern
Transformer: Rewrite Text with Constraints
▶
Role:
You are a careful text transformer.
Inputs:
- Original text.
- Target style (e.g., "formal", "friendly", "for 9th graders").
- Constraints (length limit, keep quotes intact, etc.).
Process:
1. Read the original once for meaning.
2. Rewrite the text to match the target style while preserving meaning.
3. Respect all constraints:
- Length
- Required phrases
- Sections that must not change
Output:
- Revised version of the text only, no extra commentary.
Checks:
- Confirm you did not remove any required information or change facts.
- If a constraint conflicts with preserving meaning, say what the conflict is.
Pattern
Evaluator: Critique and Score Work
▶
Role:
You are an evaluator using a rubric to score work fairly.
Inputs:
- The work to evaluate (essay, description, summary, etc.).
- A rubric with 3–6 criteria and scoring ranges.
- Any instructions about weightings or special rules.
Process:
1. Quote or restate each criterion briefly.
2. For each criterion:
- Explain how the work meets or does not meet it.
- Assign a score.
3. Compute the total or overall judgment as requested.
Output:
- "Per-Criterion Feedback" section.
- "Scores" section with a small table or list.
- One paragraph of overall feedback.
Checks:
- Apply the rubric literally; do not invent new criteria.
- If the rubric is vague, point out the ambiguity instead of guessing silently.
Pattern
Planner: Break Big Tasks into Steps
▶
Role:
You are a planner who breaks big goals into clear steps.
Inputs:
- The goal, described in 2–4 sentences.
- Deadline or time window.
- Constraints (experience level, tools, time per week).
Process:
1. Identify 4–10 major steps from start to finish.
2. For each step, specify:
- What is done.
- What "done" looks like.
- Rough time estimate.
3. Group steps into phases if useful (Phase 1, Phase 2, etc.).
Output:
- A numbered list of steps with short descriptions.
- Optional phases as headings.
Checks:
- Ensure steps are in a logical order.
- If the goal is unrealistic for the time window, say so and suggest a reduced version.
Pattern
Chain: Multi-Step, Multi-Call Workflows
▶
Role:
You are a workflow designer orchestrating several model calls.
Inputs:
- Description of the overall workflow.
- The distinct stages (e.g., Outline, Draft, Critique, Revise).
- Any constraints for each stage.
Process:
1. Define a separate E program for each stage with its own:
- Role
- Inputs
- Process
- Output
- Checks
2. Describe how data flows between stages.
3. List any human decision points where a person must review or choose.
Output:
- A written spec of the workflow:
- "Stage 1: ..."
- "Stage 2: ..."
- etc.
- For each stage, include the full E program.
Checks:
- Make sure each stage has exactly one job.
- Avoid circular dependencies between stages unless clearly intentional.
Debugging
Debugging Prompts When They Misbehave
When a prompt gives junk, treat it like a bug. Don’t blame “the AI”; inspect the program.
Common Failure Modes
- Ambiguous goals: model doesn’t know what to optimize for.
- Missing inputs: you assume it knows something it doesn’t.
- Contradictory instructions: “be short” and “explain in detail” together.
- Overloaded prompts: too many tasks mashed into one blob.
- No output contract: you never said what shape you wanted.
Debugging Pattern (E Style)
Role:
You are a prompt debugger.
Inputs:
- The original prompt.
- One or two example outputs that were unsatisfying.
- The user's true goal.
Process:
1. Identify at least 3 concrete reasons the output missed the goal.
2. Map each problem to a missing or weak part of the prompt:
- Role
- Inputs
- Process
- Output
- Checks
3. Propose a revised version of the prompt that fixes those issues.
Output:
- Bullet list of "Problems" with the original.
- "Revised Prompt" block in full E format.
Checks:
- Preserve the user's true goal; do not change what they are trying to do.
- Keep the revised prompt no longer than it needs to be.
Lab
Prompt Engineering Lab: Practice Scripts
These are plug-and-play “lab exercises” you can use to train yourself (or students/clients) in prompt engineering with E. Swap out topics and reuse.
Lab
Lab 1 – Turn a Vague Request into an E Program
▶
Role:
You are a coach teaching someone to turn vague prompts into E programs.
Inputs:
- A vague prompt (e.g., "Help me write my book", "Explain AI").
Process:
1. Ask the user 3–7 clarifying questions to uncover:
- Goal
- Audience
- Constraints
- Examples of "good" output.
2. Based on the answers, write a full E program with:
- Role
- Inputs
- Process
- Output
- Checks
3. Show both the original vague prompt and the improved E program.
Output:
- "Original Prompt" section.
- "Questions & Answers" section.
- "Final E Program" section.
Checks:
- Ensure every element in the E program is grounded in the user’s answers.
- If the user skips critical info, note that in the Checks section.
Lab
Lab 2 – Compare Two Prompts for the Same Task
▶
Role:
You are a prompt comparison analyst.
Inputs:
- Prompt A and Prompt B (both aimed at the same task).
- One or more example outputs from each.
Process:
1. Describe the task both prompts are trying to solve.
2. Compare:
- How each prompt defines the role.
- How clearly each lists inputs.
- How precise each is about output format.
3. Identify strengths and weaknesses of each.
4. Propose a new "Prompt C" that combines the best ideas.
Output:
- Short comparison table or bullet list.
- "Prompt C" written as an E program.
Checks:
- Do not declare a winner without explaining why.
- If both prompts are bad, say so and redesign from the ground up.
Lab
Lab 3 – Shrink a Powerful Prompt
▶
Role:
You are a prompt refactorer whose job is to make prompts shorter without losing power.
Inputs:
- A long, working prompt.
- A maximum target length (e.g., 500 words, 200 words).
Process:
1. Identify which parts of the long prompt actually change the output.
2. Remove any repeated or decorative phrasing.
3. Compress the remaining instructions using:
- Lists
- Headings
- Short, direct sentences
4. Keep the E structure visible (Role, Inputs, Process, Output, Checks).
Output:
- "Original Prompt Length" and "New Prompt Length".
- The shorter prompt in full.
- 2–3 notes on what was removed and why.
Checks:
- Test mentally whether each removed part truly changes nothing important.
- If the target length is unrealistic, say so and produce the best compromise.
Template
Copy-Paste Template for New Prompt Patterns
Use this template as your “blank file” whenever you design a new prompt pattern for a specific domain (accounting, derby strategy, textbooks, whatever else you’re cooking).
Role:
[Who is the model pretending to be? One clear identity.]
Inputs:
- [List each input you expect: text, data, constraints, examples.]
- [Include audience, tone, length, platform if relevant.]
Process:
1. [Step 1: read / analyze / extract something from inputs.]
2. [Step 2: transform / organize / generate new content.]
3. [Step 3: format in the required way.]
4. [Optional: add summaries, examples, or alternatives.]
Output:
- [Describe the exact structure: headings, bullets, tables, word counts.]
- [Mention any extras: examples, warnings, suggestions.]
Checks:
- [List 2–5 things the model must verify before returning.]
- [Add any "do not" rules you care about.]
Every time you discover a prompt that works, promote it to an E pattern, store it, and reuse it. That’s prompt engineering as software, not superstition.