Use the ak:storage S3-compatible integration

The ak-storage export owns the unique runtime identity ak:storage. Use it to work with marketing assets through an S3-compatible client after reviewing the credentials, local paths, object keys, provider effects, and dependency change. The separate ak-ckm-storage export now owns ak:ckm-storage and remains a router with its own operation contract.

Choose ak:storage for the client integration

Supported integration scope

• Upload one local file to a chosen object key.
• Download one object to an approved local path.
• List objects under an optional prefix.
• Remove one object or check whether an object exists.
• Construct an object URL from configuration.
• Preview or perform a recursive local-folder sync.

Choose another workflow when

• You specifically need the list, sync, upload, or url subcommand grammar of the ak:ckm-storage router.
• You need bucket creation, bucket policy changes, signed URLs, versioning, lifecycle rules, migration orchestration, retries, or transactional rollback.
• You need provider-specific support guarantees. Named providers describe compatibility intent, not verified current service behavior.

Prepare credentials and the dependency deliberately

Keep credentials in an ignored local environment file, use a bucket-scoped least-privilege credential, and never paste or print secret values in the Skill prompt or output.

The integration lazy-loads @aws-sdk/client-s3. Installing it with npm install @aws-sdk/client-s3 changes the current project's dependencies and lockfile, so review and approve that mutation separately from storage access. isConfigured() checks only whether the four required variables are present; it does not verify SDK availability, credential validity, connectivity, bucket access, or provider health. Provider-backed operations fail closed when client creation cannot proceed and generally report S3 not configured. That shared message does not distinguish a missing SDK from missing configuration. getPublicUrl() still constructs a string without the SDK or a provider request, while sync dry run can scan and map files when required configuration is present because it does not upload.

Runtime identity status

/ak:storage "Preview syncing ./approved-assets to campaign/launch, show every object key, and wait for approval before any upload"

/ak:storage "Preview syncing ./approved-assets to campaign/launch, show every object key, and wait for approval before any upload"

$ak:storage "Preview syncing ./approved-assets to campaign/launch, show every object key, and wait for approval before any upload"

The Skill source does not define router-style positional subcommands. State the operation, local path, object key or prefix, and approval boundary in the request. Use ak:ckm-storage only when you intend to use that router's distinct argument contract.

Review the client operation contract

These are integration client functions, not the ak:ckm-storage router's user-facing subcommands. Upload and sync infer common content types; unknown extensions use application/octet-stream.

Understand the integration stages

1. Read configuration from environment variables without logging secret values.
2. Lazy-load the AWS S3 SDK and create a path-style client for the configured endpoint.
3. Validate enough local state for the selected operation.
4. Send the corresponding provider request, or construct a URL without a request.
5. Return the operation-specific result: structured result objects for provider operations, an existence result for exists(), or a URL string for getPublicUrl(). Live sync uploads files one at a time and preserves a result for each file.

Cloudflare R2, AWS S3, MinIO, Backblaze B2, and DigitalOcean Spaces are named as compatible examples. Endpoint shape, authentication, public access, availability, pricing, and billing effects still require current verification with the selected provider.

Keep approval and external effects explicit

• Approve dependency installation separately from credential use and storage access.
• Treat download destinations and sync source folders as workspace mutation or data-disclosure boundaries.
• Preview the complete file-to-object mapping before recursive sync. A dry run scans the local folder but does not upload.
• Treat remove as destructive. Require the exact key and explicit approval; the client has no recycle bin or built-in recovery step.
• A URL from getPublicUrl is not proof that the object exists or is public. URL construction does not change bucket policy.
• The client provides no retries, transaction, rollback, or cross-file atomicity. A failed sync can leave earlier files uploaded successfully.

Verify operation evidence

A reviewed integration call should report:

• the selected operation, bucket, endpoint host, local path, and object key or prefix without credential values;
• a preview mapping before recursive sync;
• structured success or failure per object;
• the exact local file written by download, or the key submitted to DeleteObject and its returned result;
• uploaded and failed counts for sync, including partial failures;
• a manual recovery path for any non-atomic result.

Troubleshoot safely

Continue with the Marketing Kit overview, Installing kits, or Runtime adapters.

Know the current limits

• ak:storage identifies the integration; ak:ckm-storage identifies the separate router that depends on this client.
• The integration exposes client operations but no unique positional argument grammar, so requests must state operation and boundaries explicitly.
• Listing is one request without continuation-token pagination.
• Sync is sequential and non-atomic, with no rollback for completed uploads.
• Provider compatibility is shipped intent, not a guarantee of current support, public access, availability, pricing, or billing behavior.