Prompt Patterns That Scale

The six patterns that almost every high-scoring Grok Bot use case is built from.

Read twenty curated use cases and the prompts stop looking like twenty ideas — they look like six ideas wearing different hats. Learn the six and you can read, fix, and write prompts like the builders do.

1. The interview (setup before work)

Before we start, interview me about X. Propose a plan, let me approve or edit it, then save it to a file.

The bot interrogates you once instead of guessing forever. Every use case that needs preferences — channels, budgets, watchlists, tone — opens this way. It converts taste into configuration.

2. The two files (config + state)

• config.md — what to watch, thresholds, rules, exclusions.
• seen.md / log.md — what has already been handled.

The prompt never stores facts; it points at files. Facts change, files get edited, memory stays out of it. This is the single highest-leverage swap you can make in an existing prompt.

3. The quiet-day rule

If there is nothing new, send exactly one line: “Nothing today.” No filler.

Without it, a bot fills silence with noise; with it, a message means something. This rule is why some bots get read every day for months and others get muted in a week.

4. The report format

For each item: title, 3 bullets on what it actually says, one line on why I’d care, the link. Order by relevance. Under one screen.

Format is the user interface of a routine. Specify length, structure, and ordering explicitly — the model’s default is “more words,” and more words is exactly what you don’t want at 7am.

5. The escalation boundary

Draft, never send. Propose, never buy. If a request would cost money, delete data, or contact a human, stop and ask me.

State the ceiling of autonomy explicitly, in cost-of-error terms. Bots with a written boundary get trusted with more, because their human can predict the worst case.

6. The anti-drift clause

Re-read your instructions and the files above at the start of every run. If this prompt and a file disagree, the file wins for data, this prompt wins for rules.

Long-lived routines drift. The clause tells the bot where authority lives, which is most of what “staying consistent” means.

Putting them together

A complete prompt skeleton, ~15 lines:

You are <role>, my <scope> bot.

SETUP — interview me first, then save the plan to config.md.
Create log.md; never report the same item twice.

ROUTINE — <schedule>:
1. Check <sources> (via <tool>).
2. Compare against log.md; only new items count.
3. Report in this format: <format>.
4. If nothing new: "Nothing today." Nothing else.

Rules: <escalation boundary>. Summaries come from <source of truth> —
never invent. Re-read files each run; files win for data.

Every use case in the library maps onto this skeleton. When one breaks, diagnose by layer: role confused? config stale? log missing? format bloated? boundary vague? That’s the whole differential.

Anti-patterns worth naming

• The personality essay. 300 words of persona, 0 words of protocol. Entertaining, uncontrollable.
• The kitchen sink. One bot doing research, triage, and posting. Split it — agent teams exist for a reason.
• The invisible rule. “You know what I like.” No file, no chance.

The fastest way to internalize the patterns: pick a use case you already run, find its weakest layer, and rewrite just that layer.