Common AI mistakes to avoid when writing Craig Prompts
Writing a good prompt takes some care. Craig runs on a fast, efficient AI model — and like all AI models, it has predictable blind spots. This guide covers the mistakes that show up most often, and how to avoid them.
This article has two parts. Part 1 covers mistakes you need to address in your own prompts. Part 2 describes protections Craig already has built in — read it so you don't accidentally duplicate or weaken them.
Part 1 — Mistakes to fix in your prompts
1. Don't ask Craig to do math
What goes wrong. A rule like "only show this if the current time is within 60 minutes of the boundary" fires regardless of whether the time is actually close. Content that should be hidden gets included anyway.
Why it happens. Craig doesn't reliably calculate the difference between two times and compare it to a limit. Instead, it notices that the prompt, the data, and the rule all mention a time — and includes the content. The math check gets skipped.
How to fix it. Rephrase time-based conditions as range checks using values Craig can read directly, rather than values it has to calculate.
| AVOID | Show the storm advisory when the minutes from current local time to the expected storm arrival is between 0 and 60 inclusive. |
| BETTER | Show the storm advisory only when current local time, read as HH:MM, falls within the window [[advisory window start]] to [[advisory window end]] . This window is precomputed and passed in as part of the tool result. Outside the window, leave out the advisory. |
If the check is more complex than a simple range, ask the data tool to precompute the window — or a true/false flag — and pass it in as a field Craig can read directly.
2. Conflicting rules cancel each other out
What goes wrong. One part of your prompt says "use a comma list." Another says "never use a comma list." Craig picks one rule and applies it everywhere — ignoring the distinction you intended.
Why it happens. When two rules conflict, Craig resolves the tension by being consistent — and consistency wins over context. The difference between "this section" and "that section" isn't strong enough to override it.
How to fix it. Review your prompt for the same idea written two different ways. Use one format rule that applies throughout. If two sections genuinely need different formats, give them clearly different names and define each format separately.
| AVOID | Current observation rows: comma-separated fields per station. [[station]] : [[wind]] , [[temp]] , [[conditions]] ... Forecast rows: one line per forecast period. Never use a comma list. |
| BETTER | OUTPUT FORMAT (used for both observations and forecast): [[label]] : [[field]] , [[field]] , ... One line per station for observations; one line per period for forecast. Fields within a line are joined by ", ". |
3. Craig copies details from your examples
What goes wrong. You include an example with realistic-looking numbers to show the intended layout. Craig outputs those exact numbers — or labels from your example — even when the real data is different.
Why it happens. Examples are powerful, and they stick. Craig copies labels, values, and times from examples instead of reading them from the data source. This is especially likely when examples use realistic numbers rather than placeholders.
How to fix it. Use abstract placeholders like [[height]] or [[station]] in your examples — never real numbers. If you need to reference real data, pull it directly from the same source Craig will use at runtime.
| AVOID | Format response as "The flow rate is currently 10 m³/s and the water level is 1.9 m". (The values "10" and "1.9" are sticky — Craig may repeat them even when the actual data is different.) |
| BETTER | Format response as "The flow rate is currently [[flow]] m³/s and the water level is [[water level]] m". |
| AVOID |
Format as "The tide is 3m rising, the next high is 3m at (The real number "3m" appears twice; the AI latches onto it.) |
| BETTER | Format as "The tide is [[height]] m [[rising/falling]] , the next [[high/low]] is [[next height]] m at [[next time]] ". |
Two rules to follow every time: use [[field]] for every placeholder — pick one syntax and stick to it — and never put a real data value where a placeholder belongs.
4. Negative instructions are weak
What goes wrong. You write "the mention of X is NOT a trigger." Craig still treats any mention of X as a trigger.
Why it happens. Negative instructions ask Craig to ignore something it has already noticed. The word usually wins. Telling an AI what not to do is one of the least reliable ways to guide its output.
How to fix it. Replace "do not X" with a positive description of what to do instead. Better still, design your prompt so the unwanted word never appears in the first place.
| AVOID | Do not include water temperature, humidity, and air pressure. Report wind speed in knots. (Naming the forbidden fields primes Craig to mention them.) |
| BETTER | Output these fields only, in this order: tide, wind, sky conditions, forecast. Use knots for wind speed. |
| AVOID | Do not include lift status information. Put traffic information first. (Opens with a negative; the most important instruction is buried.) |
| BETTER | Start with traffic. Then weather, wind, cloud cover, temperature, snowpack, avalanche hazard. Leave out anything else. |
Rule of thumb: if a single instruction names more than one forbidden item, replace it with a positive list of what to include. Every item you name in a prohibition gets primed to appear.
5. When uncertain, Craig includes rather than omits
What goes wrong. Your prompt says "show this section only when X" — but in practice the section appears most of the time, even when X isn't true.
Why it happens. Craig hedges. If it's unsure whether a condition applies, it errs on the side of including content rather than leaving it out — especially when other parts of the prompt emphasise not skipping important information.
How to fix it. State the default behaviour explicitly and keep exceptions separate. Write the normal case and the special case as two distinct sentences. Better still: design the prompt so the default is "always show," removing the conditional entirely.
| AVOID | Show the high-tide caution only when within 30 minutes of high tide. (Single-sentence conditional — too easy to misread.) |
| AVOID | The high-tide caution is OFF by default. Turn it ON only if: (a) you can calculate minutes to the next high-tide event, and (b) that value is between 0 and 30. (Clearer, but still requires math — see mistake #1.) |
| BETTER |
Default: show the tide observation only. Exception: show the high-tide caution ONLY when current HH:MM is in (Range check) |
| BETTER | Always show the tide observation and next high-tide time and height. (No decision needed.) |
If a conditional is genuinely hard to express, "always show" is a reliable fallback.
A related problem: vague output specifications.
| AVOID | Format: GO / CAUTION / NO-GO per condition, TLDR summary at the beginning. ("Per condition" is vague — Craig invents its own list and the output drifts between runs.) |
| BETTER | Format: a TLDR line at the top, then one line per item from this exact list: Icing, Wind, Ceiling, Visibility, Density altitude, Turbulence. Each line: "[[item]] : [[GO/CAUTION/NO-GO]] — [[reason]] ". |
6. The last instruction carries the most weight
What goes wrong. Two rules contradict each other and the later one wins. Or the final few instructions in a long block get followed more carefully than the earlier ones.
Why it happens. Craig naturally pays more attention to text that appears later in a prompt. Long prompts also push earlier content out of focus.
How to fix it. Put your most important, non-negotiable rules at both the beginning and the end of your prompt. Keep prompts as short as possible — every extra paragraph reduces the influence of earlier instructions.
| AVOID | Do not mention parking information. Put traffic information first. Get conditions from https://example.com/conditions. (The negative leads; the most important instruction is buried in the middle.) |
| BETTER | Start with traffic. Then: road status, weather, wind, visibility, temperature. Source: https://example.com/conditions. Show only the items listed above — leave out anything else from the page. (Most important instruction first, scope limit last — where Craig's attention is strongest.) |
7. Craig fills gaps with plausible-looking details
What goes wrong. The output contains a time, ID, or value that doesn't appear in any data result. The invented detail looks realistic and fits the expected format — which makes it hard to spot.
Why it happens. When Craig must fill a slot in a strict template and doesn't have the right value, it may invent a believable one rather than leave the slot empty. Craig's built-in instructions already handle null or empty fields automatically (see Part 2) — but when your prompt assumes a record exists that isn't there, Craig may fabricate an entire row to satisfy the template.
A real example: a prompt asked for the next tide event; the data returned four events for the day. The output included a fifth — "Next low at 06:30" — a plausible time that wasn't in the data, invented because the output format implied one row per quarter of the day.
How to fix it. Name the exact field Craig should copy from, and tell it explicitly what to do if that field is missing.
| AVOID | Show the next event as "Next [[high/low]] at [[time]] ". (No source constraint — Craig can invent a time if the data doesn't have enough events.) |
| BETTER | Show the next event as "Next [[high/low]] at [[time]] ", where both values are copied exactly from the tool result's events[0] entry. If there is no events[0] record, skip the line entirely. Do not invent a placeholder row. |
| AVOID | Show the station ID from the observation. ("From the observation" is too vague.) |
| BETTER | Show the [[station id]] by copying the value of the tool result's `msc_id` field exactly. If the tool result does not include `msc_id`, skip the station_id line entirely—do not invent or substitute an ID. |
8. Craig calculates values you didn't ask for
What goes wrong. The data source returns individual fields. The output contains a calculated value — a duration, a difference, a trend — that doesn't appear in any tool result.
Why it happens. Craig doesn't see arithmetic on existing data as "inventing" something. When your prompt asks for something the tool doesn't directly return — for example, whether a river is "rising or falling" — Craig will quietly calculate it. Sometimes that calculation is wrong, particularly at inflection points like the turn of a tide.
How to fix it. Ask only for values the tool actually provides. If you need a calculated value, ask for it to be added to the tool's output — don't ask Craig to compute it.
| AVOID | Format as "The tide is 3m rising". ("Rising" is calculated. If the tool returned only the current height and the next event but no trend field, Craig worked it out itself — and may be wrong near the turn of the tide.) |
| BETTER | Format as "The tide is [[height]] m, [[rising/falling]] ". Take [[rising/falling]] only from the tool result's trend field. If that field is missing, leave out the direction entirely. |
| AVOID | Include whether the river is rising or falling. (Implicit calculation — Craig compares the current flow to a "recent" value, but which one? The answer is inconsistent.) |
| BETTER | Include the river's [[rising/falling]] from the `trend` field if present. If not present, leave it out. |
Note: Mistake #8 is related to mistake #1 but applies specifically to output values rather than conditions.
Part 2 — What Craig already handles
Every Craig request runs through a set of built-in instructions before your prompt reaches the AI. You don't need to repeat these — and repeating them in weaker language can actually undermine them (see mistake #2). Read this section so you know what's already taken care of.
Active warnings are always included. If any data result contains an active warning, Craig will include a Warning: ... line for each one. You don't need to write "always include warnings."
Values are reproduced exactly. Numbers, units, names, IDs, and timestamps are copied from the data result as-is. If a tool returns wind_speed_kmh: 12 , the output will say 12 — not "around 10" or "approximately 12 km/h." You don't need to write "report values exactly."
Empty fields are skipped. If a tool returns a null or empty field, Craig will not invent a substitute. The field simply won't appear. You don't need to write "skip empty fields" or "do not include unavailable data."
Each data source stays separate. When multiple tools return data — for example, readings from several weather stations — each station's output uses only its own values. You don't need to write rules about keeping station data separate.
Output is plain text. Craig's output is plain text by default — no bold, no bullet points, no headings, no emoji. You don't need to write "no markdown" or "plain text only."
How to avoid weakening these protections
Two things to watch for:
- Don't use markdown in your examples. If your prompt contains
**Station**: <reading>, Craig may read that as overriding the plain-text rule. Stick to plain text and[[field]]placeholders throughout. - Don't repeat a built-in rule in weaker wording. If Craig's built-in instructions already cover something, restating it less precisely draws attention away from the stronger version. Trust the built-in rule and leave it alone.
Quick checklist
Before saving a prompt, run through these:
- Does any rule depend on a calculation? Rephrase it as a range check.
- Are two rules covering the same idea with different wording? Merge them into one.
- Do your examples use
[[placeholders]]rather than real data values? - Is the default behaviour the common case, with exceptions only for genuine edge cases?
- Are "do not" instructions paired with a positive description of what to do instead?
- Does every placeholder name the exact tool field it should copy from, with a fallback if that field is missing?
- Does your prompt repeat anything Craig already handles?
- Have you tested the prompt several times with real data to confirm the output is consistent?