promptbehavior

name	promptbehavior
description	Write the behavior section of an agent prompt — decision patterns, prohibition rules, communication style, and iteration rules for agents that run more than once. Use when writing the behavior section or defining how the agent operates.
license	MIT

Promptbehavior

Output: a ## Behavior section (Markdown, default) or <behavior> block (XML) written to prompts/{slug}.behavior.md.

Context

Define how an agent operates across all tasks: what it does before acting, what it never does, how it makes decisions, and how it communicates. Behavior persists across all task invocations, just like role — but role answers "who are you" while behavior answers "how do you operate."

Tradeoff: Rich behavior specs reduce unpredictability but add prompt length. For simple one-shot agents, keep only communication style and one or two prohibitions.

Scope: This skill covers operational rules only. Agent identity belongs in promptrole. Runtime environment belongs in promptcontext. The immediate task belongs in prompttask.

Task

Apply to the User's Input

The user invokes this skill with a description of the agent's operating environment. Specialize every step below to that input.

• A read-only analysis agent needs different directives than a write-capable code agent.
• An agent that runs more than once needs an iteration block and termination criteria; a one-shot agent does not.
• If the input does not specify what the agent can do (read-only, write, run commands), ask one clarifying question before drafting.
• If the user says "xml", "as xml", or "xml format", produce XML output; otherwise default to Markdown.

Part A: Classify the Behavioral Context

Choose a baseline profile before writing individual rules.

• Read-only: the agent reads and analyzes but does not modify state. Leads with STRICTLY PROHIBITED from: and a bulleted list of concrete forbidden actions (edit, write, delete, run state-changing commands).
• Write-capable: the agent can modify files or state. Leads with operational directives (read before modify, prefer reversible). Prohibitions are targeted, not blanket.
• Agentic: the agent runs more than once and may delegate. Adds an iteration block (named loop, named iteration steps, budget, escalation, termination) on top of the above.

Part B: Define Operational Directives

What the agent does before acting. Address the agent as you (or imperative); the produced prompt is the agent's own instructions, not a description of the agent.

• "Read before modifying": establish state before changing it.
• "Diagnose before retrying": name the root cause before switching approach.
• "Ask one clarifying question if scope is ambiguous": naming the number avoids back-and-forth.
• "Verify after completing a step": check the output before continuing.

Express required behaviors with MUST: MUST read the file before proposing edits — the word "always" is weaker and treated as advisory.

Part C: Define Prohibition Rules

Each prohibition names the forbidden action and the failure mode it prevents.

• NEVER predict tool results before they return — not as prose, not as structured output closes more paths than do not predict results.
• NEVER stack multiple tasks in one prompt — you will drop or merge steps.
• NEVER assert facts about files or system state that can be verified with a tool.
• NEVER skip verification — you will rationalize "it looks correct" as sufficient; it is not.

For read-only roles, use STRICTLY PROHIBITED from: as a top-level bullet with nested items for each forbidden action.

Each behavioral directive should be its own bullet item so rules can be referenced and extended independently.

- STRICTLY PROHIBITED from:
  - editing, writing, creating, or deleting files
  - running state-changing commands
  - installing packages or modifying configuration

Pair every prohibition with its failure mode. NEVER skip X is weaker than NEVER skip X — [specific consequence]. Naming the temptation makes it harder to rationalize away.

Part D: Define Decision Patterns

Rules the agent applies when it must choose between approaches.

• Reversible over destructive: prefer approaches that can be undone; flag irreversible steps before taking them.
• Simplest approach first: solve with the minimal intervention that achieves the goal; do not introduce abstractions not required by the task.
• Parallel when independent, sequential when dependent: call multiple tools in a single response when their results do not depend on each other; call sequentially otherwise.
• Surface before assuming: when the right approach is unclear, surface options and tradeoffs rather than silently picking one.

Part E: Define Communication Style

How the agent structures every response.

• Answer-first: lead with the conclusion or result, not the reasoning that produced it.
• Omit preamble: do not restate the question, confirm understanding, or describe what you are about to do.
• Length default: match response length to task complexity; avoid padding ("Great question!", "Certainly!", "In conclusion,").
• Jargon level: name the target audience explicitly ("Write for a non-technical reader" or "Assume senior engineering context").

Use NEVER for style prohibitions with real failure modes: NEVER open with a restatement of the question — it delays the answer and adds no information.

Part F: Define the Iteration Block

For an agent that runs more than once, write a self-establishing iteration block. The agent reads the prompt cold — it has no memory of being placed in a loop and no antecedent for "this cycle" or "the next step". Open the block with one sentence that names the loop and lists its iteration steps; only then may later directives refer to "each iteration" or "the next iteration".

Cover all of the following, in this order.

• Loop declaration (always first, establishes the antecedent): "You operate in a loop. Each iteration runs four steps: observe, plan, act, verify."
• Self-criticism: "After each iteration, re-read the output of that iteration against the task objective; if it does not match, halt and report the discrepancy rather than starting the next iteration."
• Iteration budget: "Stop after N iterations and report what was completed." — bounded autonomy beats open-ended.
• Escalation trigger: "Escalate after one failed retry rather than silently skipping."
• Termination criteria — name all four types that apply:
  • Explicit: iteration limit or task-completion flag ("Stop when the output file exists and passes validation.").
  • Implicit: stalemate detection ("Stop when two consecutive iterations produce identical results with no progress.").
  • Human-in-the-loop: approval gate ("Pause and request confirmation before any destructive action.").
  • Resource-based: budget cap ("Stop when the token budget or timeout is reached and report partial progress.").
• Subagent coordination (if delegating): pass self-contained prompts; state the handoff condition explicitly; do not predict async subagent results before completion.

Part G: Format the Output

Markdown (default) — open with ## Behavior, then the content:

## Behavior

- MUST read the file before proposing edits.
- NEVER predict tool results before they return — not as prose, not as structured output.

XML — wrap content in <behavior> tag, no heading:

<behavior>
- MUST read the file before proposing edits.
- NEVER predict tool results before they return — not as prose, not as structured output.
</behavior>

Verification

1. Every prohibition names a concrete action and its failure mode.
2. Every required behavior uses MUST (not "always" or "try to").
3. Read-only roles use STRICTLY PROHIBITED from: with a concrete list.
4. Communication style states length default and jargon level.
5. Agentic roles open the iteration block with a loop declaration that names the iteration steps, then add iteration budget, escalation trigger, and termination criteria.
6. No behavior rule repeats something already in the role file.
7. Format matches user's request: ## Behavior heading for Markdown, <behavior> wrapper for XML.

Derive a slug from the input (same convention as promptrole). Create the prompts/ directory if it does not exist. Write the file to prompts/{slug}.behavior.md. Confirm the file path. No other output.