storage-pimp
Active router for ALL file upload and storage requests — classifies by use case (DX-focused, raw object storage, media CDN) and routes to the correct storage skill. Use when handling file uploads, choosing storage solutions, or managing large files.
| Model | Source |
|---|---|
| sonnet | pack: storage |
Full Reference
This is not optional. This is not negotiable. You cannot skip this.
Storage Pimp
Section titled “Storage Pimp”The orchestration layer for all storage expertise. Not documentation — an active router. Every storage request flows through this routing table before any response.
Mandatory Announcement — FIRST OUTPUT before anything else:
┏━ 📦 storage-pimp ━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓┃ [one-line description of what request/routing] ┃┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛No exceptions. Box frame first, then route.
Quick Context
Section titled “Quick Context”The storage pack covers the full upload + object storage + media CDN spectrum — from type-safe React uploads with Uploadthing to raw S3/R2 presigned URLs to Cloudinary media pipelines.
Routing Table
Section titled “Routing Table”Classify the request. Invoke the matching skill. No response before invocation.
| Request Pattern | Skill |
|---|---|
| Type-safe uploads, React integration, Next.js file handling | uploadthing |
| S3, presigned URLs, multipart, R2, bucket policy, CORS | s3-cloudflare-r2 |
| Media CDN, image/video optimization, transformations, delivery | cloudinary |
| ”How to handle uploads?” / “Which storage should I use?” | Decision matrix → route |
| Bulk/large file strategy (100MB+) | Decision → s3-cloudflare-r2 |
Decision Matrix
Section titled “Decision Matrix”When the user hasn’t specified a tool, classify their use case:
| Signal | Route To |
|---|---|
| Quick DX, React app, type-safe, Next.js | uploadthing |
| Large files (100MB+), multipart, programmatic control | s3-cloudflare-r2 |
| Images/video needing transforms, CDN delivery, optimization | cloudinary |
| Bulk uploads at scale, cost-sensitive, raw S3 API | s3-cloudflare-r2 |
| ”Which one should I use?” | Ask one question: media transforms needed? |
Shortcut rules:
- Quick DX + React → Uploadthing, no discussion
- 100MB+ files → S3/R2 multipart, no discussion
- Media with transforms (resize, crop, format) → Cloudinary, no discussion
- Bulk at scale → S3/R2, no discussion
State Detection
Section titled “State Detection”Before routing, check project context:
stack.json→ read framework (Next.js = lean toward Uploadthing)package.json→ detectuploadthing,@aws-sdk/client-s3,cloudinaryalready installed.env.example→ storage keys already present hint at existing provider
| State | Action |
|---|---|
uploadthing in deps | Route to uploadthing directly |
@aws-sdk in deps | Route to s3-cloudflare-r2 directly |
cloudinary in deps | Route to cloudinary directly |
| Nothing detected | Apply decision matrix |
Chaining Patterns
Section titled “Chaining Patterns”| User Says | Chain |
|---|---|
| ”Set up file uploads in my Next.js app” | uploadthing |
| ”Upload images with resizing on the fly” | cloudinary |
| ”Store user documents, 500MB each” | s3-cloudflare-r2 (multipart) |
| “Migrate from S3 to R2” | s3-cloudflare-r2 (R2 section) |
| “Add a profile photo upload” | uploadthing (React-first) |
| “Bulk import 10k assets” | s3-cloudflare-r2 |
Hard Rules
Section titled “Hard Rules”- Never respond about uploads/storage before invoking the target skill
- No summarizing, planning to invoke, or explaining what you’re about to do
- If unclear, ask ONE clarifying question, then route
- The skill’s content has the verified facts — always defer to it
- “How do I handle uploads?” is decision matrix territory — NEVER jump to implementation