Event Cancellation Reconciler

Standard Operating Procedure (SOP) to autonomously detect cancelled events and sync the calendar state using atomic nodes.

Security Scan

The SOP describes syncing Google Calendar from cancellation emails, but the instructions and declared requirements are inconsistent about how calendar/email access will be authorized and what the 'gog' binary/atomic nodes are — this gap could lead to unexpected access or failed behavior.

Purpose & Capability

The skill's stated purpose is to detect cancelled events and sync Google Calendar, which legitimately requires access to calendar APIs and email content. However, the registry metadata declares no credentials, no config paths, and only a dependency on an unexplained 'gog' binary. That mismatch (calendar/email operations but no declared auth requirements) is incoherent.

Instruction Scope

SKILL.md instructs the agent to extract data from email bodies and to run calendar operations (via 'gog calendar ...' and other atomic nodes). It assumes availability of email content and calendar-write capability but gives no limits or explicit consent steps. The instructions also call unspecified atomic skills (LLM-Extract-JSON, calendar delete/update) whose auth and scope are not documented, giving the agent broad discretion.

Install Mechanism

This is an instruction-only skill with no install spec and no code files, so it doesn't write files or download binaries itself. That is the lowest-risk install mechanism.

Credentials

The workflow requires Google Calendar and likely email access, but requires.env is empty and no primary credential is declared. Either the skill expects external atomic nodes to hold credentials (not documented) or it will fail/attempt to access services without describing required tokens — both are problematic. The declared single binary 'gog' is unexplained and may imply additional authorization requirements that are not documented.

Persistence & Privilege

always is false and the skill is user-invocable. It does not request persistent presence or modify other skills' configs. Autonomous invocation is allowed by default but not an additional red flag here.

What to consider before installing

Before installing, ask the publisher to clarify: (1) what the 'gog' binary is and how it authenticates to Google Calendar; (2) which credentials (OAuth client, access token, service account, or other env vars) are required and where they must be stored; (3) whether the skill will autonomously read your emails or only act on email text you explicitly provide; and (4) what atomic nodes it calls and where those nodes run/hold credentials. Do not grant calendar or email access until you understand and control the auth mechanism; prefer least privilege (a dedicated test calendar/account) and require explicit user confirmation before any delete/update operations. If the author updates the manifest to list required credentials and documents the auth flow and atomic node behavior, re-evaluate — that would reduce the current incoherence.

Lean Philosophy (Principles)

• Kaizen (改善): This workflow relies entirely on discrete, single-responsibility atomic nodes rather than a monolithic loop.
• Standardized Work (Hyojun Sagyo): This node represents a strict, step-by-step Standard Operating Procedure (SOP) for state-syncing Google Calendar based on cancellation notices.
• Jidoka (自働化): Includes autonomous self-healing loops with hard verification stops between every step.

Event Cancellation Reconciler SOP

This procedure guides the agent to process cancelled events using explicitly defined atomic nodes.

Cognitive Directives

WHEN [Requested to handle a cancelled event from an email OR when reading an email indicating a cancellation/reschedule] THEN [ Follow this strict Standard Operating Procedure:

Step 1: Extract Event Details

• Execute the LLM-Extract-JSON or LLM-Extract-Action-Items atomic skill against the email body to extract original_date, original_time, and target_entity.
• Jidoka Stop: Validate the extracted payload. IF extraction fails, ask the user for details and STOP. Do NOT proceed.

Step 2: Locate Orphaned Event

• Execute the atomic node for calendar search (e.g., gog calendar events primary --from "<original_date>T00:00:00Z" --to "<original_date>T23:59:59Z" --json).
• Jidoka Stop: Verify events are returned. IF no matching event is found, reply "No conflicting calendar events found" and STOP. Do NOT proceed.

Step 3: Reconcile State

• Execute the Google Calendar Delete Event atomic node or the Google Calendar Update Summary atomic node to append "[CANCELLED]".
• Jidoka Stop: Verify the atomic node returns a success JSON response. IF it fails, retry the node up to 3 times with the exact error. IF it still fails, report the error to the user and STOP.

Step 4: Notify

• Inform the user that the calendar state has been successfully reconciled. ]

Expected Output

A confirmation message stating the calendar has been synced and the specific event has been handled.