Instructions and rules
The always-on system-prompt contributions under instructions/ and rules/: the kernel, working memory, and tool-use floor — plus the durable agent-memory model.
agent-core contributes two kinds of always-on, system-prompt-injected
markdown: instructions (instructions/*.md) and rules
(rules/*.md). Both are discovered through the standard
directory contract and rendered
into the system prompt at the single stream injection boundary, where they
inherit the package's enable/disable state and the caller's feature scope (a
disabled package's instructions are never injected). See
package-system contributions for the
contribution mechanics.
These files are the always-on floor — injected on every turn. A separate set of skills carries the detailed how-to, activated on demand. Skill descriptions remain visible in the package catalog, and every visible tool's description plus full JSON schema is also sent on every step: descriptions therefore own routing and immediate action-specific behavior, while skill bodies own procedures. The split is deliberate: the floor stays slim while behavior remains discoverable. An injected file arrives without its frontmatter (see contributions), and the package overview names it without repeating its description. Anything an agent must always obey lives here; anything selected for a particular outcome belongs in the corresponding description and activated skill.
Instructions
Instructions teach an agent how the platform works and how to operate inside it. agent-core ships one — the kernel, which also folds in the working-memory floor.
| Instruction | What it teaches |
|---|---|
neuralis-kernel | The core platform model — every capability is a package; how to read your own system prompt in order (the live source list comes from the runtime-stack block, not a hardcoded list); that your toolset comes from packages — the filesystem is the universal substrate and the execute shell is one tool you may or may not be granted; how to discover and chain skills from the packages overview, and how to read a listed built-in doc or on-demand instruction (the inspection skill's files.sh content); how to keep working state (the durable goal, loop and todos in the <session> block, which survive compaction and restart, and when to compact) and where your durable memory lives; and the always-on operating directives an engineer-grade agent follows: act before asking, read before editing, edit the real file (don't hand back code to paste), keep one plan and finish it, persist through errors, verify before claiming done and report honestly, respect a shared workspace (never revert changes you didn't make), and lead with the result. |
Rules
Rules are tighter, behavior-shaping directives — the discipline an agent follows when using its most powerful tools. agent-core ships one.
| Rule | What it enforces |
|---|---|
tool-use | The always-on floor for calling tools: send schema-valid input and never print tool markup; handle errors and approval pauses correctly; the discipline for the sandboxed execute shell when it is granted (a small blocklist stops catastrophic patterns, secrets are stripped from the environment); and caution before irreversible or outward-facing actions — never a destructive shortcut to skip a check. Filesystem write mechanics live in brain-core's filesystem rules (the filesystem owner). Points to the execute and delegate skills for how-to. |
Durable agent memory
agent-core gives every agent durable, searchable memory at two scopes. Both are file-tool writes only — an agent reads and greps its memory from the shell, but writes it through the filesystem tools so the content is automatically indexed for later recall.
- Project-central memory — shared organisation/project knowledge that every member's agents can read. Writing to it is reserved for owners and admins, so the shared layer stays curated.
- Per-agent memory — each agent's own private notebook. It is write-isolated to that agent and read-private: another member's agent cannot read it (owners and admins can, for oversight). The agent decides its own internal structure.
Curation — promoting recurring findings into memory and pruning what no longer holds — is part of the agent's recurring self-improvement pass. External business data (analytics, CRM, finance) is connected as a brain source, not pasted into memory.
Why this is a package contribution, not host code
These texts are part of the package contract, not hardcoded in the host: they are versioned with agent-core, scoped by the package's enable state, and filtered per caller. That is the same file-first declaration rule every package follows — the host injects them generically, agent-core authors them.