promptrole

name	promptrole
description	Write the role section of an agent prompt — the agent's identity, including its domain of expertise and fallback behavior. Use when writing the role section or defining who the agent is.
license	MIT

Promptrole

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

Context

Define who an agent is: its domain of expertise, the behavioral lens it applies to all tasks, and what it falls back to when it cannot answer. A role persists across all task invocations; a task does not.

Tradeoff: Role definition shapes style and alignment. For domain-constrained tasks, a specific role reduces off-domain responses and narrows hallucination risk. For open knowledge-retrieval tasks, a strong persona can increase hallucination risk — the agent stays in character rather than admitting uncertainty. It does not substitute for grounding.

Scope: This skill covers agent identity only. Operational rules belong in promptbehavior. Runtime environment facts belong in promptcontext. The immediate task belongs in prompttask.

Task

Apply to the User's Input

The user invokes this skill with a domain, function, or purpose for the agent. Specialize every step below to that input.

• Build the identity sentence from the input ("You are a [domain expert] who...", with the actual domain filled in).
• Narrow the domain to match the specific context, not the broadest applicable category.
• If the input does not specify domain or audience, 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: State the Identity

One sentence. "You are a [seniority] [domain] [role] who [behavioral expectation]."

• Name the domain specifically: "You are a senior backend engineer reviewing distributed systems" outperforms "You are an expert engineer".
• Include a behavioral expectation in the identity sentence: "…who explains tradeoffs without jargon" gives the agent a lens for every task that follows.
• Use direct assignment: "You are…" is more effective than "Imagine you are…" or "Act as…".
• One identity per agent. Two simultaneous roles produce conflicting tone and style signals; a second concern becomes a constraint, not a second role.

Part B: Narrow the Domain

Narrow roles outperform broad ones for specialized output.

• Prefer "You are a tax advisor reviewing self-employed deductions" over "You are a financial expert".
• Secondary concerns go as constraints, not a second domain: "You are a backend engineer. Write for a non-technical audience." — not "You are a backend engineer and a technical writer."
• Skip the role for generic or undirected tasks where domain alignment adds no value; a role is not required.

Part C: Add the Fallback Clause

Always include a fallback: "If you cannot answer confidently, say so." Expert personas tend toward overconfident wrong answers without it. One sentence at the end of the role is enough.

Part D: Format the Output

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

## Role

You are a senior backend engineer who reviews distributed systems with a focus on correctness and performance. If you cannot answer confidently, say so.

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

<role>
You are a senior backend engineer who reviews distributed systems with a focus on correctness and performance. If you cannot answer confidently, say so.
</role>

Verification

1. Identity sentence names domain and behavioral expectation.
2. Exactly one identity (not two).
3. Fallback behavior is specified.
4. Domain is specific, not generic.
5. Format matches user's request: ## Role heading for Markdown, <role> wrapper for XML.

Derive a slug: kebab-case of the 2–3 most distinctive words in the input (e.g. "senior backend engineer" → backend-engineer). Create the prompts/ directory if it does not exist. Write the file to prompts/{slug}.role.md. Confirm the file path. No other output.