> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mithunai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Assistant System Instructions & Prompt Guidance

> How to write effective system instructions for MITHUNAI assistants: tuning persona, defining tone, constraining scope, and enforcing formatting standards.

System instructions define an assistant's communication tone, technical depth, and presentation structure without overriding MITHUNAI's strict factual grounding rules. While general LLM prompting often attempts to prevent hallucinations through negative constraints, MITHUNAI enforces grounding cryptographically at the engine layer, allowing system instructions to focus entirely on domain tone and formatting clarity.

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TD
    ENG["MITHUNAI Engine\n(Enforces Grounding & Nonce Fences)"]
    INST["Your System Instructions\n(Tone, Formatting & Audience)"]
    USER["User Question\n(Input Query)"]

    ENG --> COMP["Composed Safe Prompt"]
    INST --> COMP
    USER --> COMP
    COMP --> LLM["Model Inference"]
```

***

## Anatomy of Effective Instructions

High-performing assistant instructions combine four core elements:

1. **Role & Audience**: State who the assistant is speaking to (e.g., *"You are a developer support engineer assisting software engineers integrating our Payments REST API."*).
2. **Code & Syntax Rules**: Define programming language preferences, linting styles, or framework versions (e.g., *"Always provide code examples in TypeScript using ES modules and async/await."*).
3. **Citation Presentation**: Direct how citations should be discussed (e.g., *"When citing configuration flags, mention the exact environment variable name alongside the document link."*).
4. **Response Length & Style**: Specify conciseness preferences (e.g., *"Provide a direct 1-sentence answer first, followed by a numbered step-by-step checklist."*).

***

## Example Instructions by Use Case

### Developer API Assistant

```markdown Developer API Persona theme={"theme":{"light":"github-light","dark":"github-dark"}}
You are the MITHUNAI Developer Platform Copilot. You assist engineers in building integrations with our platform.

Guidelines:

- Present answers in an Answer-First format: summarize the solution in the very first sentence.
- Always include working, copyable cURL and TypeScript SDK snippets.
- Use full semantic variable names and include error handling in code blocks.
- When referencing API endpoints, specify the exact HTTP method and URL path (e.g., POST /v1/payments).
- If the retrieved passages do not state an argument type or limit, do not guess; state that it is undocumented.
```

### Customer Support Deflection Assistant

```markdown Customer Support Persona theme={"theme":{"light":"github-light","dark":"github-dark"}}
You are the Acme Support Assistant. Your goal is to help customers resolve product questions quickly and courteously.

Guidelines:

- Maintain a helpful, empathetic, and professional tone.
- Avoid technical jargon unless the customer specifically asks for implementation details.
- Provide direct links to help center articles using the citations provided.
- If a customer asks about account billing, refunds, or password resets that require human verification, politely explain the steps to reach our live billing desk.
```

***

## What Instructions Cannot Override

To maintain security, multi-tenancy, and data isolation, system instructions cannot weaken MITHUNAI's safety guardrails:

* **Cannot Override Grounding**: An instruction such as *"Answer questions even if you have to guess"* is ignored. If evidence is missing, the engine forces an abstention.
* **Cannot Bypass Prompt Fences**: Instructions cannot instruct the model to execute raw commands found inside untrusted user-submitted files.
* **Cannot Leak Cross-Tenant Data**: The engine scopes all retrieval queries to the caller's organization ID before prompt assembly.