Rules for trusted NanoClaw groups. Shared memory, session bootstrap, cross-group memory updates. Loaded for trusted and main containers only.
72
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
High
Do not use without reviewing
Extends the core ground-truth rule with verification methods available to trusted containers — native Google REST brokered by the OneCLI gateway for Google services (Calendar, Gmail, Tasks) and gh for GitHub.
| Claim type | How to verify |
|---|---|
| Calendar event | google-calendar.py events-list |
| Task/todo status | google-tasks.py list / get |
| Email content | The sanitizing Gmail-fetch skills — see google-access.md "Exception — sanitizing Gmail-fetch skills" |
| GitHub PR/issue | gh — see the github-data-via-gh rule |
Calendar/Tasks op scripts mount at /home/node/.claude/skills/tessl__google-ops/scripts/<script>.py (the google-ops skill in this tile). Invoke them via Skill(skill: "google-ops") or directly at that path. Gmail verification is the separate sanitizing Gmail-fetch path — see the Email row. jbaruch/nanoclaw-admin rules/google-access.md is the authority for op names, arg conventions, and the Gmail-fetch exception — this rule does not restate them.
Authorization: Bearer on the wire.Authorization header yourself. A credential in the container is a bug, not a fallback.google-ops skill — baseline on main and trusted (selectTiles, jbaruch/nanoclaw src/container-runner.ts), so a trusted container has them natively with no containerConfig co-load (jbaruch/nanoclaw-admin#456). The trusted surface is read-only: google-calendar.py events-list and google-tasks.py list-tasklists/list/get.nanoclaw-admin (baseline on main only). A trusted non-main container has no email-verification path — report an email claim as unverified there rather than reaching for a raw fetch.access_restricted (untrusted tier, gated by design): this container has no Google verification path. Report the claim as unverified — do not assert it, do not reach for another route.gh-first, no non-existence claims on unauth 404GitHub state — PRs, issues, repo contents, search results — comes from the authenticated gh CLI inside the container. For the full rationale and command shapes, see the github-data-via-gh rule.
A 404 from curl https://api.github.com/... proves "I cannot see this from this path", not that the resource does not exist. Owner-adjacent repos (jbaruch/*, ligolnik/*, tessl-io/*) may be private to the unauthenticated caller. Re-run the query through gh before asserting non-existence — and especially before retracting a prior statement about something existing on the strength of a 404.
Sub-agent note: Sub-agents spawned via Agent run inside the same container, inherit GITHUB_TOKEN from the env, and see the same script mounts, so both gh and the Google op scripts work inside them.
When a task requires external data, chain tools to compute the exact answer.
Example: "Remind me 15 minutes before I leave for Amir's pickup."
| Approach | Verdict |
|---|---|
| Ask "when do you leave?" | Wrong — you can compute it |
| Set it 15 min before the event start | Wrong — departure ≠ event start |
| Check calendar for destination → Maps for travel time → calculate real departure → set 15 min before | Correct |
These sources are not available in untrusted containers. The core ground-truth rule covers universal verification methods.
.tessl-plugin
rules
skills