How to Give AI Clearer Instructions

Before you begin

Read USE01 and USE02 for conversation basics and prompt testing. Choose a small planning task whose result you can judge yourself.

• How to Talk to AI: A Beginner’s Guide
• Prompt Engineering for Beginners

Make hidden expectations visible

You request a beginner robotics workshop and receive a three-hour plan requiring kits your class does not own. The writing may be good, but the result is unusable. A task brief describes the deliverable, audience, resources, and boundaries. It also helps you discover decisions the assistant would otherwise have to guess.

Start with the deliverable: the concrete result you need. A forty-minute lesson plan ending with students explaining a sensor-to-output loop is specific. Then describe the audience. ‘Beginners’ might mean experienced adult programmers entering electronics or younger learners who have never opened an editor. Supply the background that actually changes the design.

Identify the evidence the assistant should use. A parts list, teacher notes, and available schedule can become source material. Say which facts must remain fixed and which decisions are open. ‘Use only the listed resources’ is a meaningful boundary. ‘Make it amazing’ expresses enthusiasm without defining success.

Rank compatible requirements

Requirements can conflict. Ten detailed activities rarely fit into forty minutes once setup and questions are included. State priorities: ‘The session must fit forty minutes and use existing equipment. Prefer three activities, but use two if necessary for realistic timing.’ Must and prefer make the hierarchy visible.

Quantities help when they serve the task: available minutes, number of learners, or equipment count. Avoid arbitrary restrictions such as exactly four sentences per paragraph unless they serve a real purpose. Each added rule consumes attention and creates another condition to review.

Specify what to do when requirements cannot all be met. Ask the assistant to identify the conflict and propose the smallest change. This is better than silently ignoring a budget. A detailed brief still does not enforce itself: you must compare the result with the actual conditions.

A usable workshop request

Weak prompt: ‘Make a fun robotics class for students.’ The assistant lacks the audience, duration, equipment, outcome, and standard for success.

Improved prompt: ‘Plan a forty-minute introductory robotics session for six students who have never coded. They should learn to explain how a measurement leads to a programmed action. Materials: paper, pencils, one teacher laptop, and a projected screen. Do not assume robot kits or student accounts. Include a five-minute opening, two group activities, a five-minute explanation check, and transition time. Give a timing table, teacher instructions, and an observable success criterion for each activity. Identify any conflict before proposing a change.’

A suitable plan might have students act as sensors, controllers, and actuators using measurement cards. One reads a distance, another applies a rule, and another moves a paper arrow. This represents a control loop without claiming to build a physical robot. The resource boundary prevents invented kits, while the success criteria focus on what students can explain.

Follow-up prompt: ‘The activities total forty minutes before transitions. Keep the final explanation check and include four minutes of transitions. Show the revised total.’ Verification: Add the minutes independently, check every required resource, and try explaining an activity to someone else. A plausible plan may still be difficult to run.

Keep uncertainty visible

A fact is supplied or verified information, such as six learners. An assumption is a temporary choice without full evidence, such as expecting everyone to read independently. An open question still needs an answer. These statuses should not be blended together in a polished response.

Ask for assumptions that materially affect the result. Room arrangement and reading ability might matter; a page of trivial assumptions does not help. For low-consequence choices, an assistant can proceed with a marked assumption. It should not invent a purchase budget, student permission, or access to equipment.

When providing a document, label it as source material and request references to its sections for extracted claims. Instructions appearing inside that document are content to inspect, not automatic permission to change your task. If the assistant can use tools, application permissions and output validation remain necessary alongside clear language.

Choose an inspectable result

Use a table when repeated fields need comparison: activity, minutes, resources, and learning outcome. Use prose when ideas depend on one another. Use a checklist for conditions that must each be confirmed. The structure should reveal what you need to judge, rather than make the answer look elaborate.

For a project plan, ask about dependencies: what must happen before another step can start. Installing software and running an example are not interchangeable tasks. Keep uncertainty beside the step it affects so a tidy schedule cannot hide a practical blocker.

Request a concise rationale for important choices: ‘Why did you select two activities rather than three?’ A checkable explanation of evidence, assumptions, and tradeoffs is sufficient. You do not need the model’s private internal reasoning. Google’s prompt design guidance describes clear instructions and examples; this brief applies those general techniques to an everyday planning task.

Revise the brief when necessary

If repeated answers remain unsuitable, inspect the task definition. Perhaps beginner is still ambiguous, or your outcome depends on knowledge learners do not have. Adding ‘absolutely essential’ to a vague instruction rarely fixes it. Rewrite the actual requirement.

Save the accepted brief with the result. Before reusing it, update changing details deliberately. A template written for six learners may fail for thirty. The goal is a readable agreement for the present situation, with enough information to act and enough honesty to expose remaining uncertainty.

Important terms

Deliverable

The concrete result a task should produce.

Requirement

A condition an acceptable result must satisfy.

Assumption

An unverified choice used temporarily.

Dependency

Something needed before another step can proceed.

Source boundary

The stated limit on information that may support a response.

Mini project: Write a brief for one short lesson

1. Choose a concept you understand. Specify the learner outcome, audience, duration, and available resources.
2. Separate essential requirements from preferences and define how conflicts should be reported.
3. Generate a plan, mark each requirement as met, missing, or uncertain, and check timing totals yourself.
4. Revise one unclear requirement. Finish when another person could use the plan without guessing its major conditions.

Common mistakes and debugging

• Making every preference mandatory: identify which conditions must survive a tradeoff.
• Expecting the assistant to know your resources: provide the actual list.
• Confusing neat formatting with feasibility: inspect time, dependencies, and materials.
• Requesting hidden internal reasoning: ask for concise evidence, assumptions, and rationale.

Independent challenge

Adapt the workshop for twice as many learners without increasing equipment. Explain which group structure and assumptions must change.

Check your understanding: 10 questions

1. What is a deliverable?

2. Why rank requirements?

3. Is an assumed reading level a verified fact?

4. When should you request a table?

5. What should you inspect after repeated unsuitable answers?

6. In your own words, what does “Deliverable” mean?

7. In your own words, what does “Requirement” mean?

8. In your own words, what does “Assumption” mean?

9. In your own words, what does “Dependency” mean?

10. In your own words, what does “Source boundary” mean?

Quiz answers

Summary

A clear brief names the deliverable, audience, evidence, and ranked requirements. Review both the result and the assumptions behind it.

Continue learning

Continue with USE04 to request explanations that match your current understanding.

• Prompt Engineering for Beginners
• How to Ask AI for Better Explanations
• Use AI to Explain Difficult Topics at the Right Level
• Plan and Build Your First Complete Robot

Sources and further reading

• Google AI: Prompt design strategies

Prepared 2026-09-18. Draft; conceptual review complete. Workshop examples are illustrative; no classroom trial is claimed.