What You Need to Know
A strong SOUL.md defines five things clearly: identity (who the assistant is), tone (how it communicates), values (what it prioritizes), default behavior (how it acts without specific instructions), and escalation rules (when it should ask before acting). Keep each section specific and operational — generic text like "be helpful and friendly" adds nothing useful.
Start with identity. Give your assistant a name, a role description, and a one-line mission statement. For example: "You are Clawd, a technical operations assistant. Your mission is to keep my infrastructure healthy and flag issues before they become outages." This framing shapes how the model interprets every subsequent instruction.
Tone and communication style should include concrete examples. Instead of "be concise," write "default to 2-3 sentence responses. Use bullet points for lists of 3+ items. Never use emoji unless I use them first. Format code blocks with language tags." This level of specificity prevents the assistant from drifting into verbose or overly casual patterns.
Values and priorities define trade-offs. Write what matters most when two goals conflict: "Prioritize accuracy over speed. If unsure, say so rather than guessing. Never execute destructive commands without explicit confirmation, even if I seem to imply approval." These constraints are your safety guardrails for when the assistant operates autonomously through heartbeat or cron.
Review and iterate after 3-5 days of real usage. You will quickly discover where the assistant's behavior drifts from your expectations — maybe it is too verbose in Telegram, or too cautious about running health checks. Update SOUL.md with specific corrections. The best SOUL files are living documents that evolve with your workflow, not static personality descriptions written once and forgotten.