A hundred and thirty-seven habits for the point where you stop asking and start directing.
By the second month the tool stops being something you use and starts being something you direct, and the questions change with it.
Not how do I ask for this, but why does the default look like that, what is actually changing the answer, why does everything sound the same at volume, and which decisions should never leave your hands at all.
A hundred and thirty-seven habits. More than anyone reads at once, which is the point — this is the one you come back to rather than the one you finish.
Ask a model to design something and it produces the average of everything it has seen, which is why so much of it looks the same.
The layout arrives centred, with a gradient, rounded corners and three weights of the same typeface. Nothing is wrong with it. Nothing is chosen either.
Twenty-four habits about why the default looks the way it does, and what to say instead of make it look better.
Check the size of headings and spaces on a full page, not only on a small example, before you use the design.
Models often make headings and spaces look good in small previews, but when the same style is used on a real page, everything grows too large. The result is a design that wastes space and looks odd.
Don't trust how headings look in a sample box, because the same size will be overwhelming in a real report or dashboard.
Set a clear maximum size for every heading, button, and text block before you finish the design.
If you only say 'keep it small', the model might shrink things for now, but any update or change can make everything big again. A fixed maximum is easy to check and keeps things under control.
Don't rely on reminders like 'keep it small', because those are forgotten and the next version might be huge again.
Check how much space each layer of boxes or containers adds up to, not only the space inside one box.
Each container adds its own padding or margin. When several are nested, the space multiplies, and you end up with big gaps you did not plan for. The total can be hundreds of wasted pixels.
Don't look at only the space in one container, because the layers together can add up to much more than you expect.
Check the contrast of every bit of text, especially grey text, before you use a design from a model.
Models often use low-contrast grey text because it looks stylish in isolation. On a real page, though, this is hard to read for most people, especially in poor lighting or on older screens.
Don't accept grey text that looks good in a preview, because on a real page, many people will struggle to read it.
Choose the text colour based on the background colour, not personal taste, every time you design a page.
Background colour affects how readable the text is. If you pick a text colour because you like it, without checking the combination, you can end up with unreadable or ugly results.
Don't pick a text colour because it looks nice in isolation, because it might clash or disappear on your actual background.
Make important words stand out by using size or bold, not by fading other text.
Fading text makes it hard to read, especially for people with less sharp eyesight or in dim rooms. Important information can disappear, so nobody notices it when they need to.
Don't use faded or light text to make other words stand out, because faded text is often missed or unreadable.
Click every button in the design, checking how each one looks and works when resting, hovered over, clicked, or disabled.
Buttons can change or even disappear depending on their state. Hovering or disabling can make a button fade, lose contrast, or become invisible, which leaves you unable to use or even find it.
Don't check buttons only when they are active. Ignoring hover or disabled states means you might miss when a button disappears or stops working for someone.
Use only style names that have been set and checked in the design system, so the tool can apply them correctly.
A style name not set anywhere can make text vanish. For example, white text on a white background disappears without warning, because the tool cannot find a matching style to use.
Don't type in style names that aren't set up. Guessing or inventing a style name can make your text invisible or look broken.
Check which style settings are already applied to your design before adding new colours, borders, or shapes.
Adding a new colour or shape that does not match the current ones makes the design look like it belongs to another app. The mismatch stands out and confuses people.
Don't add a new style before checking what's already set. Ignoring existing settings can lead to clashing looks and a messy page.
Pick a colour already in use in the design when you need a new one, instead of adding a new shade.
A single new shade stands out as a mistake. People spot an odd colour within seconds, because it breaks the visual pattern set by the rest of the design.
Don't add a fresh colour unless it matches one already used. A lone shade looks like an error and draws the eye for the wrong reason.
Check which styles are linked to a main colour before changing it, as the change will affect all connected headings and links.
Changing a root colour silently updates every style linked to it. All headings, links, and buttons using that style will change at once, even if you wanted to fix only one part.
Don't change the main colour without checking what else uses it. You might fix one problem but break everything that shares the same style.
Choose a single colour family to use on each page, and remove any colours that do not belong to that group.
Three bright colours on the same page compete for attention. The page looks unfinished and scattered. Sticking to one colour family makes the design calm and easy to follow.
Don't mix many colour families on a page. Using several bright colours together makes everything shout for attention and nothing feels settled.
Keep important text in a neutral colour, and use colour only for details such as links, navigation crumbs, or highlights that show structure.
Bright colours on main text or links pull your eyes away from what you came to read. Coloured tabs or focus rings, though, help you see where you are without making the main content harder to follow.
Don't colour all your links, headings, and main text. When every word stands out, you lose track of what matters and where you are on the page.
Make each button fit the length of its label, and arrange buttons in rows that wrap, not stretched across the page.
Buttons that fill the whole column look like someone rushed through a form layout. Rows of right-sized buttons look more deliberate, and help people spot what to click without guessing.
Don't make every button as wide as the screen. People will think the layout is unfinished, and it becomes harder to see which button does what.
Use vector icons, such as SVGs, inside shapes for buttons or labels, instead of using text symbols like arrows or stars.
Text symbols shift position on different browsers and devices, making it hard to centre them. Fixing those tiny shifts can take hours, especially when a project is nearly finished.
Putting text arrows or stars in buttons makes buttons look off-centre on some screens, and you might spend hours fixing alignment. A quick fix seems tempting, but icons or plain text work better in practice.
Check generated pages for repeated but slightly different style values, such as button curve, card spacing, or colours, across many files.
One project ended up with three different button curve sizes, four card spacings, and over 150 colours. No one chose these on purpose; they appeared as new files were added and copied.
Ignoring small differences in style values between files adds up, making your pages inconsistent and harder to maintain. It's easy to overlook minor changes, but they combine to create bigger problems.
Fix style drift by looking up and reusing old style values, not by adding new rules meant to be 'consistent'.
Adding a new rule for consistency, without checking what already exists, caused bugs in almost every file. Many went unnoticed, because no one opened all the files to see the problems.
Don't add new CSS rules for consistency without checking old ones. You might break layouts or cause hidden bugs in files you never open.
Use fewer decorative elements and colours, especially on design pages, to show you understand what matters.
When every part of a page is decorated, nothing stands out. People often think too much colour or decoration means the designer is inexperienced, especially when showing off design work.
Don't add lots of colours, gradients, or borders to show skill. Too much makes your work look cluttered and less professional.
Write numbers in plain text, without making them bold, so the natural contrast with words does the work.
Numbers already catch the eye because they look different from words. Making them bold removes this natural difference, so numbers blend in with headings or labels and lose their quick impact.
Highlighting numbers by making them bold makes them harder to spot and the page look noisy. You might think bold stands out, but it blends numbers into other bold text and distracts from key figures.
Add a label only when the content would be confusing or ambiguous without it; avoid stacking labels before the main information.
Too many labels before the real content slow people down. Readers start to ignore them, or worse, miss what matters. Labels should help, not create clutter or pretend to organise when they do not.
Labelling every single section, field, or button makes the screen feel heavy and hides what matters. Adding too many labels might seem helpful, but it drowns out the important ones users need to see.
Design buttons and controls that are used many times a day to be quiet and subtle, so they do not distract from the main task.
Obvious or brightly coloured buttons everywhere make it hard to focus. When the most-used controls fade into the background, people can work faster without being distracted by constant visual noise.
Making every frequently used button bright or large makes the screen busy and slows down finding what matters. Highlighting only the key actions helps users spot the right button quickly.
Design important actions so they are clear and easy to use, not by making them the biggest or loudest thing on the screen.
People trust actions that are easy to find and use, not ones that shout for attention. Size and colour can make something look risky or pushy, which makes people hesitate or miss it entirely.
A huge and red 'Submit' button for the payroll form draws too much attention and can make the action seem risky, which distracts people from their regular work and may cause hesitation.
Try all possible options for a setting before adding a control, to check if changing it actually helps or alters the result.
Some settings sound useful but only add confusion. If changing the setting never improves the outcome, a control wastes space and time. Only real testing shows which options are worth exposing.
Adding a slider for every possible setting in the image export for Asha_Presentation_2024.pdf can tempt you with flexibility, but too many sliders make the tool confusing and slow to use in real work.
Avoid setting a fixed lowest value for a setting unless there is a clear best minimum; leave the range open if no one value works for everyone.
A hard minimum blocks people from choosing what works for their situation. If there is no obvious best lowest value, setting a limit is one person's guess, which can stop better results.
Setting the minimum font size in the Anil_Invoice_Template.docx to 12 may seem like a safe default, but some users need it smaller, so a strict limit blocks valid use cases and causes frustration.
No score, and nothing to finish. Every wrong answer opens with why the wrong idea was tempting.
A screen is a hard constraint and a model has never held a phone.
The design reads beautifully in the reply and breaks at 390 pixels, because nothing in the conversation ever mentioned that most of the people reading it are on a phone in a corridor.
Twenty-four habits about what actually fits, what a thumb can reach, and why the mobile version is the design rather than a version of it.
Put all layout rules for mobile and desktop together in one CSS file, so you update and check everything in one place.
When layout rules live in separate files, changes in one are often forgotten in the other. Over time, layouts no longer match. Mistakes double, and you spend extra time fixing the same bug twice.
Don't split mobile and desktop layout rules into two files. Updates in one file often get missed in the other, so layouts drift apart and bugs multiply.
Store colour and font rules in their own section or file, separate from size and position rules for each layout group.
Colour and font choices should look the same everywhere, but layout changes by screen size. Mixing them means a change for one device accidentally changes others, making appearances inconsistent.
Don't mix colour and font rules with layout rules for each screen size. If you do, a font or colour tweak for one device can break how it looks on every other.
Show the same web page regardless of whether someone uses a phone, tablet, or computer, and switch layout based on the screen size, not the device.
Device type is unreliable because screens can be resized, rotated, or misidentified. Guessing device type leads to the wrong layout showing up on tablets, odd windows, or phones in landscape.
Don't serve different pages or layouts by checking the device type. Devices change shape, and pages will appear wrong when someone rotates or resizes their screen.
Decide which elements shrink, move, or hide when designing for phones; don’t only scale down the desktop layout.
Shrinking everything makes buttons too small, text unreadable, and controls overlap. Without clear rules for what changes, mobile layouts become crowded and hard to use.
Don't treat mobile layout as a smaller version of desktop. If you do, controls will crowd together, and users will struggle to tap or read anything.
Test your layout in narrow windows and on phones yourself, not only on a big screen, to catch broken layouts.
Desktop layouts can pass all checks while mobile layouts break. Narrow screens often show issues like sideways scrolling, cut-off text, or images that don’t fit, which go unnoticed unless you look.
Don't assume a layout that works on desktop is fine on mobile. Many problems only show up when you test in a small window or on an actual phone.
Use the viewport unit that updates as the visible screen changes, so layouts adapt when toolbars or address bars appear or disappear.
Old viewport units guess the screen size and ignore browser bars. When toolbars show or hide, layouts overflow or leave gaps, especially on mobile browsers, making pages look broken.
Don't use old viewport units like 100vh for mobile layouts. Toolbars can appear, causing the layout to overflow or hide content behind the address bar.
Add up the height of every part—headers, footers, toolbars, and content—before starting to arrange your layout on a phone screen.
Layouts break when the total height of all parts is more than the screen allows. People often miss a small piece, like a filter bar, and only notice after hours of shifting things around.
Don't guess or eyeball the sizes for each section, because missing even 10 pixels can push key controls offscreen and waste hours later.
Arrange every control—buttons, fields, and menus—so you can reach them all without scrolling, even on a small phone.
Hiding controls below the fold means people miss them, especially when in a hurry. On phones, scrolling for a button leads to mistakes and support calls about missing features.
Don't tuck important buttons or fields below a scroll area, since people will not know to look there and could miss deadlines.
Check that the whole page fits on the screen when no scrollbar is visible, instead of assuming hidden scrollbars mean nothing is cut off.
Some browsers or devices hide scrollbars by default, so content can spill offscreen without any sign. People then cannot reach hidden information, like Ajay missing the last step in a checklist.
Don't assume a missing scrollbar means everything fits. Content might be cut off and unreachable, causing confusion and missed actions.
Adjust the part that sticks out past the screen, such as a table or image, instead of shrinking the area that contains it.
Shrinking the container hides whatever sticks out, like a Submit button below a data grid. The top might look fine, but key actions disappear, causing people to get stuck.
Don't reduce the container size to hide overflow, since that buries important controls and makes them impossible to reach.
Keep the container’s height steady, even when items like messages or alerts appear or disappear, so the rest of the screen does not jump around.
When a container’s height changes, the layout shifts and people lose their place. For example, a warning message in the leave-approval form made the whole screen jump, causing Priya to click the wrong button.
Don't let the container resize itself every time a message pops in or out, since that makes the screen jump and confuses people.
Leave enough space for anything fixed to the screen edge, like a chat bar or notification banner, so it never covers up content underneath.
Edge-fixed items overlap content and hide parts of the page. For weeks, a settings section stayed hidden behind the always-on chat bubble in payroll-summary.docx, leading to repeated complaints.
Don't let fixed-edge controls overlap the main content, or people will miss important sections and get frustrated.
Set up sliding panels so they hover over your main content, without pushing or shrinking anything else on the screen.
A sliding panel that takes up layout space will squeeze lists, tables, or forms, making text unreadable and buttons hard to reach. The main area warps or jumps, which confuses people and disrupts their work.
A sliding panel that moves the rest of the page aside often breaks the layout, especially on small screens, so people end up with cramped content and a harder time finding what they need.
Give each parent container control over which child elements—like sticky bars or dropdown menus—should appear above or below others on the screen.
Dropdown menus or pop-outs can get trapped behind sticky headers or footers if you do not set the right order. People cannot see options, so they miss choices or make mistakes.
Sticky bars or floating buttons that can appear anywhere might seem convenient, but they sometimes cover pop-up menus or important controls, making it difficult for people to click or finish their tasks.
Place any third-party widget, such as a map or text editor, inside its own layer group so it cannot cover up your pop-ups or other panels.
External widgets sometimes ignore your site’s order of layers. A map or embedded editor can end up on top, blocking pop-ups or dialogs that need attention, so people cannot finish their tasks.
Adding a map or editor straight into the main layout might feel efficient, but these can spill over other content, hiding menus or dialogs right when you need them most during your work.
Use your own tooltip system for hints and help, instead of letting widgets show their built-in tooltips.
Built-in tooltips from widgets usually stick to the browser window, not your page layout. When you have a fixed header or sidebar, the tooltip can get stuck behind it and people never see the help.
Leaving the widget's default tooltip enabled can hide help text behind fixed headers or navigation bars, which means nobody finds the help they need when using your tool.
Change only the visibility of list items as someone types or filters, instead of rebuilding the whole list structure on every keystroke.
Rebuilding a long list with every letter typed makes the page flicker and resets scroll position. People lose their place, and the screen jumps, which slows down work and causes mistakes.
Refreshing or rebuilding the full list after every key press might seem responsive, but it causes the screen to flash and makes people lose their place, forcing them to scroll back repeatedly.
Always set the scroll position to the top when showing a reused page or panel, so people start from the beginning of the content.
If a panel or page is reused and keeps the last scroll position, the next person may land in the middle or end of the content, which looks broken and makes it hard to find what is needed.
Letting a reused panel open at the last scroll position confuses people, as it appears that content is missing or has been cut off, which can slow down their work.
Apply animation transitions only to the panel or area that is opening, not to both open and close states at the same time.
Animating both the opening and closing panels together causes them to overlap for a point. People see two panels at once, which looks confusing and makes it unclear which one is active.
Don't animate both the panel that is opening and the one that is closing. Overlapping panels for even a second can make people think something is broken.
Stop any timers or animation effects as soon as a view or panel is closed, so nothing keeps running in the background.
If a timer or animation keeps running after a view closes, it can move things around unexpectedly. Someone may have already moved on, so the page can shift and confuse them.
Don't let a loading spinner or animation keep running after closing the settings window. Background movement can shift the layout and distract people who are working elsewhere.
Show a placeholder shape that matches the real content while data is loading, instead of a blank screen or the word 'Loading'.
A blank page looks like a mistake or an empty screen. Showing a shape that matches the real content tells people something is coming and helps them recognise the layout.
Don't show a white screen or a line saying 'Loading...' when waiting for the sales chart. People might think the page is broken or has nothing to show.
Size cards, boxes, or content areas based on the largest real data items you have, not on guesses or samples.
If you guess sizes, long titles or descriptions can get cut off when the page goes live. Real data shows the biggest case, so nothing gets hidden or looks broken.
Don't set card sizes based on short test names. Real entries like 'Quarterly Revenue Breakdown: Marketing and Partnerships' might get cut off.
Give more space to the main content than to the page or section title, so people can read what matters most.
People come for the main text, not the label. If the title takes up too much space, the content feels cramped and harder to read.
Don't make the title of the 'Weekly Update' section bigger than the actual notes from Farhan. People need space to read the details.
Arrange important content so something useful always appears first, not empty space or blank areas at the top of the screen.
If the first thing people see is empty space, they may think nothing is happening and stop looking. Useful content at the top keeps attention and helps people find what they need.
Don't leave a big gap at the top of the report page. People might close it before they see the summary below.
No score, and nothing to finish. Every wrong answer opens with why the wrong idea was tempting.
By the second month the interesting question stops being how to ask and becomes what asking is doing.
The same request, sent twice, comes back differently. Not because the tool is unreliable, but because one version carried the situation and the other carried only the task.
Twenty-nine habits about the machinery underneath: what changes an answer, what only changes its length, and where the specification actually lives.
Set up the AI tool's controls or settings to limit what the AI can say, instead of asking for limits in your message.
AI tools ignore instructions hidden in the message, like 'only show code.' The system always adds some explanation or greeting, even if you ask for code only. Controls work, messages do not.
Don't write 'Only give me the code' in your prompt. The AI will still add extra words, so your output will not match what you want.
Check the form and format of your data before you show it to anyone or save it, making sure it matches exactly what you need.
Looking for a marker, like a tag, can let through long explanations that mention the tag but do not actually contain the correct data. Format checks block these mistakes.
Don't look for a keyword or a tag in the AI's answer and assume the data is ready. You might end up displaying a long paragraph instead of the actual data.
Keep any internal notes or plans the AI creates fully hidden from the user's screen, so only the final answer appears.
One time, the AI's planning notes were shown to everyone. The page filled with steps and drafts nobody needed, which confused the team and wasted time.
Don't display the AI's full internal thought process or planning steps. Users will see pages of confusing information they never asked for.
Show only error messages written by a person to users, never the raw error text made by the AI.
AI-generated error messages are often unclear or too simple, turning into one line that does not help. People need clear, useful messages, so use ones written by someone, not the AI.
Don't let the AI's error messages appear on the user's page. Most are too vague or unhelpful, causing confusion instead of solving the problem.
List every possible result the AI might give before you start, including all final answers and known errors.
If you do not know every result, unexpected answers or failures can slip through. You might get something you did not plan for, which could leak onto the page.
Don't start without writing down every output the AI could give. Missing one means you risk showing or saving something you did not expect.
Make sure the checks on what you send to the AI and what you accept back match exactly, so no answer slips through the cracks.
If the rules for sending and receiving are different, you get answers that can show up but never save, or junk that saves but never appears. Both break the process.
Don't use different checks for sending and receiving data. Mismatched rules mean you lose or wrongly keep information, causing errors in your workflow.
Delete information from your saved records after you make a big mistake, like uploading the wrong version of Q2_Report_2024.xlsx.
Any error you leave in your saved data will keep showing up in future results. Fixing settings or checks only helps new work, not what you already stored by mistake.
Don't assume correcting your prompt or settings will clean up old errors. Past mistakes remain in your files and can be used again without you noticing.
Describe how you want your answer to feel or behave, not the exact words you want to appear in the answer.
Mentioning a word in your instructions puts it in the system's memory, so the tool often repeats it. Repetition makes answers sound forced or artificial, which is not how people really work.
Telling the tool to use a specific word if you care about tone or mood can trap the answer into echoing your instruction, rather than producing a reply that matches your actual goal.
Avoid using broad or common phrases in your instructions, because they make answers too general.
Using fixed phrases leads the system to pull from average, bland examples, so the answers miss your specific situation and sound like every other reply, which is tempting but not helpful.
Adding words like 'best practice' or 'innovative solution' to your prompt can make the answer generic, which may seem safe but offers little help for your real work.
Stop using overused words in your file names, task names, and variable names, not only in your instructions.
Every name you give a file or task shapes what the system writes next. If you use tired words, the system keeps repeating them, making your work less clear and more repetitive.
Don't rename a task to 'Innovative_Strategy' and expect fresh ideas. The system will keep using the same language and patterns in its replies.
After banning an overused word, check your whole list for similar words before you write again.
Banning a tired word often leads your mind to pick a synonym without realising it. You might think you have fixed the problem, but the same dull pattern keeps slipping into your files and answers, even after the ban.
Don't swap 'effective' for 'efficient' and move on. Both are overused, and your answers will still sound generic.
Limit the words you use, but keep the topic the same. Don't change what you are asking about.
Choosing different words is a skill. If you change the topic to avoid a banned word, you stop solving the real problem and miss what your task needs.
Don't avoid writing about risk in RiskRegister2024.xlsx by switching to another subject. You need to address the real topic, with better words.
Write any limits or restrictions at the end of your prompt, and tag them as never to say or do.
Systems process instructions in order, giving the end the most weight. Limits buried in the middle often get ignored, so putting them last ensures the system remembers and follows them.
Don't put your never-to-say list or limits in the middle of your prompt, as the system may miss or override them by later instructions.
Keep instructions short and clear, since long prompts hide important details in the middle.
Long instructions cause the system to focus on the beginning and end, often missing or misapplying details in the middle. Short, direct prompts make each rule more likely to be followed.
Don't write a long block of instructions with important rules in the middle, as those are likely to be skipped or misread by the system.
If you have a condition, write two separate prompts and choose one before you start.
Conditional statements like 'if this, then that' get confused with similar words or partial matches, leading to ignored or misapplied instructions. Deciding which prompt to use before asking avoids this problem.
Don't include soft if-then statements in your prompt, as the system may not handle them correctly or may mix up the conditions.
Write a separate prompt for each task, instead of combining all instructions into one.
Combining tasks in one prompt causes instructions to overlap and conflict, making it hard for the system to follow each rule. Separate prompts keep tasks clear and prevent confusion.
Don't ask for everything in one prompt, as it creates conflicts and muddled results.
Ask for each item separately with a simple, direct request. Don’t add more rules to try to get variety.
Adding more rules makes the system follow a new, blended pattern, not more variety. Short, focused requests for each item create more natural and different responses.
Don't pile on extra rules hoping for variety, as the system will create a new, repetitive style instead.
Show real examples from actual work, like a file or conversation, instead of describing what to do in general terms.
The system learns best by copying real moments. Vague or general instructions lead to bland, repetitive results. Real examples show exactly how to act in practical situations.
Don't explain the task in the abstract or with made-up situations, as this leads to generic, lifeless answers.
Give two clear, detailed examples of your answer using real files or tasks, not more or less.
When you see only two examples, your mind can compare them and notice the style. More than two makes it hard to keep track, and the main point gets lost in the crowd.
Don't add four or five examples thinking more is better. Too many examples blur the pattern, and you end up copying the wrong parts or missing the main idea.
Check every example for mistakes before sharing, and leave out any you are not sure about.
Mistakes in examples get copied into your own work, even if you know better. A bad example sticks in your mind, and you repeat the error without noticing.
Don't include an example you think is 'close enough' or 'probably fine.' Even a small error will be repeated, and you will end up fixing the same mistake later.
Ask for the finished answer first, then ask for the steps or explanation after.
When you see the final answer before the steps, you know if it fits your needs. If you ask for the process first, you might get lost in details, and the answer could drift away from your goal.
Don't ask for the steps before you see the answer. Starting with the process makes it easier to lose track of what you needed, and the reply can go off course.
Ask the tool to show its thinking or calculation, especially if you need high accuracy.
If you only see the answer, you cannot check how it got there. When the tool explains its thinking, you can spot mistakes or steps that do not fit your needs.
Don't hide the steps by asking for only the result. If the answer is wrong, you will not know where it went off track, and fixing it takes longer.
Tell the tool to check its answer against your rules or criteria, and show the check out loud.
When the tool reviews its own answer, it often catches mistakes before you see them. Hearing the check helps you spot anything missed, and you can trust the result more.
Don't skip the review step. If you only look at the answer, you might miss errors that the tool could have caught by checking its own work.
State the exact number of items you want in each list or slot, and match it to your template.
If you do not say how many items you want, the tool might guess and give too few or too many. The count can change each time, making your work inconsistent.
Don't leave the number open or vague. If you say 'several' or 'a few,' you will get a different number each time, and your template will not line up.
Ask the model for help with tasks where repeating patterns or summarising is useful, but do not expect it to understand feelings or reasons like a colleague would.
A model repeats patterns from its training or sources. The tool does not understand context, feelings, or reasons. Answers come from matching words and phrases it has seen before, not thinking or understanding like a person.
Don't expect the model to explain why Raj chose the new supplier in his report. The model will copy phrases from the text, not explain Raj's actual thinking.
Keep the source text or summary away from the model if you want a fresh answer. Only share data, facts, or an outline for the model to work with.
When the model sees original text or a summary, it copies words and phrases from it. Giving only facts or an outline forces the tool to create new sentences and ideas, avoiding direct copying.
Don't paste the project brief into the model and ask for a new version. The model will repeat lines from the brief, so the result is not original.
Tell the model to 'recall' if you want real examples it has seen, or to 'generate' if you want it to make up new examples.
When the tool is told to generate, it invents details that sound real, but are made up. When told to recall, it tries to pull examples from its training or the data given, not inventing anything.
Don't ask the model to 'generate' a client feedback example for the Q2 report if you need a real one. The model will make up a believable quote, not find an actual client comment.
Update your request if you want better answers, but remember old saved answers will not change. Only new answers use the improved request.
Changing the prompt helps future replies, but any answers already created stay the same. Old mistakes or missing details remain in those saved responses, even if the new prompt is better.
The updated prompt will not change the answers you already saved for the HR_Policy_Review.docx task. Any old answers will still appear in your results, so you may need to update them by hand.
Use a script or spreadsheet for simple tasks like sorting, counting, or matching; let the model handle decisions or creative work.
Scripts and spreadsheets run fast and cost nothing for basic actions. The model is slower and can make mistakes with exact tasks, so use it for things that need judgement, not basic chores.
Don't ask the model to sort the list of invoice numbers in Invoice_Archive.csv. The model may miss details, and a script does it faster and more accurately.
No score, and nothing to finish. Every wrong answer opens with why the wrong idea was tempting.
Left alone, a model writes to the middle of everything it has read, and the middle is where nothing is memorable.
Fifty items come back and each one reads fine. Read together, every one opens the same way, runs the same length and lands the same beat.
Eighteen habits about sameness at volume, and why more instructions make it worse rather than better.
Ask for one entry for each different item by making the instructions clear, so every unique thing gets its own line in the list.
When instructions are vague, the tool might list every time a word appears, so you end up with several identical entries. Later, you have to clean up the mess, which wastes time and causes confusion.
Don't say 'List all the words in the document,' because the tool might repeat 'summary' three times if it shows up three times, which is not helpful.
Remove repeated items from the list before you show the result, so each item only appears once.
When repeated items stay hidden inside the list, they can sneak back in later when you use the list for something else, like sending emails or making a chart. Problems show up when you least expect them.
Don't hide repeats only on the screen, because the duplicates are still in the list and will cause trouble if you use the list for another step.
If two answers both seem right, rewrite the question so only one answer fits, even for someone who knows the topic well.
When a question could have more than one correct answer, even experts will disagree. The question doesn't work, because the answer depends on guessing what the writer meant, not what is actually true.
Don't leave a question as it is if two answers could be picked by a knowledgeable person, because this will always cause arguments or confusion.
Make sure all answer choices are the same kind of thing, like all single words or all full sentences, so nobody guesses by the shape.
When answer choices mix phrases with single words, people can spot the odd one out or guess without understanding the meaning. The question becomes a puzzle about form, not about the content.
Don't mix answer types, like using 'office' and 'works from home on Fridays' in the same list, because the difference is obvious and not about knowledge.
Write wrong answer choices somebody could actually pick, so the question is a real test rather than a formality.
When wrong answers are silly or impossible, nobody gets confused by them. The question doesn't help learning, because you only have to spot the joke, not know the right answer.
Don't add obviously wrong options like 'banana' for a list of cities, because these don't challenge anyone and waste space.
Write each question so it makes sense on its own, without needing to read anything before or after it.
When a question only makes sense with the nearby text, it gets confusing if someone sees it somewhere else. The question loses meaning and cannot be reused in a new place.
Don't write questions that rely on the previous paragraph, because they won't work when moved or reused in a different context.
Point out the exact mistake in the answer and explain why it is wrong, using clear language.
When feedback only says 'good job' or 'try again', you do not know what to fix. Naming the specific mistake and explaining why it matters helps you avoid repeating the same error.
Don't give vague feedback like 'incorrect' or 'try again', because it leaves you confused about what went wrong and how to improve.
Match your feedback to the exact wrong answer given, so the reply always fits what you actually did.
When you get generic feedback that does not mention your specific mistake, it feels like no one checked what you did. You might repeat mistakes, thinking something else was wrong.
Don't send the same error message for every wrong answer, because it makes you feel like your effort does not matter and you do not learn what to fix.
If the answer is missing, do not make up a fake example or repeat a hint that does not fit the situation.
When you see a hint that does not match what you did, you get confused. Repeated, unfitting hints make it harder to understand what actually needs to be changed.
Don't reuse the same hint or invent a wrong answer when you do not know what happened, because it will mislead and frustrate you.
Never use the first example's data as a default answer in later examples, so each answer stays accurate.
When the same example data appears in every answer, you start to ignore it. Later answers become wrong, and you lose trust in the tool.
Don't copy the first example's answer into every later example, because it makes all the other answers incorrect and confusing.
Set a clear limit for how much text can go in a box, and make sure the box is never almost full when you start typing.
When a text area is nearly full from the start, any new text makes it overflow. Scroll bars jump around, and you might think the tool is broken.
Don't let the text area start with so much text that adding one word makes it scroll, because it looks broken and is annoying to use.
Keep every paragraph short, so it's easy to read on a phone without scrolling through long blocks of text.
Long paragraphs fill the screen with lines that are hard to track on a narrow display. You lose your place and miss the main idea.
Don't write one long paragraph for everything, because it makes reading on a phone difficult and tiring.
Ask the tool to explain its answers in plain English, so you can understand without needing technical knowledge.
A machine prefers information packed tightly, because other machines process it that way. People need information unpacked and clear, or they feel confused and left out, especially if English is not their first language.
Don't let the tool reply in technical jargon or dense language, because that makes you spend extra time figuring out what it means and you risk misunderstanding the answer.
Introduce hard words by explaining them in simple terms first, before using them in your instructions or questions.
When a new or complicated word appears without explanation, readers pause or stop. Giving a simple explanation first lets you follow along, even if you have never seen the word before.
Do not use a technical word like 'concatenate' without first saying it means 'join together', or people may miss the meaning and get lost in the steps.
Leave out information the reader already knows, and focus on sharing new and useful details each time you answer.
When you get information you already expect, your mind tunes out. Only new or surprising details keep your attention and help you learn something you did not know before.
Don't repeat obvious facts, like 'click Save to save your file', when everyone already knows that part, or your answer feels empty and wastes time.
Use examples with real names, files, or situations from everyday work to make your explanation clear and memorable.
A specific situation, like 'Priya missed the 5pm deadline for 'client_notes.docx'', sticks in your mind. General rules fade fast, but real stories connect to your own experience.
Don't use generic examples like 'a document' or 'an employee', because these feel distant and hard to picture, making it more difficult to remember the point.
Explain the reasons behind each step, not only what happens, so you understand how things work and not what to do.
When you only hear what button to press, you might follow along but forget later. Explaining why something works a certain way helps you remember and apply the idea in new situations.
Don't list instructions without reasons, like 'click here, then here', or you will not know what to do when the screen changes or something goes wrong.
Leave out any part you are not sure about, instead of guessing or including wrong information in your answer.
Missing information is obvious and can be fixed by asking again. Wrong information is believed, shared with others, and causes mistakes that are harder to spot and correct later.
Don't guess at what a button does or invent a step, because someone may trust your answer and end up making an error that is hard to undo.
No score, and nothing to finish. Every wrong answer opens with why the wrong idea was tempting.
Most of what goes wrong with data is not the analysis. The problem is not knowing which version is real.
Two spreadsheets, one name, three days apart. The answer is correct for whichever one was handed over, and nobody checked which that was.
Twelve habits about shape, source and freshness — knowing what a thing is before asking anything of it.
Use a unique ID number or code to identify each item in your data, not the name or label.
When two people in the team share the same name, the system cannot tell them apart. The wrong record gets picked, and nobody notices until something goes wrong—like sending Priya Sharma’s pay slip to the wrong Priya.
Don't use names, email addresses, or job titles as identifiers. People can share these, change them, or misspell them, which leads the system to mix up their records.
Check which file or system holds the official value for each piece of information before you update or use it.
When the same detail, like a phone number, lives in both the HR spreadsheet and the office directory, one copy often gets out of date. People grab the wrong one, and messages go to the wrong place.
Don't assume the first copy you find is correct. Different files may have different versions, and the one you use might be old or wrong.
Decide what type of unique ID you will use for each item before you start building your data files or system.
When you mix up which ID belongs to which kind of data, or change your mind after starting, records get lost or mismatched. People’s details can end up orphaned or linked to the wrong person.
Don't start entering data without a clear ID plan. Changing IDs later breaks links between files and loses people’s information.
Add a prefix or tag to each ID when you import data from another file, not inside the original source file.
When two files both use ‘001’ for different people, importing them together creates a clash. Tagging IDs as they arrive keeps each record unique without changing the original files.
Don't edit the original files to add prefixes. Changing source data can break other systems that rely on it and makes mistakes hard to track.
Keep large sets of data in separate files by type, but use the same unique ID to connect records across them.
When all data types are merged into one huge file, the file becomes slow, hard to search, and easy to break. Keeping types apart but linked by a common ID makes updates and checks much easier.
Don't put every detail—contacts, projects, hours, payments—into one spreadsheet. Large, mixed files are hard to manage and prone to errors.
Set up automatic checks in the tool or form that creates your data to catch missing or wrong values before saving.
When data gets entered without checks, mistakes like missing dates or wrong totals slip through. Errors such as these only come to light later, after the records have spread to other files and systems.
Don't wait until the final report to find missing or wrong fields. Early errors are much harder to fix once they spread.
Check every quoted phrase or sentence in your document to make sure it actually appears where the tool says it does.
A single character missing from a quoted phrase can break the connection, so the reference link disappears and the feature does not work. The tool gives no warning, so nobody knows why it failed.
Don't copy a phrase from memory or guess what was written, because a missing comma or word means the tool cannot find it and the link fails without notice.
Make the tool show a clear error message when something it needs is missing, instead of hiding the problem or continuing silently.
When a part is missing but the tool stays quiet, people think the feature is broken or buggy. Hours get wasted looking for a bug that is really a missing file or piece.
Don't let the tool skip over missing files or data without any message, because people will not know what went wrong and will spend days searching for a fix.
Save common search results once on the main server so everyone can use them, instead of making each person run the same search separately.
Running the same search for every person uses up the computer’s time and power over and over. The results are the same, but the work is repeated for no reason.
Don't let each person run the same search for 'weekly_sales.xlsx' on their own, or the server will slow down and waste energy.
Get answers for the most common questions ready ahead of time, and only make people wait for answers to unusual questions.
Most people ask the same questions, so having those answers ready saves time. Unusual questions are rare and do not slow things down much if they take longer.
Don't treat every question as new, or people will wait for answers to things like 'latest leave policy' that could be ready instantly.
Move your data into a real database before your file, like 'contacts_list.csv', gets so large that opening it becomes slow or fails.
Big files take longer and longer to load as they grow. By the time you notice, opening or searching the file is already slow or broken, which stops your work.
Don't keep adding names to 'contacts_list.csv' forever, because once it gets huge, the file will not open or search quickly enough to use.
Set up searches to look for the meaning of what you ask, not only exact words, so you find ideas even if the words are different.
Searching for exact matches misses files that use different words for the same idea. People waste time looking for something that is there, but written another way.
Don't search only for 'annual review' if the document uses 'yearly appraisal', or you will miss what you need and spend extra time looking.
No score, and nothing to finish. Every wrong answer opens with why the wrong idea was tempting.
Judgment is the part that does not transfer, and the part worth protecting.
The recommendation is well argued and confidently wrong, and the reason it is wrong is something you know and the model could not.
Eighteen habits about what stays yours: the decision, the check that carries consequence, and the line between advising and acting.
Describe the full range of work, not only a single summary number, when sharing what the tool covers.
A single number, like '500 templates', hides the variety and complexity inside. People may miss important details or think everything fits into one small box. Work done over centuries cannot be shown by a tidy label.
Don't reduce a wide field to a count or single label. People will not see the real size, and may ignore what is missing or unique.
Use lists for things you can fully name, like file types. For bigger groups, like stories or tones, provide a way to create new ones.
Closed sets can be listed because all items are known. Open sets, such as creative ideas or writing styles, keep growing. A list alone cannot cover every possibility, so people need a way to add or make new options.
Don't try to make one giant list for ideas or styles. People will think the list is complete and miss out on new or custom choices.
Check if a template or file already exists before asking the tool to create a new one.
Duplicate work happens when people do not look for existing resources. Time and effort are wasted making what is already there, like buying more apples when the basket is already full.
Don't ask the tool to make something from scratch without searching first. You may end up with two copies or miss a better version.
Estimate time for tasks based on how fast the tool works, not how long people usually take.
People often guess time using their own pace, but the tool may finish much faster. Wrong estimates can ruin schedules, like planning a race with the wrong distance.
Don't plan using human speed for tasks the tool can do in seconds. You risk missing deadlines or wasting time.
Describe what the tool will include or change in a task, not only how long it will take.
Time alone does not explain what is being done. If you only hear 'a month', you cannot tell what is new or reused. Plans become guesses, like picking a box without knowing what is inside.
Don't say only how long something will take. People need to know what is included so they can plan or check the results.
Fix the real problem in a process or file, not only cover it up with retries or warnings.
Temporary fixes, like retries or warnings, hide faults instead of solving them. Problems may grow unseen, like a pipe leaking behind tape, until they cause bigger trouble later.
Don't rely on retries or error messages to handle faults. The real issue stays hidden and may get worse.
Stop and rethink your idea if two different prompts fail to make the right picture for the same project, such as the 'Q3 Invoice Cover' for Rajesh.
Repeating the same idea with small changes usually leads to the same wrong result. The shapes and plan are the problem, not the specific wording. A new approach with a different image often works quickly.
Tweaking the same prompt over and over for the 'Q3 Invoice Cover' wastes time and energy when the idea itself is what is not working.
Switch your approach if your first picture looks like something you did not want, such as a 'cake' when you needed a 'pie' for 'Finance Report Chart'.
The first shapes chosen guide the picture’s meaning. If the result is off, changing small details or softening features will not make it say the right thing. Starting again with a new plan works better.
Editing a picture that looks wrong for 'Finance Report Chart' only makes a bad fit look slightly different, not correct.
Check real, successful examples before making more pictures, especially if the first two tries for 'Team Roster Slide' did not work.
Planning based only on file names or titles misses what actually works. Looking at finished, good examples shows what details and style succeed, so your next attempt is based on proof, not guesswork.
Making a third 'Team Roster Slide' based on your memory of the name repeats the mistake of not learning from what has actually worked.
Use a picture or symbol from your own checked folder for 'HR Policy Update' before searching for a new one online.
A matching symbol in your own collection is already checked for style and meaning. Skipping it for a general one wastes time and risks using something that does not fit your team's way of working.
Grabbing a random symbol from the web for 'HR Policy Update' when you have a matching one saved ignores your own quality-checked collection.
Figure out why the first batch of 'Product Launch Posters' failed before resizing or making changes for the next try.
Guessing at the problem and trying again without understanding wastes budget and damages trust. The same mistake is likely to happen if you do not know what went wrong the first time.
Resizing and re-sending 'Product Launch Posters' right after a failed batch repeats the error and wastes resources.
Pick the right AI model for your task, such as 'Presentation Slides', and try the lowest-cost capable one first.
Some jobs need more capable models, but not always the biggest or most expensive. On one task, a well-chosen model was much cheaper and faster than the smaller ones, with no drop in quality.
Starting with the smallest or most expensive model for 'Presentation Slides' every time can waste time or money if another model is a better fit.
Check early whether the AI tool can handle the type of task you want, like reading a scanned invoice or analysing a chart.
Many AI models have hard limits, such as not being able to read handwriting or extract information from complex diagrams. You notice these gaps before you rely on the tool, avoiding wasted effort.
Don't assume the system can handle every file, or you might build a process that fails at the first step.
Before starting a large job, confirm agreement on the task, test a small sample, get approval, and check the cost with your manager or team.
Skipping one of these steps often means doing a lot of work that nobody wants, or that costs too much, or that fails basic checks. Early checks save time and budget.
Don't run a full batch before showing a test or checking the price, or you risk wasted budget and time.
Treat the checking tool as a way to review results, not as the final work you deliver to your colleague or manager.
Spending time making the review tool look perfect blurs the line between draft and finished work. Colleagues may confuse a preview for the final product, leading to mistakes.
Don't polish the review screen as if it is the final report, or people will use the wrong output.
Reuse old prompts or templates only if they fit exactly what your colleague needs to do today.
Copying a pattern because it is available or easy leads to results that might work, but do not help with the real task. The output ends up generic and not useful.
Don't grab a template from last month for a new project unless the work matches, or your results will be off-topic.
Keep the technical method hidden behind the scenes; show only clear controls for the result your colleague wants.
Labels or buttons that reveal the technical method confuse people who are not interested in how it works. Controls should focus on what the person wants to achieve, not how the tool does it.
Don't label buttons with code names or method types, or people will get lost in details they do not need.
Show your colleague what each control or message is for, not hidden codes, step numbers, or internal labels.
Stage numbers or internal codes make the tool feel unfinished and unprofessional when people see them. Removing these is easy and helps make the tool clearer and more trustworthy.
Don't display 'Step 3: 04B_Tokenise' or similar codes, or your colleague will be confused and think the tool is not ready.
No score, and nothing to finish. Every wrong answer opens with why the wrong idea was tempting.
Everything above is worth nothing if it lives in your memory and nowhere else.
You learn something on a Tuesday, apply it beautifully, and meet the same problem in six weeks having forgotten which of the four things you tried was the one that worked.
Twelve habits about where a rule has to live to be honoured, and why anything that must never be violated cannot survive in prose.
Watch the training video, then set up a rule in your tool that checks for the mistake every time, like a checklist before sending a report.
A saved video or note does nothing unless you act on it. Without a rule that runs every time, old habits return. People remember lessons when something makes them change what they do, not when they only read or watch.
Don't save a note or video and expect your behaviour to change. A lesson sitting in a folder will not remind you in the point you need it.
Write down what happened in your archive, then set a separate rule in your tool that runs every time you do that task again.
Stories and records help you learn, but unless you put a rule in place that acts each time, you will repeat the same error. Memory fades, but a rule brings the lesson back exactly when needed.
Don't put the story and the rule in the same place and expect you’ll remember. Writing both together means the rule gets buried and isn’t used when you need it.
Practise using your rules in real situations, not only reciting them. Set up reminders or blockers so you use them under pressure.
People can repeat all the rules perfectly, but when deadlines hit, stress makes them forget. Only rules that actually run in the point help you stick to them, especially when you’re busy or distracted.
Don't assume knowing the rules means you’ll follow them. Under stress, you can break several rules without even noticing if nothing reminds you.
Choose a tool or setting that blocks mistakes automatically, like a file lock or a required field, so you cannot skip the safety step.
When a tool blocks the mistake, you don’t have to remember to be careful. If the safety step is optional, it gets skipped when you’re in a rush, so errors slip through at the worst times.
Don't rely on your memory to catch every error. Optional checks get skipped, especially when you’re late or distracted.
Set up a separate checker—like a second person or an automated rule—so the person doing the work cannot approve their own changes.
A blocker that is not the person doing the task catches mistakes every time. When the checker and the actor are the same, errors slip through because people get used to their own habits.
Don't let the same person check their own work. Familiarity makes it easy to miss mistakes that a separate checker would catch.
List clearly which rules your tool cannot enforce, so you know where you have to pay extra attention and use self-control.
No tool can force every step, like making a model explain every choice. When you know which parts need your attention, you can watch yourself and not expect the tool to do it all.
Don't assume your tool covers every rule. Some things need your discipline, so forgetting which ones can leave big gaps.
Write each rule in full sentences that anyone could follow, with all steps spelled out and no abbreviations or inside jokes.
New people feel lost when rules use short forms or private language. When you write everything clearly, anyone who joins later can understand what to do without guessing or asking for help.
Don't write rules like 'No shortcuts in docs' or use initials and codes. New joiners will miss what matters, and mistakes get repeated.
Choose full explanations for each rule, using plain words and examples, so someone in a hurry can follow along when something breaks.
People only read these files when something has gone wrong. Dense notes or technical shorthand make them waste time guessing what to do, instead of fixing the problem.
Don't fill the notes with one-liners or technical codes. When someone needs help, they will not know what to do next.
Keep the main file with rules short and focused, so the most important instructions are easy to spot without scrolling through pages.
People skim long lists and miss what matters most. When you keep the file tight, the rules that prevent mistakes stay visible, even on a busy day.
Don't add every possible tip or warning to the main file. People will ignore the whole thing if it looks too long.
Add each new note or rule to the log without deleting older entries, so the full history of changes stays in the file.
When you erase old notes, nobody can see why a rule changed or what went wrong before. Keeping the full story helps everyone understand past decisions and avoid old mistakes.
Don't overwrite or remove previous log entries. The team loses the reasons behind changes, and repeats past errors.
Update the shared record with all details of your work before you tell anyone the task is finished, so nothing is forgotten.
When you wait until later, you forget the small but important details that explain what you did. Next time someone checks, the steps are missing and problems repeat.
Don't mark a job as done and promise to update the record later. People will miss the details that matter most.
Only keep rules in the main file that came from actual mistakes, so every instruction solves a real problem someone faced.
When you add guesses or warnings that never happened, the file fills with clutter. People stop trusting or following the rules, and real lessons get buried.
Don't add imagined problems or warnings that have not happened. The file becomes too long, and nobody can tell what matters.
No score, and nothing to finish. Every wrong answer opens with why the wrong idea was tempting.
AI tools can jumble similar file names, especially when lists are long or names look alike. Double-check that each file is mentioned separately in your prompt. Point out differences, such as dates or versions, so the tool keeps them apart.
AI tools often focus on the main sections at the top or middle of a document. Mention that your summary should include notes from the end as well. Point to the section by its heading or page number if you can.
Screen size changes can cause layouts to shift. Check your design on both devices before sharing. Leave space for things like the chat bar or notifications, so nothing important gets covered or lost.
AI tools use default styles unless you tell them what to use. Give the tool your brand colours and font names, or choose from the options in your design system. Check the finished slide before you present.
| Request | What you get |
|---|---|
| Summary | A short version of the whole update, covering all main ideas. |
| Action points | A list of tasks or next steps, usually with names and deadlines. |
Many AI tools focus on the main content and may not read comments or footnotes unless you ask directly. If your feedback is in a comment, mention the comments section in your question so the tool includes it. Comments can be hidden by default, so always specify if you want them.
Similar column names or number formats can confuse the AI tool. Make sure you use clear column headers like 'Contact_Number' and 'Invoice_Number'. When asking for details, mention the exact column name so the tool picks the right one every time.
AI tools can change answers based on small differences in your question or the context from earlier messages. To get consistent results, use the same wording each time and start a new chat if you want a fresh answer with no history.
| Feature | Summary | Detailed Report |
|---|---|---|
| Length | Short, 3-5 sentences | Long, several paragraphs |
| Detail | Key points only | All main points, examples, and data |
| Use | Quick update | Full review or record |
| Audience | Busy colleagues | Managers or clients needing full context |
Check the file name and last modified date shown in the tool before starting. Compare this with the version saved on your computer or cloud drive. If the tool shows an older date or a different file name, upload or select the correct version before continuing.
AI tools often group similar names or roles together if instructions are not clear. Always mention both the name and the specific task next to each entry. Double-check the list after processing to see if each person’s task is shown separately.
Keep both address lines in the same cell or field before sending them to the tool. Add a single comma or line break between them. Tell the tool to combine both lines as one address, so they stay together in the output.
AI tools may pick the first logo file they find if several are available. Name each logo file with the client’s full name—like 'Asha_Consulting_logo.svg'—and mention the exact file name in your request. Double-check the design output before sharing.
Export the slides in the original order from your desktop. When using the tool for mobile, check the slide order before sharing. If slides are out of order, re-upload the file and ask the tool to keep the order exactly as in 'training_deck.pptx'.
AI tools often do not know the screen size unless told. Ask for shorter paragraphs or use bullet points. Before sending, check the summary on your phone and ask the tool to shorten sections that look crowded.
| Type | Monthly Sales Report | Weekly Team Meeting |
|---|---|---|
| Focus | Numbers, trends, targets | Tasks, updates, next steps |
| Length | Longer, with details | Shorter, quick points |
| Audience | Managers, finance team | Team members |
| Language | Formal, specific | Casual, direct |
A hundred and thirty-seven habits, and the last one is the only one that matters on its own: anything that must never be violated cannot live in prose. Write it where it is enforced, or accept that it will hold until the day it does not.