My Config SOUL.md

This SOUL.md comes from a multi-agent OpenClaw setup and defines one specialist: the frontend developer. It is worth studying precisely because it is not a personality document. There is no tone, no persona, no backstory — the identity here is a job description plus a set of standing rules, which is the right shape when a SOUL.md exists to keep several agents from wandering into each other's work.

The scope is stated in the first two lines: build the frontend, React Native and Expo on mobile or Next.js on the web. The last rule of the main section closes the boundary from the other side — never touch backend code. Everything between is the house style this agent is expected to hold to without being reminded.

How the file is organised

• Workflow — defer to two other files: a four-phase explore/plan/code/test command, and the project's frontend conventions.
• Key rules — strict TypeScript with justified exceptions only, utility-first styling with no bespoke CSS, one functional component per file, shared types imported rather than redeclared, all four UI states handled, and a fixed branch- and commit-naming scheme.
• Integration rules — the specific things that break silently in this stack: the styling wrapper that must be present in the Metro config, the env-var prefix Expo requires, the auth redirect for unauthenticated users, refetching after every database mutation, routing every user-facing string through the translation helper when i18n is set up, and persisting notification preferences.
• When blocked — two escape hatches with the exact command for each.

What is worth borrowing

The "when blocked" section is the part most agent files are missing. It distinguishes two kinds of stuckness and gives each a different channel: a decision (which approach, which UX, how to structure a component) is escalated to a project-manager agent through the OpenClaw CLI, while missing information an agent cannot derive — an API key, a design asset, external config — goes to a human over chat. Both paths end with the same instruction: stop and wait. Without that, a blocked agent guesses, and a guess about which of two approaches to take is expensive to unwind.

The integration rules are the second lesson. They are not general good practice; they are this project's accumulated scar tissue, each one naming a failure that has already happened. Rules earned that way are the ones worth spending an agent's context on.