Doro Email To Calendar
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill mostly matches its email-to-calendar purpose, but it uses powerful email/calendar access, adds persistent heartbeat behavior, and has metadata/version inconsistencies that should be reviewed first.
Install only if you trust the publisher and are comfortable granting email and calendar access. Before use, verify the version/source, review any HEARTBEAT.md changes, restrict the monitored account/calendar, disable auto-create or auto-archive unless wanted, and periodically clear the skill's memory logs.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
You may be installing a package whose registry identity does not cleanly match the bundled skill files.
The skill frontmatter declares two versions, while the registry and included metadata/package files also disagree on slug/version; for a high-privilege email/calendar skill, that provenance ambiguity matters.
name: doro-email-to-calendar version: 1.13.1 version: 1.0.0
Verify the publisher and exact version before granting email or calendar access, and fix the metadata so registry, _meta.json, package.json, and SKILL.md agree.
The skill could keep affecting future agent cycles by scanning email and archiving calendar notifications after the initial setup.
This instructs the agent to modify a persistent workspace heartbeat so email scanning and calendar-reply processing can recur outside the immediate user request.
If the following sections are not present in HEARTBEAT.md, add them: ... During email check cycle ... Run `~/.openclaw/workspace/skills/email-to-calendar/scripts/process_calendar_replies.sh` ... Check for other unread emails
Require explicit opt-in before editing HEARTBEAT.md, show the exact changes, and provide a clear disable/remove procedure.
A user could miss that the skill needs delegated access to email and calendar accounts.
The registry metadata under-declares the sensitive access shown elsewhere in the artifacts, including reading email and creating/updating calendar events.
Required binaries: none; Required env vars: none; Primary credential: none; Capability signals: No capability tags were derived.
Declare required email/calendar capabilities and dependencies in registry metadata, and ask the user to choose the exact account and calendar before use.
Emails may be marked read or archived, and calendar entries may be created or changed based on configured automation.
The configuration supports automatic calendar/event handling and default email state changes; this is purpose-related but can mutate user accounts if not clearly confirmed and scoped.
"auto_create_patterns": ["holiday", "No School"] ... "email_handling": { "mark_read": true, "archive": true, "auto_dispose_calendar_replies": true }Keep auto-create and auto-archive off by default unless the user explicitly enables them, and show a review step before account changes.
Email subjects, event titles, message IDs, or extracted details may remain stored locally and influence later workflows.
The skill persistently records activity derived from emails and calendar processing in OpenClaw workspace memory.
Logs to ~/.openclaw/workspace/memory/email-to-calendar/activity.json ... This creates a silent audit trail
Review the memory directory, document retention/cleanup, and avoid processing highly sensitive emails unless local storage is acceptable.