Identity Approaches for Claude Prompts

Calibration: Tier 1, Opus-primary. See repository README for model compatibility.

Identity is the first layer of a well-structured Claude prompt. It defines WHO Claude is for a task — shaping the depth of analysis, the vocabulary used, the reasoning style applied, and what Claude treats as obvious versus what requires explanation.

A prompt without a clear identity produces generic output. A prompt with the wrong identity produces output that's confident in the wrong domain. Getting the identity right is the single highest-leverage decision in prompt construction.

When to Use This Skill

• You are building a Claude prompt and need to choose or define a role/persona
• You have a prompt whose output lacks domain-appropriate depth or vocabulary
• You need to decide which expert perspective fits a task
• You want to build a custom identity for a specialized domain

Choosing the Right Identity

Quick Selection Table

Selection Decision Tree

Step 1 — Is the task about making a decision or producing an artifact?

If the primary output is a decision, recommendation, or evaluation:

• Business/market decision → Strategic Advisor
• Technical/architecture decision → Technical Architect
• Product/feature decision → Product Strategist
• Financial/investment decision → Financial Analyst

If the primary output is a process, system, or workflow:

• → Operations Designer

If the primary output is synthesized understanding from multiple sources:

• → Research Synthesist

If the primary output is a message, narrative, or positioning:

• → Communications Strategist

If the primary output is an explanation or teaching artifact:

• → Educator / Explainer

Step 2 — Check the audience.

The identity shapes the output's depth and vocabulary. If the audience differs from what the identity naturally assumes:

• Strategic Advisor assumes executive-level business literacy → add audience constraints for non-business readers
• Technical Architect assumes high technical sophistication → add audience constraints for non-technical stakeholders
• Financial Analyst assumes financial literacy → specify when communicating to non-financial audiences
• Research Synthesist can over-hedge → constrain to reach clear conclusions when needed

Step 3 — Check for domain specialization.

These eight approaches are domain-agnostic starting points. For deeper specialization in specific verticals (consulting, M&A, SRE, security, editorial, data analysis, policy research), domain-specific identity approaches are available in the rootnode-domain-* skills if installed. Domain approaches extend these core approaches — they do not replace them.

When Multiple Approaches Seem to Fit

If a task sits at the intersection of two domains, do NOT combine two full identity approaches. Instead:

1. Pick the PRIMARY identity — the one whose reasoning style matters most for the output quality
2. Add domain context from the secondary area as a constraint or context statement
3. Example: A financial analysis of a product decision → use Financial Analyst with product context added to the prompt's context layer, not a merged Financial-Product hybrid

Complete Approach Documentation

Each approach includes the full identity template (ready to paste into a prompt), usage guidance, and specific failure modes to watch for.

• Strategic approaches: Strategic Advisor, Financial Analyst, Product Strategist → see references/strategic-identities.md
• Technical approaches: Technical Architect → see references/technical-identities.md
• Research approaches: Research Synthesist → see references/research-identities.md
• Communications approaches: Communications Strategist, Educator / Explainer → see references/communications-identities.md
• Operations approaches: Operations Designer → see references/operations-identities.md

Read the relevant reference file when you need the full identity template text, specific usage guidance, or failure mode documentation for an approach.

Building Custom Identities

When none of the eight approaches fit, build a custom identity using this template:

<role>
You are a [SENIORITY] [ROLE] with deep expertise in [DOMAIN 1], [DOMAIN 2], and [DOMAIN 3].

You approach problems by [REASONING STYLE — how you think through issues].

You prioritize [VALUE 1] over [VALUE 2 — the thing you'll sacrifice when there's a tension].

[ONE SENTENCE on your communication style or a behavioral instruction that distinguishes this role from a generic one.]
</role>

Calibration Principles

Seniority shapes the output. "Senior" or "principal" produces nuanced analysis with tradeoffs acknowledged. Removing seniority or using "junior" produces more explanatory, step-by-step output. Match seniority to the analytical depth you need, not to the audience's seniority.

Domain intersections create distinctive thinking. "Data scientist with supply chain expertise" produces different analysis than either role alone. Use intersections when the task genuinely sits at a crossroads — not as a way to cover more ground.

Stated values resolve ambiguity. When Claude faces a tradeoff in the task (thoroughness vs. speed, precision vs. accessibility, innovation vs. safety), the values statement tells it which way to lean. Without this, Claude defaults to optimizing everything simultaneously and producing middling output.

The behavioral sentence prevents drift. One concrete instruction about how this role communicates — "You are direct and do not pad analysis with unnecessary caveats" or "You explain your reasoning transparently so others can disagree with your logic, not just your conclusions" — anchors the identity more effectively than additional domain descriptions.

Common Custom Identity Mistakes

• Too many domains. Three is the practical limit. More than three dilutes the identity.
• No values statement. Without a clear priority, Claude tries to satisfy every possible objective and produces generic output.
• Generic behavioral sentence. "You communicate clearly" adds nothing. Make it specific to a real tension the role faces.
• Mismatched seniority. Using "junior" when you need sophisticated tradeoff analysis, or "principal" when you need accessible step-by-step explanation.

Critical: Identity Is Not Enough

An identity approach defines WHO Claude is. It does not define WHAT Claude should do (objective), WHAT Claude knows (context), HOW Claude should reason (methodology), or WHAT the output looks like (format). A strong identity paired with a vague objective still produces vague output. Always pair identity with clear objective, context, and output instructions.

Troubleshooting

Output sounds generic despite having an identity. The identity is too broad or too similar to Claude's default behavior. Make it more specific — add domain intersections, sharper values, or a behavioral sentence that pushes Claude away from its defaults.

Output uses wrong vocabulary or depth. The identit