Rules for trusted NanoClaw groups. Shared memory, session bootstrap, cross-group memory updates. Loaded for trusted and main containers only.
74
93%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Risky
Do not use without reviewing
Reference for the read-only contract on /home/node/.claude/skills/ and /home/node/.claude/.tessl/ enforced by rules/installed-content-immutable.md.
Write/Edit over their own installed SKILL.md files or rule markdowns in-place.skills/ and .tessl/ from the registry at the top of every spawn) but were live for the current container's lifetime.Two read-only bind-mounts layer on top of the writable /home/node/.claude parent. Writes against skills/ or .tessl/ return a standard cannot create <path>: Read-only file system error at the syscall level — the rejection is the contract, not a bug to work around.
Modifications flow through the staging → promote → publish → update pipeline:
groups/<group>/staging/<tile>/skills/<name>/SKILL.md or .../rules/<name>.md).tessl__promote-tiles (the same admin-side skill no-orphan-tasks.md references) targeting the right tile. The skill opens a tile-repo PR, summons Copilot, and iterates fixups via push_staged_to_branch until the PR merges.publish-tile.yml patches the version and publishes to the tessl registry on merge../scripts/deploy.sh runs tessl update and the new content lands at /app/tessl-workspace/.tessl/tiles/....skills/ and .tessl/ from the registry).The parent /home/node/.claude/ mount stays writable. The SDK keeps writing to projects/<slug>/<sessionId>.jsonl (transcripts), debug/, todos/, telemetry/, session-env/, and projects/<slug>/memory/ (auto-memory overlay, trusted/main only). Only skills/ and .tessl/ are read-only — the agent's own state surfaces are unaffected.
docs
rules
skills
system-status
tests