What I Built
Vibe‑Code is a prompt‑driven prototype that generates a lightweight content app from a single natural‑language prompt. It produces a live preview UI, a Sanity schema tailored to the prompt, and an optional workflow model for editorial states. The prototype includes a client‑side video → GIF converter demo and integration hints for the Sanity App SDK so judges can see how the app could be extended into a real Studio app.
Demo
Deployed demo: (placeholder — add your deployment URL here)
Walkthrough: the demo shows entering a prompt (e.g., “Playful blog editor with video→gif and review workflow”), generating a preview and schema, uploading a short video, and converting it to a GIF. Screenshots and a short screencast highlight: prompt → generated UI, schema JSON, workflow transitions, and the GIF output. The exported JSON contains the submission template you can paste into DEV.
Code
Repository: (placeholder — add your Git repo URL here)
Included files: index.html, style.css, script.js.
Key implementation notes: the generator is deterministic and local (no LLM calls required to reproduce results); script.js contains commented examples showing how to wire a read‑only Sanity client and where to implement App SDK components and workflow documents. The video→GIF feature uses gif.js for an entirely client‑side proof of concept.
My Build Process
Environment: iterative work inside an AI‑native IDE and a local static prototype; prompts were refined in short cycles.
Prompts that worked: concise, role‑scoped prompts such as “Generate a minimal content app: hero, editor, media array, status field, optional video→gif component, and a 3‑state editorial workflow.” produced coherent schema and UI specs.
Where the model got stuck: early prompts produced overly generic schemas; I fixed this by adding explicit field rationales (why each field exists) and by asking for workflow transitions with actor roles.
Course corrections: I moved heavy or sensitive operations (writes, tokens) to server‑side in the design, kept the client demo read‑only, and documented exact places to add App SDK components and server endpoints.
App SDK and Workflows: I modeled workflows as first‑class documents (workflow with states and transitions) and sketched an App SDK component that subscribes to documents and exposes transition buttons; the prototype includes comments and a minimal example schema to guide implementation.
Sanity Project Details
Project ID: (add your Sanity project ID here)
Public dataset URL: (add public dataset URL if available)
Schema highlights: primary document type vibeContent with fields title, body, media (images/files), status (draft/review/published), and optional gifPreview when video features are requested. The workflow model is a separate workflow document with states and transitions so agents and humans can operate on the same data. All schema decisions include short rationales in the exported JSON to show thoughtfulness.
Agent Session
Transcript: (optional — add link to agent session transcript)
What to include: the prompts used to generate UI, schema, and workflow; the agent’s failures and how I corrected them; any redactions for secrets. Judges will find value in the exact prompt history and the short writeup explaining why each prompt was chosen and how it influenced schema design.
How to reproduce
- Clone the repo and open
index.html. - Enter a descriptive prompt and click Generate Preview & Schema.
- Test the video→GIF demo with a short clip.
- Export the submission JSON and paste it into your DEV post, adding deployment and repo links.
Submission checklist
- Honest build notes with prompts and failures.
- Schema reasoning for each field.
- One bonus: either a small App SDK demo or a modeled workflow document (the prototype includes both hints).
- Sanity project ID or public dataset so judges can inspect structured content.
Top comments (0)