Most people try to improve AI results by writing longer prompts. A better approach is to borrow methods from disciplines that already solve problems involving ambiguity, complex instructions, and quality control.
Aircraft maintenance documentation, systems engineering, software testing, plain-language writing, and data validation all offer useful ideas for making prompts clearer and AI outputs easier to verify.
For example, ASD-STE100 is a controlled-language standard developed for technical documentation. EARS helps engineers write requirements in structured patterns. JSON Schema defines the expected structure of data. These methods were not all designed for AI, but their underlying principles can be adapted to prompt engineering.
In this guide, you will learn eight engineering-inspired prompt engineering techniques, when to use each one, and how to apply them with complete copy-and-paste examples for ChatGPT, Claude, and AI coding agents.
Quick guide: Which prompt engineering technique should you use?
| Technique | Best use |
|---|---|
| ASD-STE100 principles | Clear instructions, SOPs, technical tasks |
| EARS requirements | Defining how an AI system must behave |
| Gherkin scenarios | Testing workflows and expected outcomes |
| Plain-language principles | Training content and business communication |
| XML and Markdown structure | Long prompts and multi-step agents |
| JSON Schema | Structured, machine-readable AI output |
| Test-driven prompting | Building software with coding agents |
| Evaluation-driven prompting | Improving reliability over repeated runs |
1. ASD-STE100: Use controlled language to reduce ambiguity
Best for: AI coding agents, business process automation, technical documentation, standard operating procedures, and repeatable workflows.
ASD-STE100, or Simplified Technical English, originated in the aerospace industry to make technical documentation easier to understand. It uses writing rules and a controlled dictionary to reduce confusing vocabulary and sentence structures. Its purpose is not to make every document short; it is to make instructions easier to interpret consistently.
Consider this vague request: “Look through the website, improve anything that seems outdated, make the design better, and fix whatever else needs attention.” What does “better” mean? Which pages can be changed? Is the AI allowed to delete content? How should success be measured?
A controlled-language approach replaces vague instructions with direct actions, explicit boundaries, and observable outcomes.
Principles to borrow
- Use one instruction for one main action.
- Prefer specific verbs such as inspect, list, update, test, and report.
- Use the same term for the same concept throughout the prompt.
- Replace subjective words such as “good” and “better” with measurable requirements.
- State what the AI must not change.
- Ask the AI to report incomplete work.
These are adaptations of general clarity principles, not a claim that an AI prompt complies with the complete ASD-STE100 specification.
Complete example: Audit a WordPress website
Weak prompt:
Check my website and make it better. Fix the SEO,
improve the design, update old posts, and make
everything work properly.Improved prompt:
ROLE
Act as a WordPress website auditor.
OBJECTIVE
Audit SEO, readability, navigation, mobile usability,
and performance.
INPUT
Website: https://example.com
INSTRUCTIONS
1. Inspect the homepage and main navigation.
2. Review the 10 most recently published articles.
3. Identify weak page titles and meta descriptions.
4. Identify broken links and confusing navigation labels.
5. Check whether headings follow a logical hierarchy.
6. List observable mobile usability issues.
7. Separate verified problems from possible improvements.
CONSTRAINTS
- Do not delete pages or posts.
- Do not publish changes.
- Do not change the website theme.
- Do not invent performance measurements.
- State which checks require external tools.
OUTPUT
Create a table with:
Finding | URL | Evidence | Recommended action |
Priority | Verification method
SUCCESS CRITERIA
Every recommendation must identify a specific problem
or a clearly labelled improvement opportunity.
Finish with the five highest-priority actions.Why it works: The prompt defines the task, limits the AI’s authority, and specifies what the report must contain. It also separates verified findings from assumptions.
Try it: Take one prompt you use regularly. Replace vague words with specific actions, measurable outcomes, and clear boundaries.
2. EARS: Turn vague requests into explicit requirements
Best for: Coding agents, SaaS development, API integrations, CRM automation, and complex business workflows.
EARS stands for Easy Approach to Requirements Syntax. It helps people write requirements in structured patterns, including requirements that apply continuously, respond to events, depend on a state, or describe unwanted behaviour.
The key lesson for prompt engineering is that a requirement should describe what the system must do under a defined condition.
Compare “Make the CRM secure” with “When a user signs in with invalid credentials, reject the sign-in attempt and display an error message that does not reveal whether the email address exists.” The second request describes a condition and an observable response. It is easier to implement and test.
Complete example: Build a lead-generation CRM
PROJECT
Build a web-based lead-generation CRM.
R1 — Lead creation
When a user submits a valid lead form, save the lead
and generate a unique lead ID.
R2 — Duplicate prevention
When a submitted lead matches an existing lead by email,
flag the possible duplicate before creating a second record.
R3 — Lead qualification
When a lead has a company name, job title, business email,
and source, mark it eligible for qualification.
R4 — Missing information
If a required field is missing, identify the field and
reject the incomplete submission.
R5 — Follow-up tasks
When a lead is assigned to a sales representative,
create a follow-up task with a due date.
R6 — Outreach permissions
Before an outreach message is sent, check the configured
consent, suppression, and sending rules for that contact
and communication channel.
R7 — Delivery failures
If an email provider reports a permanent failure, record
the failure and prevent retries that violate provider rules.
R8 — Audit trail
Record the timestamp and actor for important changes
to lead status and outreach activity.
DELIVERABLES
1. Requirements document.
2. Database schema.
3. API specification.
4. User interface.
5. Automated tests.
6. Setup instructions.
Before implementation, identify missing decisions and
present a proposed architecture for approval.Why it works: Each requirement can become a development task and a test. This makes missing decisions easier to identify before implementation starts.
Use EARS when: You need an AI agent to build something that must behave predictably across many conditions.
3. Gherkin: Describe behaviour with Given–When–Then
Best for: Chatbots, customer-support agents, workflow automation, browser agents, and regression testing.
Gherkin is a structured language used to describe software behaviour in a readable format. Its familiar syntax uses Given, When, and Then to describe the starting condition, action, and expected outcome.
- Given: What is true before the task starts?
- When: What action or event occurs?
- Then: What outcome should be observable?
Complete example: Create an AI customer-support agent
ROLE
Build a customer-support chatbot for an online store.
Scenario 1: Answer a known question
Given the customer asks about the published return policy
And the policy exists in the approved knowledge base
When the chatbot receives the question
Then it answers using the relevant policy
And it does not add unsupported policy terms
And it cites the policy reference when available
Scenario 2: Handle an unknown answer
Given the knowledge base does not contain the answer
When the customer asks a question
Then the chatbot states that it cannot verify the answer
And asks a relevant follow-up question or offers escalation
And does not invent a policy
Scenario 3: Request a refund
Given the customer requests a refund
When the chatbot identifies the request
Then it collects the minimum required information
And checks the applicable refund policy
And explains the next step
The chatbot must not issue a refund unless an authorized
tool confirms the action is permitted.
Scenario 4: Escalate a complaint
Given the customer requests a human representative
When the chatbot detects the request
Then it offers the configured escalation process
And preserves relevant conversation context
And does not claim a ticket was created unless confirmed.
IMPLEMENTATION
Convert each scenario into an automated test where possible.
Use mocked services for tests that must not trigger real
refunds, emails, or account changes.
OUTPUT
Provide the implementation, test cases, and a report
showing which scenarios pass or fail.Why it works: Scenarios expose edge cases before implementation. They also let you test an AI system against expected behaviour instead of judging it only by how convincing its answers sound.
4. Plain-language principles: Write prompts for the real reader
Best for: Training content, business communication, AI-generated documentation, customer-facing content, and non-technical teams.
ISO 24495-1:2023 provides principles and guidelines for creating plain-language documents. It is a writing standard, not a prompt-engineering framework, but its emphasis on reader needs and comprehension is useful when designing AI instructions.
A prompt can contain all the right information and still perform poorly if instructions are buried in long paragraphs or mixed with irrelevant context.
Complete example: Create an employee training module
ROLE
Act as a corporate learning designer.
AUDIENCE
Indian professionals with intermediate English skills.
They understand routine workplace communication but need
help with assertiveness and handling disagreements.
OBJECTIVE
Create a practical 60-minute training module on
assertive communication at work.
LEARNING OUTCOMES
By the end, participants should be able to:
1. Distinguish assertive, passive, and aggressive language.
2. Rewrite an unclear request as a specific request.
3. Respond to disagreement without personal attacks.
CONTENT RULES
- Use simple, professional English.
- Explain one main idea at a time.
- Define technical terms before using them.
- Use realistic workplace examples.
- Avoid generic motivational statements.
SESSION STRUCTURE
1. Opening activity: 5 minutes.
2. Concept explanation: 10 minutes.
3. Facilitator demonstration: 10 minutes.
4. Paired practice: 15 minutes.
5. Group discussion: 10 minutes.
6. Knowledge check and action plan: 10 minutes.
DELIVERABLES
Provide facilitator notes, slide-by-slide content,
two workplace case studies, one paired practice activity,
five assessment questions with answers, and an action plan.
QUALITY CHECK
Map each learning outcome to at least one activity
and one assessment question.Why it works: The prompt is designed around the learner, not simply the topic. It defines learning outcomes, practical activities, and a way to check whether the session meets its objectives.
5. XML and Markdown: Separate instructions from context
Best for: Long prompts, system instructions, coding agents, research workflows, and multi-stage automation.
When a prompt mixes instructions, source material, examples, and restrictions in a single block, the model may not clearly distinguish their roles. Markdown headings and XML-style tags can give each part a clear boundary.
Useful labels include <role>, <task>, <context>, <constraints>, <input>, and <output_format>. These are illustrative tags, not special commands that every model must execute.
Complete example: Research a competitor
<role>
You are a business research analyst.
</role>
<task>
Compare the supplied competitor information and identify
three opportunities to differentiate our product.
</task>
<context>
Our product is a digital profile and portfolio platform.
Users can publish a professional profile using a personal
URL or subdomain.
</context>
<input>
Competitor A:
Features: Profile pages, templates, contact links.
Pricing: Not supplied.
Competitor B:
Features: Portfolio pages, project galleries.
Pricing: Not supplied.
</input>
<constraints>
Do not invent pricing, customer counts, or market share.
Separate supplied facts from hypotheses.
Do not claim a feature is unique without evidence.
</constraints>
<analysis_requirements>
1. Compare the known features.
2. Identify gaps in the supplied information.
3. Suggest three differentiation opportunities.
4. Explain the target customer for each opportunity.
5. State how each opportunity could be validated.
</analysis_requirements>
<output_format>
Return an executive summary, comparison table,
three opportunity statements, missing information,
and a validation plan.
</output_format>Why it works: Each section has a distinct purpose. It becomes easier to update the task without accidentally changing the context or constraints.
Structured boundaries can also help prevent the model from treating every piece of supplied text as an instruction. For example, text found on a competitor’s website should be treated as source material, not as an instruction to ignore the user’s task.
6. JSON Schema: Define the output contract
Best for: APIs, CRM imports, lead extraction, structured research, workflow automation, and applications that consume AI output programmatically.
JSON Schema describes the structure and constraints of JSON data. It can specify required fields, data types, and permitted values. This is useful when an AI must return data that another system can process.
Complete example: Extract lead information
Prompt:
TASK
Extract lead information from the supplied text.
RULES
1. Use only information supported by the source.
2. Do not invent email addresses, phone numbers, or names.
3. Use null for missing or unverified values.
4. Return one JSON object with the defined fields.
5. Do not include Markdown fences or explanatory text.
SOURCE
Company: Northstar Digital
Contact: Priya Sharma
Role: Head of Marketing
Website: https://example.com
Email: Not providedExample JSON Schema:
{
"type": "object",
"properties": {
"company_name": {"type": "string"},
"contact_name": {"type": ["string", "null"]},
"job_title": {"type": ["string", "null"]},
"website": {"type": ["string", "null"]},
"business_email": {"type": ["string", "null"]},
"verification_status": {
"type": "string",
"enum": [
"verified_from_source",
"partially_verified",
"unverified"
]
}
},
"required": [
"company_name",
"contact_name",
"job_title",
"website",
"business_email",
"verification_status"
],
"additionalProperties": false
}Expected output:
{
"company_name": "Northstar Digital",
"contact_name": "Priya Sharma",
"job_title": "Head of Marketing",
"website": "https://example.com",
"business_email": null,
"verification_status": "partially_verified"
}Why it works: The output has a predictable structure, missing information is represented explicitly, and downstream software can validate the result.
Important distinction: asking an AI to follow a JSON Schema is not the same as validating the output against it. For production systems, use a JSON Schema validator or a supported structured-output feature, and reject or repair invalid results.
7. Test-driven prompting: Define success before asking AI to build
Best for: Claude Code, OpenCode, application development, scripts, integrations, and debugging.
Test-driven development uses tests to define required software behaviour. Adapted to AI-assisted development, the principle is simple: define how you will verify success before asking the agent to implement the feature.
Complete example: Build a resume-builder application
PROJECT
Build a responsive resume-builder web application.
FEATURE
Allow a user to enter resume details, select a template,
preview the resume, and export it as a PDF.
ACCEPTANCE TESTS
Test 1: Empty form
Given a new user opens the resume builder
When the user tries to export an empty resume
Then the application identifies required fields
And does not generate an invalid resume.
Test 2: Valid resume
Given the user enters a name, work experience, and skills
When the user generates a resume
Then the preview displays the entered information
And the selected template is applied.
Test 3: Special characters
Given the resume contains Unicode characters and long titles
When the resume is generated
Then the text remains readable and does not overlap.
Test 4: Mobile layout
Given the application is opened on a narrow viewport
When the user edits resume information
Then the form remains usable and the preview is accessible.
Test 5: PDF export
Given the resume contains valid information
When the user selects Export PDF
Then a PDF is generated and checked for clipping.
WORKFLOW
1. Inspect the existing repository.
2. Identify required components.
3. Propose the implementation plan.
4. Write or update tests.
5. Implement the feature.
6. Run available tests.
7. Fix failures and run tests again.
8. Report passing tests and unresolved issues.
CONSTRAINTS
Do not delete unrelated features.
Do not replace working dependencies without a reason.
Do not claim a test passed unless it was executed.
Report tests that could not be run.
DELIVERABLES
Provide the working feature, test files, setup steps,
and an implementation report.Why it works: The tests give the agent a concrete target and provide a repeatable way to check whether future changes break existing functionality. It is most valuable for executable software or tasks where failures have meaningful consequences.
8. Evaluation-driven prompting: Measure quality and improve it
Best for: Production AI agents, content generation, customer support, recruitment workflows, and repeated business automation.
A prompt that works once may fail on a different input. Evaluation-driven prompting turns improvement into a repeatable process: define what good output means, test representative inputs, record failures, and refine the prompt or workflow.
Complete example: Evaluate an AI lead-qualification agent
TASK
Classify the supplied business lead using the scoring rules.
SCORING
- Relevant industry: 0 to 3 points.
- Relevant job title: 0 to 3 points.
- Evidence of business need: 0 to 3 points.
- Valid business contact information: 0 to 1 point.
CLASSIFICATION
- High priority: 8 to 10 points.
- Medium priority: 5 to 7 points.
- Low priority: 0 to 4 points.
RULES
Score only evidence supplied in the input.
Do not infer buying intent from a job title alone.
Mark missing information as unknown.
Explain the evidence for each score.
Return the result using the specified JSON structure.Build a test set:
| Test input | Expected behaviour |
|---|---|
| Relevant industry, matching role, documented need, valid contact | High score only if the criteria are met |
| Relevant company, unrelated role, no documented need | Do not assign a high score without evidence |
| Missing company and contact details | Flag insufficient information |
| Conflicting source records | Flag the conflict instead of guessing |
| Unrelated industry and no evidence of need | Low score supported by available evidence |
Evaluate each result:
- Correctness: Did the classification follow the rules?
- Evidence: Can each score be traced to supplied information?
- Consistency: Does the agent handle similar cases similarly?
- Structure: Is the JSON valid and complete?
- Safety: Does the agent avoid inventing facts or sending unauthorized outreach?
Record the results. When the agent fails, determine whether the problem is an unclear instruction, incomplete input, weak scoring rules, or a technical issue. Update the prompt or workflow and run the same test set again.
Why it works: It replaces subjective prompt tweaking with evidence-based improvement. A higher evaluation score does not automatically prove better real-world performance, so test inputs must represent actual use and production performance should be monitored.
How to combine the eight techniques into one prompt
You do not need to choose only one method. For a lead-generation and outreach platform, you might combine controlled language for clarity, EARS-style requirements for behaviour, Gherkin scenarios for user journeys, XML sections for context, JSON Schema for lead records, and acceptance tests for verification.
Reusable master prompt for a business automation system
<role>
Act as a senior software engineer and systems analyst.
</role>
<objective>
Build a lead-management system that captures leads,
stores structured records, supports qualification,
and manages authorized outreach.
</objective>
<requirements>
R1: Validate required lead fields.
R2: Flag potential duplicate records.
R3: Preserve the source of each lead.
R4: Record qualification evidence.
R5: Respect applicable outreach permissions.
R6: Record outreach outcomes and failures.
R7: Provide an auditable activity history.
</requirements>
<constraints>
Do not invent lead information.
Do not send real messages during testing.
Do not expose API keys in frontend code.
Do not delete existing project files without approval.
Do not claim an operation succeeded without confirmation.
Separate verified facts from assumptions.
</constraints>
<workflow>
1. Inspect the repository.
2. Identify missing requirements.
3. Propose the architecture and data model.
4. Define acceptance tests.
5. Present the plan for approval.
6. Implement the approved plan.
7. Run available tests.
8. Fix failures and repeat tests.
9. Report results and remaining risks.
</workflow>
<output_contract>
Provide a requirements checklist, architecture summary,
data model, implementation plan, automated tests,
setup instructions, and test-results report.
</output_contract>
<success_criteria>
Core workflows pass their acceptance tests.
Lead records follow the agreed data structure.
Unauthorized outreach is blocked.
Secrets remain outside client-side code.
Unresolved issues are reported explicitly.
</success_criteria>This master prompt combines several principles, but it does not replace detailed specifications, secure implementation, or human review. Expand each requirement into testable scenarios and define the data schema separately for a real project.
Frequently asked questions
What is engineering-inspired prompt engineering?
Engineering-inspired prompt engineering adapts ideas from controlled technical writing, requirements engineering, software testing, and data validation to make AI instructions clearer and outputs easier to verify. It is a practical approach, not one official standard.
Is ASD-STE100 an official prompt-engineering standard?
No. ASD-STE100 is a controlled-language standard for technical documentation, particularly associated with aerospace and defence. Its principles can inspire clearer prompts, but applying them does not make a prompt compliant with the complete standard.
Which prompt engineering technique is best for coding agents?
For coding agents, combine structured sections, EARS-style requirements, Given–When–Then scenarios, acceptance tests, and structured output contracts when needed. The right combination depends on the complexity and risk of the task.
How can I write better prompts for ChatGPT and Claude?
Specify the task, context, audience, constraints, and expected output. Add examples when format matters. For complex work, define success criteria and ask for verification. A short, specific prompt can outperform a long prompt with conflicting instructions.
Does adding XML tags make AI more intelligent?
No. XML tags do not increase a model’s intelligence or guarantee compliance. They can make instructions and reference material easier to distinguish, especially in long prompts.
How do I test whether a prompt is reliable?
Create representative test inputs, define expected behaviour, run the prompt on those inputs, and score outputs against a consistent rubric. Include edge cases and situations where the correct response is to ask for clarification or report insufficient information.
Can these techniques help build autonomous AI agents?
Yes. They can improve requirements interpretation, output structure, and verification. However, autonomous agents also need appropriate tool permissions, input validation, error handling, logging, safeguards, and human approval for consequential actions.
Final takeaway: Stop treating prompts as magic words
The next stage of prompt engineering is not simply learning more prompt formulas. It is learning how to design instructions that can be understood, executed, and verified.
ASD-STE100 offers lessons in clarity. EARS helps structure requirements. Gherkin makes expected behaviour explicit. JSON Schema defines data contracts. Testing and evaluation help establish whether the result actually works.
Your challenge: Take one AI task you perform repeatedly this week. Rewrite the prompt using one method from this guide, then compare the result against your original prompt. Which method made the biggest difference?
SEO and AEO: Long-tail keywords to explore
Use relevant phrases naturally in future supporting articles and internal links. Do not insert every phrase mechanically.
- how to use ASD-STE100 principles for AI prompting
- engineering-inspired prompt engineering techniques with examples
- how to write clear prompts for ChatGPT and Claude
- EARS requirements syntax for AI coding agents
- Given When Then prompting examples for AI agents
- how to use JSON Schema to validate AI-generated output
- structured prompting with XML and Markdown examples
- prompt engineering techniques for autonomous AI agents
- test-driven prompting for Claude Code and OpenCode
- how to evaluate and improve AI prompts systematically
- how to write reliable prompts for business process automation
- prompt engineering methods for AI-powered CRM systems
Primary sources and further reading
- ASD-STE100 — official website and specification information
- Easy Approach to Requirements Syntax (EARS)
- ISO 24495-1:2023 — Plain language
- OpenAI prompt engineering guidance
- JSON Schema — getting started
Editorial note: These methods are complementary approaches, not eight equivalent prompt formulas. Standards and methods are discussed as sources of inspiration; this article does not claim that any of them is an officially validated prompt-engineering standard.
