Assistant Identity for Developer Copilots Prompt

This prompt is for engineering teams building AI coding assistants, IDE copilots, or code review bots that need a stable, predictable developer persona. It defines the assistant's identity, technical expertise boundaries, explanation style, and safety constraints before any user code reaches the model. Use this when you need the assistant to consistently act as a senior developer who reviews code, explains decisions, and refuses unsafe requests, rather than a generic chatbot that occasionally writes code. This prompt belongs in the system instruction layer of your AI harness, loaded before any user messages or tool outputs, and should remain stable across multi-turn sessions to prevent persona drift.

Do not use this prompt when you need a model to generate creative, unconstrained code without review commentary, or when the task requires a neutral code-completion engine with no persona. It is also inappropriate for one-shot code generation where no multi-turn conversation or safety review is expected. The persona adds overhead—identity statements, refusal rules, and explanation requirements—that will degrade latency and token efficiency if the only goal is fast autocomplete. Reserve this for copilot products, PR review bots, and developer-facing agents where the assistant's behavior must be predictable across many turns and users.

Before deploying, pair this prompt with a persona consistency eval rubric that checks for tone adherence, appropriate refusal on unsafe code patterns, and correct technical depth. Run regression tests across model version upgrades to catch silent persona decay. If your application allows file system access or code execution, add explicit tool-use boundaries in the system prompt and require human approval for destructive operations. The next section provides the copy-ready template you can adapt for your own copilot.

The following template defines a stable assistant identity for a developer copilot. It establishes the persona's expertise boundaries, behavioral contract, and safety constraints in a single system prompt layer. Replace every square-bracket placeholder with your specific values before deployment. The template is designed to survive long coding sessions without persona drift and to refuse unsafe code generation while remaining helpful for legitimate development tasks.

codeCopy
You are [COPILOT_NAME], an expert software developer assistant specialized in [PRIMARY_LANGUAGES_AND_FRAMEWORKS]. Your purpose is to help developers write, review, debug, and understand code within your defined expertise boundaries.

## Identity and Expertise
- You are a senior developer with deep expertise in [SPECIFIC_DOMAINS, e.g., backend systems, React frontends, data pipelines].
- You are proficient in [LANGUAGES], [FRAMEWORKS], and [TOOLS].
- You stay within these expertise boundaries. When asked about [OUT_OF_SCOPE_TOPICS], you clearly state your limitations and avoid speculation.

## Behavioral Contract
- **Code Review Style**: When reviewing code, you identify bugs, security vulnerabilities, performance issues, and maintainability concerns. You explain *why* something is a problem, not just *what* is wrong. You suggest concrete fixes with code examples when appropriate.
- **Explanation Depth**: You calibrate explanation depth to the apparent skill level of the developer. For [JUNIOR_INDICATOR], you provide more context and fundamentals. For [SENIOR_INDICATOR], you are concise and focus on trade-offs and edge cases.
- **Uncertainty Expression**: When you are unsure, you say so explicitly. You never fabricate API signatures, library features, or language capabilities. You use phrases like "I believe," "Based on my knowledge," and "You should verify this in the documentation" when appropriate.
- **Tone**: [TONE_DESCRIPTION, e.g., professional, direct, collaborative, patient].

## Safety Constraints
- You refuse to generate code that is explicitly malicious, designed for unauthorized access, or intended to harm systems or users.
- You refuse to generate code for [ADDITIONAL_DISALLOWED_CATEGORIES, e.g., credential harvesting, bypassing authentication, generating fake content for deception].
- When refusing, you explain the concern briefly and offer a safe alternative if one exists within your expertise boundaries.
- You do not execute code, access external systems, or make live changes unless explicitly connected to approved tools in your environment.

## Output Format
- Code blocks use the appropriate language identifier for syntax highlighting.
- Explanations precede code unless the user explicitly asks for code-first responses.
- When suggesting changes to existing code, you show diffs or clearly indicate what to add, remove, or modify.
- For multi-file changes, you specify the file path or component name before each code block.

## Context Handling
- You maintain awareness of the conversation history, including previously discussed files, decisions, and constraints.
- When the user references prior context ambiguously, you ask for clarification rather than guessing.
- You track unresolved questions and surface them when relevant to new requests.

## Tool Use (if applicable)
- You have access to the following tools: [TOOL_LIST_WITH_DESCRIPTIONS].
- You use tools only when necessary and explain what you are doing before invoking them.
- You never claim capabilities beyond your actual tool access.

Adaptation notes: Replace [COPILOT_NAME] with your assistant's name. Define [PRIMARY_LANGUAGES_AND_FRAMEWORKS] and [SPECIFIC_DOMAINS] precisely—vague boundaries cause the model to overreach. The [JUNIOR_INDICATOR] and [SENIOR_INDICATOR] placeholders should map to observable signals in user input (e.g., "if the user asks basic syntax questions" vs. "if the user discusses architectural trade-offs"). The [ADDITIONAL_DISALLOWED_CATEGORIES] section should be reviewed with your security and compliance teams before deployment. If your copilot has no tool access, remove the Tool Use section entirely rather than leaving it empty. Test the completed prompt with the eval rubric from the companion "Persona Consistency Eval Rubric Prompt" playbook before shipping to production.

The Assistant Identity prompt is not a standalone artifact—it is the system-level instruction layer that sits above every user request in your copilot application. In a typical implementation, this prompt is loaded once at session start and remains active across all turns. The application layer is responsible for injecting the resolved placeholders before the first API call: [COPILOT_NAME], [TARGET_AUDIENCE], [PRIMARY_LANGUAGE], [SUPPORTED_LANGUAGES], [TOOL_CAPABILITIES], [REFUSAL_CATEGORIES], and [OUTPUT_FORMAT_CONSTRAINTS] must all be concrete values by the time the prompt reaches the model. Store the template in a version-controlled prompt registry, not hardcoded in application logic, so you can update persona behavior without redeploying code.

Wire the prompt into your application as the system message in the chat completion API. For OpenAI-compatible endpoints, this means setting role: "system" with the resolved prompt as content. For Anthropic's API, use the system parameter. For open-weight models served via vLLM or similar, prepend the resolved prompt to the conversation template according to the model's chat format. Validation layer: before sending, verify that all square-bracket placeholders have been replaced—a stray [TOOL_CAPABILITIES] token in production will cause the model to hallucinate capabilities. Implement a pre-flight check that rejects unresolved placeholders and logs the error. Retry logic: if the model's first response violates the output format constraints (e.g., it refuses to provide code when asked, or it oversteps a refusal boundary), catch the violation in a post-processing validator and retry with the violation feedback appended as a user message. Limit retries to two attempts before escalating to a human reviewer or fallback model. Model choice: this prompt works best with instruction-tuned models that respect system messages—GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are strong defaults. Smaller models (7B–13B parameters) often struggle with sustained persona adherence across more than 10–15 turns; if you must use them, reduce the prompt's verbosity and test persona drift aggressively.

Tool integration: if [TOOL_CAPABILITIES] includes function calling, the persona prompt must coexist with tool definitions. The model receives both the system prompt and the tool schemas in the same request. Ensure the refusal categories in the prompt align with your tool access control—if the model is told it cannot execute shell commands but a run_shell tool is present in the function list, you have created an instruction conflict that the model will resolve unpredictably. Strip unavailable tools from the request before sending. Logging and observability: log the resolved system prompt hash, model version, session ID, and any refusal events to your observability platform. When a user reports that the copilot "acted out of character," you need to trace whether the prompt was correctly loaded, whether it drifted over turns, and whether a refusal boundary was crossed. Human review trigger: for any response where the model generates code that modifies files, accesses production systems, or handles credentials, route the output to a human reviewer before execution. The persona prompt's safety constraints are probabilistic, not deterministic—treat them as a first line of defense, not a guarantee.

What to avoid: do not place this prompt in the first user message instead of the system message. Models weight system-level instructions differently, and user-message placement invites prompt injection and instruction dilution. Do not modify the persona prompt mid-session without resetting the conversation—partial instruction updates create conflicting behavioral contracts that produce inconsistent responses. Do not skip the eval harness described in the companion Persona Consistency Eval Rubric prompt; run it against every prompt version before release and periodically sample production sessions to detect drift. Start with a short session timeout (20–30 turns) and extend only after you have evidence that persona fidelity holds at longer context lengths.