How to Write Better Instructions for Super Intelligence | Clear AI Prompting and Task Design

Instruction Architecture: Build From the Job Outward

A strong instruction can be designed in layers. Start with the job, then add only the layers necessary to make the job dependable. This is more efficient than beginning with a giant template and deleting parts you do not understand.

Layer 1 is the task. Layer 2 is the source or context. Layer 3 protects meaning. Layer 4 shapes the output for the receiver. Layer 5 defines evidence and checking. Layer 6 defines action boundaries and failure behaviour.

Simple jobs may stop after Layer 1 or Layer 2. A consequential workflow may need all six. The architecture grows because the responsibility grows, not because advanced users are expected to write longer prompts.

Layer 1 — Task Ownership

Write the task so one output can clearly own it. If the instruction contains research, analysis, writing, approval and publication, decide whether those should be separate stages.

Example: “Research current scholarship, choose the best interpretation, write the final policy and publish it” contains several different jobs with different evidence and authority requirements. A better design separates research from decision, decision from drafting and drafting from publication.

Task ownership makes error diagnosis possible. If the source is weak, repair research. If the decision criteria are weak, repair analysis. If the prose is unclear, repair writing. One giant request hides these distinctions.

Layer 2 — Context Architecture

Context should answer what the system needs to know now. Create categories: authoritative source, reference material, audience information, previous decision, style example and current constraints.

Label them. This prevents the system from treating a style example as a factual source or an old decision as current. Context labels are especially useful in long projects and multi-document work.

When the context becomes large, compress it into a current-state brief. Keep archival material available for lookup rather than forcing every old message into the active prompt.

Layer 3 — Semantic Protection

Semantic protection means identifying the parts of meaning that must survive transformation. This is essential for editing, summarisation, translation and document conversion.

• Names and roles.
• Dates, deadlines and sequence.
• Numbers, units and percentages.
• Optional versus compulsory actions.
• Promises, guarantees and disclaimers.
• Definitions and technical terms.
• Source-attributed opinions.
• Unresolved questions and uncertainty.

The protection list should be task-specific. Do not include every possible category if the source contains none of them.

Layer 4 — Receiver Design

The output should help a receiver perform the next job. A briefing for a manager might lead with decision, evidence and risk. A revision guide for a student might lead with concept, example, practice and self-check.

Specify what the receiver already knows when that matters. “For a reader who understands fractions but has not studied algebraic fractions” is more useful than a vague label such as “beginner”.

Receiver design can also specify accessibility: plain language, defined acronyms, shorter sections or a table for scanning.

Layer 5 — Evidence and Verification

Instructions become more reliable when the evidence path is part of the output. Ask for source links or identifiers where appropriate, calculation inputs, test results or citations to provided files.

Do not request evidence theatrically. A list of citations is not useful if nobody checks whether they support the claim. Design the output so verification is easy.

For example, a research table can include claim, source, date, supporting passage and limitation. A data analysis can include formula, numerator, denominator and interpretation.

Layer 6 — Failure and Action Boundaries

State what the system should do when it cannot complete the task: ask for missing information, return a partial result, flag a conflict or stop before an unauthorised action.

For connected tools, state which actions are allowed. “Read and propose; do not modify” is an operational instruction, not merely a style preference.

A strong workflow makes failure an expected state that can be handled, rather than a surprise the system tries to hide with plausible output.

Instruction Compression: How to Make a Long Prompt Shorter

Once a workflow works, simplify it. Remove repeated statements and decorative language. Combine constraints that express the same principle. Move stable background into a reusable project brief.

Keep the parts that protect known failure modes. If the system repeatedly invented unknown values until you added “return missing values as not stated”, that sentence has earned its place.

Compression improves maintainability. A prompt nobody can read is difficult to debug, share or update.

Instruction Expansion: When More Detail Is Justified

Expand when a failure shows that the current instruction leaves material ambiguity. Add a source hierarchy when versions conflict. Add output fields when downstream software requires them. Add examples when a subtle style boundary remains unclear.

Do not expand merely because the task is important. Important tasks need stronger evidence and review, not necessarily enormous prompts.

Instruction Testing With A/B Comparisons

To learn whether a change helps, compare two instructions on the same or comparable source. Keep the acceptance criteria fixed.

Example A says, “Summarise this notice.” Example B says, “Summarise for a parent; preserve date, time and materials; leave unstated details unknown.” Compare factual preservation, not which paragraph you personally prefer stylistically.

Repeat on more than one source before treating the result as stable. Generative systems can vary between runs.

Instruction Testing With Adversarial Cases

A robust instruction should survive cases that stress its key rule. If the prompt says to preserve unknowns, test a source with an important missing detail. If it says to protect modality, test a passage containing may, must, should and cannot.

Adversarial does not mean malicious. It means deliberately choosing examples likely to expose the weakness the instruction is supposed to control.

Instruction Testing With Fresh Cases

Do not evaluate only on examples used while designing the prompt. Keep fresh cases. If the system has repeatedly seen the correction for one notice, success on that notice says little about transfer.

Fresh testing is one of the main protections against overfitting your workflow to a demonstration.

How to Write Instructions for Summarisation

State the audience and purpose. Identify protected details. State the source boundary. Decide how to handle missing information and disagreements. Choose the desired length only after deciding what must survive.

A useful instruction might be: “Summarise these notes for a colleague joining the project. Preserve decisions, owners, deadlines and unresolved issues. Prefer later notes when they explicitly update earlier arrangements. Do not invent missing details. Use a short paragraph followed by four bullets.”

The check compares output with source, especially protected fields.

How to Write Instructions for Editing

Separate meaning from style. Extract commitments, conditions and facts before asking for tone changes.

Useful instruction: “Edit for clarity and a calm professional tone. Keep the deadline, eligibility conditions and refund language unchanged. Do not add promises, guarantees or facts not present in the source.”

Review meaning before grammar or polish.

How to Write Instructions for Research

Define the research question and source standard. Current questions may require current sources. Official-rule questions should prioritise official sources.

Useful instruction: “Find the current official source for X, then identify two high-quality secondary sources that explain the issue. Separate official requirements from commentary. State publication dates and unresolved disagreement.”

Research instructions should reward uncertainty when evidence is incomplete.

How to Write Instructions for Learning

Design for active learning. State what the learner should attempt before receiving help and what independent evidence will show understanding.

Useful instruction: “Do not solve the whole problem. Ask me to show my first step, diagnose the first error, explain that concept, then give me a new comparable problem to attempt without help.”

The output is a learning sequence rather than an answer.

How to Write Instructions for Brainstorming

Define the dimensions along which ideas should differ. Without this, the system may produce many near-duplicates.

Example: “Generate eight ways to teach this concept. Include at least one visual method, one physical analogy, one inquiry activity and one exam-practice method. Do not rank them yet.”

After divergence, use a second instruction for evaluation. Mixing ideation and selection too early can reduce variety.

How to Write Instructions for Decisions

State the options, criteria and known constraints. Keep factual comparison separate from preferences.

Example: “Compare Option A and B on cost, reversibility, implementation time and quality risk. List missing evidence. Do not select a winner; prepare the comparison for a human decision.”

This prevents the system from importing hidden values into the recommendation.

How to Write Instructions for Spreadsheets

Define sheet, columns, units and the intended calculation. Ask the system not to modify the source when only analysis is required.

Example: “Using columns B and C, calculate completion rate as completed ÷ assigned for each row. Flag missing or zero denominators. Return the formula and a result table. Do not alter the workbook.”

The instruction makes both arithmetic and operational boundary clear.

How to Write Instructions for Code

Scope the component. Provide language, interfaces, constraints and tests. Do not ask for a whole application when you need one function.

Example: “Implement parseDate(input: string) in TypeScript. Accept YYYY-MM-DD only. Return either a Date or a structured error. Include tests for valid input, invalid month, missing value and wrong format. Do not modify other files.”

The instruction creates a testable unit and protects surrounding code.

How to Write Instructions for Tool Use

List the allowed tools and the allowed actions. State which outputs require confirmation before external change.

Example: “Read the calendar and propose three times. Do not create or modify events. Return conflicts and the proposed slots for approval.”

Once approved, a separate instruction can authorise creation.

How to Write Instructions for Long Documents

Break the document into stages: map structure, identify relevant sections, extract evidence, then synthesise. Avoid asking for detailed analysis of a large document without defining what matters.

Ask for locators such as headings or page references when available. This makes later checking easier.

How to Write Instructions for Multiple Sources

Label each source and explain relationships. If Source B updates Source A, say so. If no source has priority, instruct the system to preserve disagreement.

A comparison output can include source, claim, agreement, conflict and unresolved issue. The structure itself helps prevent accidental blending.

How to Write Instructions for Structured Data

When a downstream system needs data, define field names, permitted values and missing-value behaviour. Avoid free-form prose around machine-readable output unless the receiver expects it.

Test invalid and absent fields. Structured output is only useful when the semantics of the structure are stable.

How to Write Instructions for Images

For image generation, define subject, composition, visual purpose, camera or viewpoint if relevant, lighting, background and constraints. If exact text or data representation matters, consider a deterministic graphic tool instead.

Review the generated image against the brief. Visual attractiveness does not guarantee factual accuracy.

How to Write Instructions for Presentations

Start from audience and takeaway. Define the narrative before slide count. Ask for evidence-backed claims and indicate which information should be visualised.

A useful presentation instruction separates content structure from design treatment. Check the factual content before polishing layout.

How to Write Instructions for Agents

State the goal, available tools, boundaries, completion condition and escalation rules. Avoid micromanaging every step if the agent needs flexibility.

Example: “Find the latest approved project brief in the authorised folder, extract unresolved actions and prepare a draft task list. Do not create tasks. If multiple documents appear equally current, stop and ask for clarification.”

This instruction gives freedom inside a controlled operating envelope.

A Prompt Refactoring Exercise

Take one long prompt from your current workflow. Highlight each sentence as task, context, constraint, output, evidence or action boundary. Sentences that fit no category may be decorative or redundant.

Remove redundancy. Group stable context into a reusable brief. Keep failure rules that protect real errors. Run the refactored version on the same test set.

If quality remains stable or improves, keep the shorter prompt. If an old failure returns, restore the protective rule.

An Instruction Handoff Exercise

Give your instruction to another authorised person without verbal explanation. Ask them what inputs they need, what result to expect and what errors to watch for.

If the answers depend on private knowledge in your head, improve the instruction or project brief. Reusable instructions should survive handoff.

An Instruction Maintenance Rule

Review important prompts after model or workflow changes. A rule that was necessary last year may become redundant; a new capability may introduce a different failure.

Keep a version note for critical workflow instructions. Test changes on representative cases before replacing the stable version.

The Instruction Floor for This SI Series

Every future instruction article in this curriculum follows the same standard: define the reader job, explain the mechanism, show weak and strong examples, include failure modes, provide transfer exercises and connect the instruction to verification.

This protects the series from becoming a list of prompt tricks. The goal is durable specification skill that survives changes in models and interfaces.

Better instructions are the interface between human intent and intelligent capability. When that interface is clear, the rest of the workflow becomes easier to reason about, test and improve.

Instruction Writing as an Error-Prevention System

The deepest purpose of an instruction is not merely to tell SI what to generate. It is to prevent predictable categories of error before they enter the output. A good instruction makes the dangerous ambiguity visible at the beginning instead of relying on a reviewer to discover it at the end.

For a summary, the dangerous ambiguity may be which details are essential. For an edit, it may be which commitments must remain unchanged. For data work, it may be which denominator defines the metric. For tool use, it may be whether the system is authorised to write or only read.

This is why good prompts often look different across tasks. The error-prevention layer is domain-specific even when the general communication principles are the same.

The Receiver-First Instruction Test

Before finalising an instruction, imagine the finished output in the hands of its receiver. What decision will they make? What action will they take? What misunderstanding would matter most?

Use the answers to shape the instruction. A parent reminder should preserve logistics and obligations. A manager brief should distinguish evidence, recommendation and unresolved risk. A student explanation should leave enough cognitive work for learning.

If the receiver cannot act correctly without reconstructing hidden context, the instruction is incomplete.

The Closure-First Instruction Test

Ask what observable state means the task is done. Without closure, the system may keep generating alternatives or adding analysis after the useful work is complete.

Examples of closure include: all required fields completed or explicitly marked missing; three distinct options compared on four criteria; one source-grounded summary checked against the document; all tests passing; a draft returned for approval without external action.

Closure also improves efficiency because it tells both human and system when to stop.

The Reversibility Test

For instructions involving tools, ask whether the action is easy to reverse. Drafting is more reversible than sending. Creating a proposed task list is more reversible than changing a production database.

Keep uncertain steps reversible for as long as practical. Use test environments, copies and approval gates. This makes experimentation safer and reduces the cost of instruction mistakes.

The Instruction Conflict Test

Read the prompt as if you were the system. Are there competing goals? “Be comprehensive but extremely brief.” “Use only the source but add expert context.” “Do not make assumptions but fill every field.”

Resolve conflicts explicitly. State priority or allow missing information. A model cannot reliably satisfy impossible instructions simply because the wording is forceful.

The Negative-Space Test

Strong instructions say what not to do only when the boundary matters. “Do not invent missing room numbers.” “Do not send the message.” “Do not alter other files.” These negative constraints protect known risks.

Avoid large generic lists of prohibited behaviours that have no relationship to the task. Too many irrelevant constraints make the instruction harder to maintain and can obscure the controls that actually matter.

A Final Instruction Examination

Choose a real recurring task and write the instruction from scratch using five fields: task, source, protected meaning, receiver and closure. Add a sixth field only if evidence, tool permission or failure behaviour requires it.

Run the instruction on one normal case and one difficult case. Preserve the outputs. Identify any failure. Modify only the relevant layer. Then run a fresh transfer case.

The instruction passes when another authorised user can understand it, the output meets the acceptance conditions on fresh material and known failure cases are either prevented or handled visibly.

At that point, save the instruction as part of a workflow. Do not call it perfect. Keep the test cases so future changes can be compared against the behaviour that earned your trust.

The Instruction Stack: Build From Purpose to Output

A strong instruction can be designed as a stack. Begin with purpose: what useful change should the work create? Add the task: what operation should SI perform? Add context: what information changes the answer? Add constraints: what must remain protected? Add output: what should the result look like? Add closure: what tells the system and the user that the job is complete?

The stack is not a mandatory template for every interaction. It is a diagnostic structure. When an output fails, ask which layer was missing. If the answer solved the wrong problem, purpose or task was unclear. If facts drifted, the source or protection layer was weak. If the output looked useful but could not be judged, closure was missing.

This approach is faster than adding random prompt decorations. Each instruction element should exist because it prevents a known ambiguity or helps the receiver use the result.

The Preservation Contract

Many instruction failures happen during transformation. The user asks for a friendlier email, simpler explanation or shorter summary, and the wording changes more than intended. A preservation contract states what may change and what must remain stable.

For an email, protected elements may include deadline, price, promise, person responsible and whether an action is optional. For a summary, protected elements may include numerical result, source uncertainty and qualification. For a lesson, protected elements may include the mathematical rule or scientific relationship being taught.

Write the preservation contract before the transformation: “You may simplify vocabulary and reorder sentences. Do not change names, dates, quantities, commitments or the distinction between confirmed and proposed arrangements.” This makes review substantially easier because the user knows what to inspect.

Instruction Priority: Tell the System What Matters Most

Complex tasks contain trade-offs. A short answer may conflict with completeness. A friendly tone may conflict with legal precision. A beginner explanation may conflict with technical detail. If all requirements are presented as equally absolute, the system may satisfy one by weakening another.

State priorities. For example: “Accuracy and preservation of the policy wording are more important than brevity. Keep the answer under 400 words if possible, but do not omit exceptions to meet the length target.”

Priorities also help human reviewers. When the result exceeds the preferred word count but preserves a critical exception, the reviewer can recognise that the workflow followed the intended hierarchy rather than treating every deviation as failure.

Instruction Design for Unknown Information

An instruction should specify what happens when the answer is not contained in the available evidence. Without this rule, fluent systems may fill gaps with plausible detail.

Use a missing-information policy: “If the source does not establish a value, write ‘not provided’ and list what information would be required to answer.” For research: “Distinguish verified facts from unresolved questions.” For data: “Do not calculate a rate if the required denominator is missing.”

This policy improves both accuracy and workflow design. Unknown is a valid state. A system that can stop at unknown is more useful than one that creates false completeness.

Instruction Design for Source Authority

When several sources are present, tell SI how authority should be interpreted. Recency alone may not determine authority. A signed agreement may outrank later informal notes. An official policy may outrank commentary. A teacher’s latest correction may supersede an older worksheet.

Write the rule when you know it: “Use the signed policy as the source of truth. Use the commentary only to explain context.” Or: “The Wednesday update supersedes Monday only where it explicitly changes the same arrangement.”

When authority is unknown, instruct the system to preserve the conflict. Do not ask it to invent a hierarchy that the real process has not established.

Instruction Design for Evidence

If the task is factual, specify the evidence standard. “Use current official sources for the eligibility requirements. Cite the passage or page that supports each important claim. If no authoritative source is found, say so.”

This instruction is stronger than “be accurate” because it defines a mechanism. Accuracy becomes linked to source traceability rather than tone or confidence.

For internal documents, evidence may mean filenames, headings, dates or line ranges. For calculations, evidence may mean visible inputs and reproducible operations. Match the evidence instruction to the kind of claim.

Instruction Design for Calculations

Numerical instructions should identify quantities and units. Instead of “calculate the improvement”, state the baseline, comparison period and formula when those choices matter. If the appropriate formula is part of the task, ask SI to propose it and justify the choice before calculating.

Include sanity checks: “Show the numerator and denominator. State the unit. Flag missing or incompatible values. Do not mix percentages with percentage points.”

A well-designed numerical instruction protects interpretation, not only arithmetic. The user should be able to reconstruct what the final number means.

Instruction Design for Learning

When the objective is learning, the instruction should preserve cognitive work for the learner. “Do not give the final answer yet. Ask one diagnostic question about the step where I stopped. After I respond, give feedback and then provide a comparable practice problem.”

This is different from an instruction optimised for task completion. The system is capable of completing the problem, but the instruction deliberately limits assistance because the receiver needs to develop the skill.

Learning instructions should also define the transfer check. Understanding during the explanation is not enough. Ask for a fresh example that the learner attempts without seeing the original solution.

Instruction Design for Research

A research instruction should separate question, scope, evidence and synthesis. Define the time period, population, geography and source types where relevant. Ask for disagreements or gaps instead of assuming one clean answer exists.

Example: “Investigate the current official requirements as of September 2026. Prioritise the responsible agency’s sources. Separate the rule itself from third-party interpretation. Note any unresolved conflict between current official pages.”

For broader research, ask for a source map before a long report. This lets you inspect the evidence architecture before prose hides weaknesses.

Instruction Design for Writing

Writing instructions benefit from four layers: audience, purpose, content constraints and style. Style should come last because tone cannot repair wrong content.

Instead of “write professionally”, state: “Write for a parent who has not seen the earlier conversation. The purpose is to confirm the new lesson time and what to bring. Preserve the date, time and materials exactly. Use warm, concise language.”

This helps SI understand what professional means in context: not abstract formality, but usable communication for a defined receiver.

Instruction Design for Editing

Editing requires a change budget. State which dimensions may change: grammar, sentence length, organisation, tone, vocabulary. State which dimensions may not: facts, claims, quotations, citations, commitments, technical meaning.

Ask for tracked explanations when the edit is consequential: “List any sentence where meaning changed rather than merely wording.” This gives the human reviewer a focused inspection path.

For large documents, edit in layers. First structure, then factual review, then style. A single “improve everything” instruction makes it difficult to know which change caused a new error.

Instruction Design for Coding

Code instructions should begin with specification and tests, not with a request for code. State inputs, outputs, environment, constraints, error behaviour and examples.

Example: “Write a Python function accepting a list of non-negative integers and returning the median. Raise ValueError on an empty list. Do not mutate the input. Provide tests for odd length, even length and empty input.”

When the code fails, give the error and the test case. Ask for the smallest repair. Avoid repeated full rewrites unless the architecture itself is wrong.

Instruction Design for Data Analysis

Define the unit of observation, columns, question and limitations. Ask SI to inspect missing values, units and inconsistent categories before analysis.

Example: “Each row is one order. Revenue is in SGD. Cancelled orders are marked in status. Calculate completed-order revenue by month, excluding cancelled orders. Show the number of excluded rows and flag months with missing revenue values.”

This makes the transformation auditable. The user can see what was excluded and why.

Instruction Design for Images

Visual instructions need subject, composition, purpose and constraints. “Create a diagram showing water moving through the water cycle, with clear labels for evaporation, condensation, precipitation and collection. Use a clean educational layout for a Secondary student.”

Then inspect the image itself. A good prompt does not guarantee correct labels or relationships. For factual diagrams, validation remains necessary.

If exact geometry, data scale or text placement matters, a diagramming or plotting tool may be more suitable than free-form image generation.

Instruction Design for Tools and External Actions

External actions should state the allowed scope and confirmation boundary. “Find three suitable meeting times from the calendar. Do not create or change any event.”

When action is authorised, specify the object and final validation: “Create the approved event at 3 pm on Friday for these named participants, then return the event details so I can verify the calendar record.”

The instruction must not confuse ability with authority. A connected tool may technically be able to do more than the current task permits.

Instruction Design for Long Tasks

For multi-stage work, define milestones. Research before drafting. Validate the data before drawing conclusions. Review the draft before publishing. Each milestone should produce an inspectable artifact.

This reduces error propagation. If the source map is weak, fix it before generating a twenty-page report. If the calculations are wrong, fix them before building charts and slides.

Long tasks become more reliable when checkpoints are part of the instruction architecture rather than improvised after something goes wrong.

Instruction Design for Teams

Team instructions should state source ownership and approval. If several people contribute documents, identify which version is authoritative and who resolves conflicts.

Use shared terminology. A term such as “final” should mean the same thing across the workflow. If “approved” has a formal organisational meaning, preserve it rather than letting SI infer approval from conversational language.

At handoff, state what changed, what remains unresolved and what action the next person is authorised to take.

Instruction Design for Reusable Workflows

A reusable instruction should be parameterised around stable structure. Separate fixed rules from variable inputs. Fixed rules may include source hierarchy, protected fields and verification. Variable inputs may include date, audience, source file and requested output.

This reduces the temptation to copy an old prompt containing stale details. The workflow becomes a template with clear inputs rather than a block of historical text.

Version reusable workflows when changes matter. Record why a rule was added, especially if it protects against a real past failure.

Instruction Design for Agents

Agent instructions need objective, tool boundaries, stop conditions and evidence of progress. Avoid goals so broad that the agent can interpret success arbitrarily.

For an open-ended research agent, specify source quality, date range, output artifacts and when to stop searching. For an action agent, define which tools can write, which changes require confirmation and what to do when a tool fails.

Greater autonomy makes instruction quality more important because errors can propagate through multiple steps before a human sees them.

Negative Instructions: Use Them for Boundaries, Not Everything

“Do not invent sources,” “do not change the deadline,” and “do not send the message” are useful because they protect important boundaries. But a prompt containing only prohibitions may leave the desired behaviour unclear.

Pair negative instructions with positive replacements. “Do not invent a room. If the room is missing, label it unconfirmed and list it under information needed.” This tells the system what to do instead of merely what to avoid.

Use negative constraints for known failure modes. Do not accumulate a giant blacklist of every mistake ever seen.

Instruction Hierarchy and Conflict Resolution

Long tasks can contain instructions at several levels: system or organisational rules, current user objective, source constraints and format preferences. Users should understand that some instructions may have higher priority than others.

Within your own task brief, make conflict resolution explicit. “Preserve factual accuracy even if that requires exceeding the preferred length.” “Do not change approved terminology to improve style.”

When two requirements genuinely cannot both be satisfied, ask the system to surface the conflict rather than pretending both were achieved.

Instruction Versioning

When an instruction becomes important to repeated work, give it a version and change log. The change log does not need to be elaborate. Record the failure that caused the revision and the new rule.

Example: Version 1.2 — added “unconfirmed details must remain unconfirmed” after a room number was invented in a meeting reminder. This history explains why the rule exists and protects it from casual deletion.

Periodically retest older cases to make sure new rules did not create regressions.

Instruction Compression

As a workflow matures, the prompt may become shorter because assumptions have been moved into stable structured context, tools or reusable instructions. This is healthy when the controls remain visible and testable.

Compression should remove redundancy, not meaning. Compare the shorter version against representative cases. If old failures return, restore the missing control.

The goal is the smallest complete instruction, not the shortest possible instruction.

Instruction Expansion

Sometimes the opposite is needed. A task becomes more consequential, the source set grows or a new tool is connected. Add the instructions required by the new responsibility.

Expansion should be modular. Add a source-authority rule because multiple sources now exist. Add an approval rule because a write tool was connected. Add a privacy rule because personal data entered the workflow.

This keeps the instruction architecture understandable as complexity grows.

A Detailed Worked Rewrite

Source: “We can review drafts submitted by Thursday. We may not return feedback before Monday. The final version is due Wednesday at noon.”

Weak request: “Make this friendly.” A possible failure is turning uncertainty into a promise: “Send your draft Thursday and we’ll reply by Monday.”

Stronger instruction: “Rewrite this for students in warm plain English. Preserve three meanings exactly: draft review is available for submissions by Thursday; feedback before Monday is not guaranteed; final submission is due Wednesday at noon. You may simplify wording and split sentences. Do not create any new promise.”

Review the result against the preservation contract before reviewing style. This order catches semantic errors early.

A Detailed Worked Research Instruction

Question: “What is the current official eligibility requirement?” Weak instruction: “Research this and tell me.”

Stronger instruction: “Find the current official eligibility requirements as of September 2026. Prioritise the responsible agency or programme owner. For each major requirement, identify the source and supporting passage. Separate official requirements from commentary. If official sources conflict, report the conflict and compare dates and scope rather than choosing silently.”

The improvement comes from evidence architecture, not decorative wording.

A Detailed Worked Learning Instruction

Student attempt: 4x + 7 = 31, and the student stops after subtracting seven to get 4x = 24.

Instruction: “Act as a tutor for this one step. Do not give the value of x yet. Ask one question that helps me decide what operation undoes multiplication by four. After I answer, tell me whether my reasoning is correct. Then give me a different equation of similar difficulty to solve independently.”

The instruction protects the learning objective by limiting assistance and requiring transfer.

A Detailed Worked Workflow Instruction

Task: convert meeting notes into an action brief. Instruction: “Use only the approved notes. Extract decisions, named owners, deadlines, proposals and unresolved questions. Do not convert tentative ideas into actions. Draft a brief for colleagues who did not attend. Before finalising, check every owner and date against the notes. Return the draft for human approval; do not send or create tasks.”

This instruction separates analysis, drafting, checking and action boundaries. It is already more than a one-shot prompt; it is a small workflow specification.

The Receiver Acceptance Test

After writing an instruction, imagine the output in the receiver’s hands. What must they be able to do next? If a parent needs to arrive at the correct time, the time is a protected field. If a manager needs to decide, evidence and trade-offs must be visible. If a student needs to learn, independent practice must remain.

Add only the instruction elements that support that receiver. This keeps prompts focused while preventing omissions that create downstream rework.

The Instruction Closure Test

Ask how the system knows the task is complete. A summary may be complete when all protected facts are represented. Research may be complete when the defined questions have supported answers or explicit unresolved states. A workflow may be complete when the artifact is produced and returned for approval.

Without closure, a task can drift into endless refinement. Explicit closure saves time and makes automation more predictable.

Instruction Maintenance

Review reusable instructions after important failures, source changes or tool changes. Do not update them merely because a new prompt trend appears.

Remove rules that no longer serve a meaningful failure. Keep rules that protect high-impact details. Test the revised instruction on old failure cases and fresh transfer cases.

A mature instruction library is small enough to understand and strong enough to preserve the essential controls.

A Better Instruction Checklist

• Can I state the job in one sentence?
• Is the receiver clear?
• Is the source of truth identified?
• Are protected facts or constraints explicit?
• Is missing information handled safely?
• Are priorities clear when requirements conflict?
• Is the desired output shape useful to the receiver?
• Is the evidence standard appropriate?
• Are external actions separated from drafting?
• Is there an observable completion condition?
• Can the important result be verified independently?
• Has the method been tested on a fresh example?

A Final Instruction Transfer Examination

Take a successful instruction and remove the names, dates and domain-specific nouns. Write the underlying structure in plain language. Then apply that structure to a new task in another domain.

If the instruction still works, you have learned a transferable design principle. If it fails, identify which assumption was specific to the original task and make that condition explicit.

The goal is not one universal master prompt. The goal is the ability to build the right instruction for the task in front of you.

The Five-Layer Instruction Model

A strong instruction can usually be understood through five layers: objective, context, constraints, output and check. You do not need to write these as formal headings every time, but separating them mentally prevents many common failures.

Objective

The objective describes the job. Use a clear verb: summarise, compare, rewrite, classify, calculate, explain, design, debug or extract. Avoid starting with a personality description when the actual task remains unclear.

Weak: “Be an amazing study coach.” Stronger: “Create five retrieval questions from these notes and wait for my answers before giving feedback.” The second instruction defines observable work.

Context

Context contains the information that changes the answer. It may include the source passage, audience, prior decisions, definitions or current state. More text is not automatically better context. Irrelevant detail can create competing cues.

OpenAI’s current prompting guidance recommends clear, specific prompts with sufficient context, while Google’s current prompt design documentation similarly emphasises precise instructions and structured context. Treat these as design principles, not rigid formulas.

Constraints

Constraints protect important boundaries. Examples include “use only the supplied source”, “do not invent missing values”, “preserve all deadlines”, “do not send the message” and “return no more than five items”.

A constraint should exist for a reason. Do not load the prompt with decorative restrictions that do not protect the task. Too many competing constraints make the instruction harder to follow and harder to debug.

Output

Specify the form when form matters. A reader may need a two-paragraph brief, a comparison table, JSON fields, a checklist or a draft email. Output structure reduces ambiguity and makes downstream checking easier.

The format should match the receiver. A manager may need decisions and risks. A student may need explanation plus practice. A software component may need stable field names rather than elegant prose.

Check

The instruction can include how the result should be checked: cite the source passage, preserve unknown values, show the calculation, list assumptions or flag contradictions. This does not replace independent verification, but it makes the expected evidence visible.

Write Instructions in the Order the Work Happens

Complex instructions become easier to follow when their sequence mirrors the real workflow. If the system must first extract facts, then compare them, then draft a message, state those stages in that order.

A common mistake is mixing final style instructions with source-analysis instructions in one dense paragraph. Break the process into stages when the intermediate result matters.

For example: “First extract confirmed decisions, owners and deadlines. Second list unresolved points. Third draft a concise meeting brief. Finally check the draft against the extracted facts.” The sequence creates internal checkpoints.

Use Examples When a Rule Is Hard to Describe

Examples are useful when the desired pattern is easier to show than explain. If you want a particular classification, provide one or two representative input-output pairs. If you want a tone boundary, show an acceptable sentence and one that is too informal.

OpenAI’s API prompting guide recommends articulating desired output formats through examples, and Google’s prompt design guidance also discusses using examples to shape behaviour. The key is representativeness: an example should illustrate the rule you want transferred.

Do not overload the instruction with many nearly identical examples. A small contrast set can be more informative: one good example, one failure and a short explanation of the difference.

Use Delimiters to Separate Instructions From Source Material

When prompts contain long source passages, make it visually obvious where instructions end and source material begins. Markdown headings, triple quotes or XML-style tags can all work when used consistently.

Example structure: “Task”, “Source”, “Constraints”, “Output”. The delimiter is not magic. It reduces ambiguity by making the roles of different text segments clear.

This becomes especially important when the source itself contains instructions. If you are summarising a document, text inside the document should normally be treated as content unless the workflow explicitly authorises it to control the system.

Instruction Hierarchy: What Happens When Rules Conflict

A prompt can fail because its own instructions conflict. “Use only the source” followed by “fill in any missing background from your knowledge” creates ambiguity. “Be concise” followed by “include every detail” may be impossible for a long source.

Before blaming the system, check the brief. Rank requirements. Which one protects factual correctness? Which is merely stylistic? If two constraints cannot both be satisfied, decide which one takes precedence.

For team workflows, document priority rules. Example: factual fidelity overrides tone; legal or policy constraints override convenience; explicit user approval is required before external write actions.

Positive Instructions Usually Beat Vague Negatives

“Do not be bad” gives almost no operational guidance. “Use only claims supported by the source and label missing information as unknown” tells the system what successful behaviour looks like.

Negative constraints are still useful when they block a specific failure: “Do not invent a room number” or “Do not send the draft.” Pair them with the desired alternative: “If the room is absent, write ‘room not confirmed’.”

This makes failure handling explicit rather than merely prohibitive.

Role Prompts: Useful, but Secondary to the Task

A role can provide useful perspective: “Act as an editor checking meaning preservation” or “Act as a tutor who asks one diagnostic question at a time.” Roles help when they specify behaviour relevant to the task.

A grandiose role such as “You are the greatest expert in the world” does not provide missing evidence, current data or professional authority. Treat role prompting as a framing tool, not a substitute for context and verification.

Use the narrowest role that changes the work. If the role adds no observable behaviour, remove it.

Long Context: Curate Before You Prompt

Long context creates a new problem: the system may have more information than the task needs. Old decisions, duplicate files and irrelevant conversation branches can compete with the current objective.

Build a current-state brief. Include objective, authoritative sources, latest decisions, constraints and unresolved questions. Archive background separately when it is not needed for the current task.

Google’s current Gemini prompting guidance recommends structuring long context clearly and anchoring the final request to the preceding information. Regardless of provider, the durable principle is to make the relationship between source material and requested operation explicit.

Few-Shot Prompting: Teach a Pattern Through Demonstrations

Few-shot prompting means providing a small number of examples that demonstrate the transformation you want. It is useful for classification, extraction, rewriting and structured formats.

Suppose you want to label project statements as Confirmed, Proposed or Unknown. Give examples: “Meeting is Friday → Confirmed”; “We could use Room 3 → Proposed”; “Room not stated → Unknown.” Then provide new statements.

Check transfer on wording that differs from the examples. If the system only recognises exact phrases, the demonstration set may be too narrow.

Structured Outputs: Make the Answer Easier to Check

Structure can improve reliability because each required field becomes visible. A meeting brief might use fields for Decision, Owner, Deadline, Source and Status.

When a value is missing, define the representation. Use “Unknown” or null rather than encouraging the system to fill the field with a plausible value.

Structured output is especially useful for downstream software, but the semantic content still requires checking. A perfectly formatted wrong value is still wrong.

Instruction Design for Research

A research instruction should define the question, time period, relevant population, preferred source type and what to do with conflicting evidence.

Weak: “Research whether remote work improves productivity.” Stronger: “Compare recent evidence on employee productivity in knowledge-work settings. Separate measured productivity from self-reported satisfaction, record study dates and populations, and identify disagreements.”

The stronger instruction does not decide the conclusion in advance. It defines the evidence categories and protects against mixing different outcomes.

Instruction Design for Writing

Writing instructions should separate meaning from style. First state the purpose and protected facts. Then specify audience, tone, length and structure.

Example: “Rewrite this parent notice in a calm, friendly tone. Preserve the exam date, arrival time and required materials exactly. Do not add promises or advice not present in the source.”

This protects the semantic layer before optimising the rhetorical layer.

Instruction Design for Learning

A learning instruction should preserve cognitive work. “Give me the answer” is appropriate for some reference tasks but weak for skill development.

Example: “I attempted this equation and reached 4x = 20. Ask me one question that helps me choose the next step. Do not give the final answer until I attempt it.”

Then add a transfer instruction: “After we finish, give me one different equation with the same underlying skill and do not show the solution unless I ask.”

Instruction Design for Data

Specify columns, units, missing-value rules and the question the calculation must answer. If a column contains percentages, clarify whether they are proportions, percentage points or formatted ratios.

Example: “Calculate attendance rate using registrations as the denominator. If registrations are missing, return ‘cannot calculate’ rather than inferring a total.”

The instruction protects both arithmetic and interpretation.

Instruction Design for Coding

A coding prompt should include expected behaviour, environment, constraints and tests. “Write a parser” is weaker than “Write a Python function that accepts ISO dates, rejects invalid dates and returns a timezone-aware object; include tests for leap day and malformed input.”

Ask for the smallest change when debugging existing code. Large rewrites can introduce unrelated regressions.

Generated code should still be run and reviewed. Prompt quality reduces ambiguity; it does not replace testing.

Instruction Design for Tool Use

When a system can call tools, specify when the tool should be used and what evidence of success matters. “Check the current value using the authorised source” is different from “answer from memory”.

For external actions, state the boundary: “Draft the event details but do not create the calendar event until I approve.” The instruction makes preparation and execution separate states.

After execution, require confirmation from the tool or destination rather than a conversational claim.

Iterative Refinement: Change the Prompt Because of Evidence

OpenAI’s current ChatGPT prompt guide describes prompting as iterative: start, review and refine. The important discipline is to refine based on an observed failure.

If the answer is too broad, narrow the scope. If it omits a required field, add the field. If it invents missing values, define unknown handling. If it ignores a source, separate source and instruction more clearly.

Avoid changing five variables at once. A targeted change teaches you which instruction mattered.

Prompt Debugging: A Failure Tree

• Wrong task → clarify the objective.
• Missing information → supply the required source or context.
• Source ignored → separate and label the source.
• Facts changed → add protected details and fidelity checks.
• Output inconsistent → define a structure or example.
• Too much irrelevant detail → remove context that does not change the answer.
• Tool not used → state the required current source or operation and confirm tool availability.
• Action exceeded scope → define permission and confirmation boundary.
• Good answer on one case only → test with fresh transfer examples.

The failure tree turns prompt engineering into diagnosis rather than superstition.

A Worked Rewrite Example

Source: “Parents may attend the briefing. Students must attend. Registration closes at noon on Monday. The venue will be confirmed later.”

Weak instruction: “Make this more professional.” A polished answer could easily blur who must attend or invent a venue.

Stronger instruction: “Rewrite this as a professional school notice. Preserve the difference between optional parent attendance and compulsory student attendance. Keep the Monday-noon registration deadline. State that the venue is not yet confirmed. Do not add any new logistics.”

Check the final text against the four protected facts. The instruction is better because it makes the acceptance standard visible.

A Worked Research Example

Question: “Has the organisation changed its eligibility requirements?” A good instruction begins by identifying the current authoritative source, not by asking for a free-form historical essay.

Use: “Find the organisation’s current official eligibility page. Record the page date if available. Compare it with the supplied older version. List explicit changes and leave unclear differences unresolved.”

The task now contains source priority, comparison logic and uncertainty handling.

A Worked Data Example

Data: 24 registrations, 18 attendees, 6 absences. Instruction: “Calculate attendance as a percentage of registrations. Show the formula and answer. Then state one limitation: this percentage does not by itself explain why people were absent.”

The formula is 18 ÷ 24 × 100 = 75%. The explanation protects the difference between calculation and causal interpretation.

A Worked Learning Example

Student work: 3x + 5 = 20 → 3x = 15. Instruction: “Ask me one question that helps me identify how to isolate x. Wait for my answer. If I am wrong, explain the balance principle using a different simple equation.”

This instruction controls pacing and protects the student’s opportunity to think.

A Worked Tool Example

Task: prepare a calendar event from a message. Instruction: “Extract proposed date, time, title and participants. Flag any missing information. Return a draft event object only. Do not create or send anything.”

After review, a separate approved instruction can perform the external action. The split reduces accidental overreach.

Instruction Patterns to Retire

“Make it better”

Replace with the specific dimension: clearer structure, simpler language, stronger evidence, shorter length or preserved meaning.

“Think harder”

If the problem is missing evidence or ambiguous requirements, more effort does not solve it. Define what additional analysis or check is needed.

“Be 100% accurate”

Accuracy is an outcome, not an operational instruction. Specify sources, calculations, constraints and verification.

“Use your knowledge”

For current or source-specific tasks, identify the actual evidence required. Model knowledge may be outdated or insufficient.

“Act as an expert”

Use a role only when it defines useful behaviour. Do not use role language to imply credentials, authority or access that the system does not possess.

A Prompt Quality Checklist

• Is the task explicit?
• Is the necessary context present?
• Are source and instruction clearly separated?
• Are important constraints observable?
• Does the output form match the receiver?
• Are unknown values handled explicitly?
• Are external actions bounded by permission?
• Is there a meaningful verification method?
• Can a failure be diagnosed without rewriting everything?
• Has the method been tested on a fresh example?

Frequently Asked Questions

Do longer prompts work better?

Not automatically. Add detail that changes the task or protects important boundaries. Remove repetition and irrelevant context.

Should instructions go at the beginning or end?

For ordinary prompts, placing the task clearly near the beginning is often helpful. For very long source contexts, some current provider guidance recommends putting the source first and anchoring the question clearly afterward. Use the structure that makes roles unambiguous for the model you are using.

Should I use examples?

Use examples when they clarify a pattern, format or boundary. Keep them representative and test transfer beyond the examples.

Should I tell SI to show all of its reasoning?

Ask for the explanation, evidence, calculation or concise rationale needed to evaluate the result. You do not need hidden internal reasoning in order to verify the important output.

Can a prompt eliminate hallucinations?

No prompt guarantees that. Source grounding, uncertainty handling and independent verification are stronger controls for important factual tasks.

What comes next?

Continue with How Prompting Super Intelligence Really Works, which explains the larger mechanism behind instructions, context, examples and iteration.

Good Instructions Make the Work Inspectable

The objective of instruction design is not to discover a secret incantation. It is to communicate a job clearly enough that the output can be evaluated and repaired.

As your SI skills grow, instructions may become shorter because the surrounding workflow becomes stronger. Sources are organised, checks are standardised and permissions are already defined.

Use the complete SI learning hub to continue. The next article moves from writing better instructions to understanding why prompting works at all.