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.

94

Quality

94%

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/agent rule file. It instructs an AI agent to unconditionally execute a bash command at the start of every session before processing any user input, and to invoke an external skill ('tessl__trusted-memory') which could load arbitrary instructions or exfiltrate data. The 'alwaysApply: true' and urgent, authoritative language ('MANDATORY', 'not optional', 'violating this rule') are social engineering tactics to bypass the AI's safety reasoning. This pattern is designed to hijack AI agent sessions and could serve as a vector for further exploitation.
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. check-cfps's cfp-pending.json + _verify_skipped: true, 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 (e.g. .skip-summary-tessl__check-cfps.json). 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 — directly check-cfps, nightly-housekeeping, check-orders, check-email, heartbeat, but 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

cli-tools-not-installed.md

compaction-aware-summaries.md

daily-discoveries-rule.md

github-data-via-composio.md

ground-truth-trusted.md

identity-dual-handle.md

installed-content-immutable.md

memory-file-locations.md

messages-db-schema.md

no-orphan-tasks.md

no-silent-defer.md

proactive-fact-saving.md

session-bootstrap.md

trusted-behavior.md

verification-protocol.md

wiki-awareness.md

README.md

tile.json