TripIt
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill mostly matches its TripIt purpose, but it advises storing a private TripIt calendar feed URL, which could allow ongoing access to the user's travel plans without clear retention or deletion controls.
Only install this if you are comfortable letting the agent prepare TripIt emails and, if you choose, verify them through your private calendar feed. Do not let it store your TripIt iCal URL unless you understand where it will be saved, how it will be protected, and how you can delete or regenerate it.
Findings (3)
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.
A mistaken or premature send could add incorrect travel items to the user's TripIt account.
The skill depends on another email-sending tool to submit travel data to TripIt, which is expected for the stated purpose but can modify the user's TripIt plans if used incorrectly.
The script outputs the email body. You send it using whatever email tool is available.
Confirm the recipient, email body, and key itinerary details with the user before sending to TripIt.
The skill can act through the user's email account to affect their TripIt itinerary.
The workflow uses the user's linked email identity as the authority to create or update TripIt travel plans. This is disclosed and purpose-aligned, but it is still delegated account authority.
The sender email must be associated with the user's TripIt account.
Use only an email account the user intentionally linked to TripIt, and ask before sending any itinerary-changing email.
If stored carelessly or reused outside the intended task, the URL could provide ongoing access to the user's private travel calendar.
A private TripIt iCal URL can expose itinerary details through a long-lived bearer-style link. The skill recommends persistent storage without specifying explicit consent, storage protections, retention, deletion, or limits on future reuse.
Tip: Store the user's iCal feed URL so you can verify future sends without asking again. The URL is stable — it doesn't change unless the user regenerates it.
Store the iCal URL only with explicit user permission, keep it in a protected user-controlled location, document how to delete it, and avoid reusing it except for user-requested verification.