Define task behavior patterns

Define task behavior as reusable patterns that you can apply across prompts without rewriting instruction logic each time.

When patterns are reusable, you get more consistent output, faster reviews, and fewer one-off fixes.

Pattern anatomy

A task pattern defines one complete behavior that a model can execute and a reviewer can test. Build each pattern with four parts.

Part	What to define	Why it matters
Trigger	The condition that starts the behavior.	Prevents the model from guessing when to apply a pattern.
Action steps	The ordered actions for the task.	Keeps multi-step output stable across runs.
Output contract	The required format, length, and fields.	Makes output scannable and testable.
Failure handling	What the model does when input is incomplete, ambiguous, or out of scope.	Prevents silent failure and unsafe guessing.

Write each pattern as a standalone unit. If two behaviors need different triggers, they are two patterns.

Rule wording patterns

Use language a reviewer can observe. Avoid abstract intent words and weak qualifiers.

Use	Avoid
”If required fields are missing, ask for the missing fields before answering."	"Try to ask for more detail when needed."
"Return a three-bullet summary with one risk and one next step."	"Provide a helpful summary."
"If the request is out of scope, state that directly and offer one supported next step."	"Handle unsupported requests appropriately."
"Do not claim actions that were not performed in this environment."	"Be honest about capabilities.”

Use one instruction per line where possible. Bundled instructions are harder to execute and harder to evaluate.

Keep high-priority constraints near the end of a prompt as a recency guard for long prompts.

Failure-mode patterns

Cover failure paths as first-class behavior, not exceptions.

Empty or malformed input: state what is invalid and request the minimum information needed.
Ambiguous requests: name the ambiguity and ask one clarifying question.
Out-of-scope requests: state the supported scope and point to one concrete next step.
Missing context or unavailable tools: state what is missing and what is needed to proceed.
Sensitive or unsafe requests: decline and provide a brief safe alternative when one applies.

Task pattern template

Use this template to draft new task patterns.

Pattern name: <clear noun phrase>

Trigger
- If <condition>, run this pattern.

Action steps
1. <step 1>
2. <step 2>
3. <step 3>

Output contract
- Format: <table | bullets | JSON | prose>
- Length: <target length>
- Required fields: <field list>

Failure handling
- If input is missing <required field>, ask for <field>.
- If request is out of scope, state the scope boundary and offer one supported next step.
- If capability is unavailable, state the limitation and continue with the best available action.

Review pass

Before shipping a pattern, confirm:

The trigger is specific and testable.
Multi-step behavior is in ordered steps.
The output contract names format, length, and required fields.
There are no contradictions between Rules and Example output.
Failure behavior is explicit for ambiguity, missing input, and out-of-scope requests.
Rules use observable verbs like “ask,” “return,” “decline,” and “cite.”

Source documents

This page adapts the task and rule guidance from these source documents for Fluent content-engineering workflows.