Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Implement [upload feature] for [specific allowed file types and maximum size] using the existing client, server, and storage design. Trace selection, request, validation, storage, access, and deletion or retention. Treat the supplied filename and media type as untrusted metadata. Define the checks appropriate to the file formats and use generated storage identities rather than client paths.
Show per-file pending, progress where genuinely measurable, accepted, rejected, canceled, and failed states. Define what repeated submission, timeout, partial storage, and retry mean so a successful retry does not silently create unwanted duplicates. Enforce authorization at the trusted boundary.
Use disposable fixtures to check an allowed file, excessive size, misleading metadata, an invalid content case, interruption, and a duplicate attempt. Confirm stored objects and access rules as well as the interface. Report format-validation limits and any cleanup still required.Make this prompt yours
Keep fixture size and content bounded. Use the service’s documented upload guarantees; do not invent resumability or malware scanning.
You might also hear
- file upload
- validation
- multipart
- upload retry
- filename safety
- partial upload
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original upload workflow. OWASP supports treating filenames/media types as untrusted, generated storage names, size/type checks, authorization, and safe storage. Retry/cleanup behavior must follow the actual service contract; no security certification is claimed.