Prompt Patterns That Actually Work in Now Assist Skills (and the Ones That Quietly Fail)

Prompt engineering for a platform skill is not the same craft as prompting a chatbot, and treating it like one is why so many skills behave inconsistently in production. A chatbot prompt is a one-off conversation. A skill prompt is a component that runs thousands of times against messy, varied inputs and has to produce structured output the rest of your workflow can consume. Different job, different patterns. Here is the catalog, the ones that hold up and the ones that quietly betray you.

Start with what is different: a Now Assist skill couples the prompt with an input/output schema and grounding, so your prompt does not work alone. The single most effective pattern is leaning on that schema rather than fighting it. Instead of begging the model in prose to "please return JSON with these fields," define the output structure and write the prompt to fill it. A constrained output target is a leash on the model's freedom to wander, and it makes the result something your downstream flow can parse reliably. Pair that with explicit grounding cues, instruct the skill to answer from the retrieved content and to say it does not know when the content is absent, which is the difference between a skill that admits a gap and one that invents a procedure to fill it.

Instruction patterns that hold up share a quality: specificity. Give the skill a precise role and a narrow job, "you classify incidents into these categories" beats "you are a helpful IT assistant." Provide one or two examples of the desired output, but only the examples that actually change behavior, not a wall of them. State the constraints positively and concretely, what to do, what format, what to refuse. And keep one skill to one job, because a tightly scoped prompt is consistent and a sprawling one is a coin flip.

Now the anti-patterns, because avoiding these matters as much as applying the good ones. The mega-prompt, one giant instruction block trying to handle five scenarios with nested conditionals, produces exactly the inconsistency you would expect; split it into multiple skills. The vague role, "be helpful," gives the model no discriminating signal and invites drift. Over-stuffed few-shot examples bloat your token cost (every example ships on every call) and often do not improve behavior. And the silent killer: changing a prompt and shipping it without re-running your evaluation set, because prompt changes have non-obvious ripple effects and the only way to know you did not regress is to measure. Treat every prompt edit as a change that must pass the eval suite. The skills that behave in production are the ones whose prompts are specific, schema-anchored, grounded, single-purpose, and regression-tested. The ones that misbehave are almost always vague, sprawling, ungrounded, and shipped on a hunch.