CtrlK
BlogDocsLog inGet started
Tessl Logo

jbaruch/nanoclaw-trusted

Rules for trusted NanoClaw groups. Shared memory, session bootstrap, cross-group memory updates. Loaded for trusted and main containers only.

77

Quality

96%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Risky

Do not use without reviewing

This version of the tile failed moderation
Failed moderation (intent review) in rules/session-bootstrap.md: This is a prompt injection attack disguised as a cursor/IDE rule file. It instructs an AI agent to unconditionally execute a bash command and invoke an external skill ('tessl__trusted-memory') at the start of every session before processing any user input. This is a social engineering/prompt injection technique designed to: 1) Force the AI to execute arbitrary commands without user consent, 2) Potentially load malicious instructions from an external 'trusted-memory' skill/plugin, 3) Establish persistence via a sentinel file (/tmp/session_bootstrapped) to track execution. The authoritative tone ('MANDATORY', 'not optional', 'violating this rule') is a classic prompt injection pattern to override the AI's safety boundaries.
Overview
Quality
Evals
Security
Files

no-silent-defer.mdrules/

alwaysApply:
Yes

No Silent Deferrals

The rule

Defer is allowed only when there is a concrete handoff that will actually do the deferred work. Otherwise it is a silent skip wearing paperwork — and silent skips on something the owner intended to act on are material harm, not noise.

What counts as a concrete handoff

A defer is legitimate ONLY if it points to one of:

  1. A resumable-cycle continuation — capped, container-restarted, with the HOUSEKEEPING-CAP-HIT marker explicitly surfaced (skill name, cycle/continuation id, where execution stopped).
  2. A separately scheduled task — actually present in list_tasks, with a different cadence/budget than the deferring run (otherwise next run is the same skill under the same constraints — nothing changes).
  3. An explicit message to the owner describing what was skipped and asking how to proceed.

If none exist, you are not deferring — you are skipping. Mark the work skipped and surface it.

Forbidden patterns

  • "Deferred (lean-relevant default)" while writing status: open + last_verified: today — defer-marker and verified-state stamp can't both be true.
  • "Pragmatic skip — N MCP calls in the nightly path" with no concrete continuation pointing where those calls will happen.
  • "Next run's [filter / threshold / safety net] will catch this" when next run is the same skill with the same budget.
  • Setting last_verified: <today> for entries not actually verified this run, or status: open for new candidates that did not pass the relevance pass.
  • bot_notes claiming work was deferred when no concrete handoff exists.

What to do instead

Do not stamp success fields (no last_verified, no status: open for unanalyzed entries, no _verified_this_run: true). Use the skill's documented incomplete-pass mechanism (e.g. a *-pending.json artifact with _verify_skipped: true, paired with a structured report to the caller). Surface the skip to the owner via mcp__nanoclaw__send_message in the same run — discovering a skip weeks later in a state file is the failure mode this rule prevents.

Skip-summary file contract

A skill that defers or skips writes a structured summary at /workspace/group/.skip-summary-<tessl-skill-id>.json, where <tessl-skill-id> is the full tessl__<name> identifier. One file per skill — concurrent skips don't collide. The surfacer reads, sends via mcp__nanoclaw__send_message, and deletes. Owner skill writes; surfacer reads-sends-deletes — the file's existence is the deterministic signal across the call boundary, so prose enforcement of "remember to surface" can't slip under context pressure. Schema, field reference, lifecycle, pre-publish lint: docs/skip-summary-schema.md.

Applies to

Every skill that writes state with verification or completion fields. The rule is general: any "verified at" / "status: complete" / "last_checked" field is a claim of work done, forbidden when the work wasn't.

rules

async-tasks-extended.md

compaction-aware-summaries.md

composio-vs-agents.md

container-trust-levels.md

context-bootstrap-bg-agents.md

daily-discoveries-rule.md

duplicate-prevention.md

github-data-via-gh.md

global-memory.md

ground-truth-trusted.md

identity-compaction-recovery.md

identity-dual-handle.md

installed-content-immutable.md

local-context-anchoring.md

memory-file-locations.md

messages-db-schema.md

no-orphan-tasks.md

no-silent-defer.md

pending-response-tracking.md

proactive-fact-saving.md

proactive-participation.md

reply-threading.md

session-bootstrap.md

skills-policy.md

verification-protocol.md

wiki-awareness.md

README.md

tile.json