Cloud Storage

Manage files across cloud providers with authentication, cost awareness, and multi-provider operations.

Security Scan

The skill's instructions and guidance match its stated purpose (multi‑cloud file operations), but it references many sensitive credentials, config files, and token storage practices without declaring required environment variables or provenance—this mismatch and lack of author/source info warrants caution.

Purpose & Capability

The name/description match the content: auth, cost, and provider patterns for S3, GCS, Azure, Backblaze, R2, Drive/Dropbox/OneDrive are all covered. Including consumer providers (Google Drive, Dropbox, OneDrive) is reasonable. The mention of iCloud correctly notes there is no public file API. Overall capability is coherent with purpose.

Instruction Scope

The runtime instructions (auth.md, providers.md) explicitly reference reading and setting environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, GOOGLE_APPLICATION_CREDENTIALS, AZURE_CLIENT_SECRET, etc.), local credential files (~/.aws/credentials, /path/to/key.json), CLI logins (gcloud, az, aws implicit metadata), and storing refresh tokens. The skill manifest lists no required env vars or config paths—SKILL.md therefore accesses sensitive credentials/configuration without declaring them. The instructions do not direct data to unexpected external endpoints beyond the cloud providers, but they do instruct behaviors (storing refresh tokens) that affect sensitive data handling and persistence decisions.

Install Mechanism

Instruction-only skill with no install spec and no code files. This lowers risk from arbitrary code downloads or installation artifacts.

Credentials

The credentials and secrets referenced are directly relevant to cloud storage management (AWS keys, GCP service account JSON, Azure service principal, OAuth refresh tokens). That is proportionate to the stated purpose. However: (1) many different credential types are discussed (broad surface area), (2) the skill does not declare or require any environment variables or a primary credential in its registry metadata, and (3) instructions mention storing refresh tokens without describing secure storage—these are sensitive choices the user should control.

Persistence & Privilege

always:false and no install steps mean the skill does not request forced persistence. As an instruction-only skill it will only act when invoked (or when the agent is allowed to call it). There is no evidence it tries to modify other skills or system-wide agent settings.

What to consider before installing

This skill is functionally coherent for multi‑cloud file operations, but exercise caution before providing credentials. Key points: (1) The skill text explicitly uses and suggests storing highly sensitive secrets (AWS keys, GCP JSON, Azure client secrets, OAuth refresh tokens) but the registry entry declares no required envs or provenance—ask the author how credentials are expected to be provided and stored. (2) Prefer using least-privilege service accounts/app-specific keys and short-lived or instance role credentials rather than long-lived root keys. (3) Confirm where refresh tokens or stored credentials would be kept and who/what can access them. (4) Because this is instruction-only (no install), no code will be written by the skill itself, but if you allow the agent to act autonomously it can call provider APIs using any credentials you provide—restrict autonomous invocation if you are uncomfortable. (5) If you need higher assurance, request the skill’s source/homepage or a signed provenance, or run the agent in a restricted environment with only ephemeral credentials and audit logging enabled.

When to Use

User needs to upload, download, sync, or manage files across cloud storage providers. Agent handles multi-provider operations with cost awareness.

Quick Reference

Topic	File
Provider-specific patterns	providers.md
Authentication setup	auth.md
Cost calculation	costs.md

Scope

This skill covers operational cloud storage tasks across providers:

• S3, GCS, Azure Blob, Backblaze B2, Cloudflare R2
• Google Drive, Dropbox, OneDrive, iCloud

For storage architecture decisions, see storage skill. For S3-specific deep patterns, see s3 skill.

Critical Rules

1. Verify operations completed — API 200 ≠ success; check file exists with correct size/checksum
2. Calculate ALL costs before large transfers — egress fees often exceed storage costs; check costs.md
3. Never delete without backup verification — confirm backup exists AND is restorable before removing source
4. Handle partial failures — long operations fail mid-way; implement checkpoints and resume logic
5. Rate limits vary wildly — Google 750GB/day upload, Dropbox batch limits, S3 3500 PUT/s per prefix

Authentication Traps

• OAuth tokens expire — refresh before long operations, not during
• Service account ≠ user account — different quotas, permissions, audit trails
• Wrong region/endpoint — S3 bucket in eu-west-1 won't work with s3.amazonaws.com
• MFA required — some operations need session tokens, plan for interactive auth

Multi-Provider Gotchas

Concept	Translates differently
Shared folder	Drive "Shared with me" ≠ Dropbox "Team Folders" ≠ OneDrive "SharePoint"
File ID	Drive uses IDs; Dropbox uses paths; S3 uses keys
Versioning	S3 explicit enable; Drive automatic; Dropbox 180 days
Permissions	S3 ACLs + policies; Drive roles; Dropbox link-based

Before Any Bulk Operation

• Estimated time calculated (size ÷ bandwidth)
• Rate limits checked for both source AND destination
• Cost estimate including egress + API calls
• Checkpoint/resume strategy for failures
• Verification method defined (checksum, count, spot-check)