Module 4 · Advanced Strategies
2 min read · about 20 min lab
Builds: Your own prompt library

How to Write an AI System Instruction (System Prompt) That Holds Up

Write the standing instructions behind an assistant, and keep them within what a model can use well.

Key takeaway & what you'll build

A system instruction sets the standing rules for an assistant: who it is, what it does, what it won't do, and how it communicates. Write it like a job description with clear limits and refusal rules, keep it focused so it fits comfortably in the model's context, and test it with normal, edge, and should-refuse cases.

You'll build: Your own prompt library

The rules behind every reply

A system instruction (often called a system prompt) is the set of standing rules an assistant follows in every reply, before your message is even read. Every persona in Ace has one; that's what makes @Editor edit and @Copywriter write hooks.

A prompt says "do this now." A system instruction says "this is who you are and how you always work."

Five parts of a strong system instruction

Role and goal: who the assistant is and what success looks like. "You are the support assistant for a project-management app. Your goal is to solve the user's problem in as few messages as possible."
What it does: the tasks it's for.
What it doesn't do: the limits. "Don't discuss pricing changes; point users to the billing page."
How it communicates: tone, length, format. "Short answers, numbered steps for anything with more than two actions."
What to do when stuck: missing information, out-of-scope requests, uncertainty. "If you don't know, say so and offer to connect them with a person."

Limits and refusals

Write refusals as behaviour, not just bans: "If asked for medical advice, say you can't give it and suggest a doctor" gives the assistant something to do instead.

Context limits

Every model can only take in so much text at once, its context window, and everything counts towards it: the system instruction, the conversation, and any documents. Long chats and huge pastes crowd out the instructions. Keep system instructions focused (a few hundred words is usually plenty), put reference material in documents rather than the instruction, and start fresh chats for new tasks.

Testing

Test any system instruction with three kinds of message:

Normal: a typical request it should handle well
Edge: something ambiguous or with missing information
Should-refuse: something out of scope it must decline gracefully

Build one in Ace

In Ask Ace, open Personas → My Personas and create a persona. The steps (Identity, Role, Voice, Rules, Review) mirror the five parts above, and Ace writes a System instruction from them, which you can edit directly. Then add your persona to a chat and run your three tests.

Try it

Draft a system instruction for an assistant you'd actually use, then build it as a persona and run the three tests. The lab is next.

Hands-on lab

Design a System Instruction

Write a complete system instruction (about 200–400 words) for a specific assistant, defining its role and goal, what it does, its limits and refusal behaviour, how it communicates, and what it does when stuck. Write three test messages (a normal case, an edge case, and a should-refuse case), and explain why you included each part of the instruction. If you built it as a persona in Ask Ace, say how it handled the tests.

What the AI grader checks for

Role definition (25%): A clear, specific role and goal, with defined expertise, audience, and communication style.
Constraints and safety (25%): Includes concrete limits, what to do when information is missing, and refusal behaviour that tells the assistant what to do instead.
Test scenarios (25%): The three tests genuinely cover a normal case, an ambiguous edge case, and an out-of-scope request that should be refused.
Design rationale (25%): Explains the reasoning behind each part of the instruction.

Ask the AI course tutor

The tutor knows this whole course. Pick a question to start a conversation about this lesson.