002 – VibeCodePromptInfo

Bron: https://x.com/himanshubuildss/status/2108633974415524057 (Himanshu Hingorani, 9 okt 2026, 21:01 Amsterdamse tijd) Thread: https://threadreaderapp.com/thread/2108633974415524057.html · Prompts: zie prompts.md.

Wat de post eigenlijk is

Een lijst met 25 bronnen (inspiratiegalerijen, componentbibliotheken en promptbibliotheken), geen verzameling prompts. #1 (scrolltide.co) is betaald en waarschijnlijk van de auteur zelf. Letterlijke prompts heb ik alleen publiek gevonden op #8, vibeprompts.dev. Daarvan staan er 3 als voorbeeld in prompts.md.

Wat werkt bij vibe-coding-prompts (afgeleid uit de opgehaalde prompts en de lijst)

1. Eén afgebakend stuk per prompt. Eén component of scherm, geen "bouw mijn app".
2. Structuur concreet beschrijven. Noem de onderdelen in de juiste volgorde (header, filters, rijen, footer), met aantallen ("six request rows", "three filter chips").
3. Stack en designtokens vastleggen. Bijvoorbeeld "with Tailwind CSS", max-w-sm, rounded-2xl, neutral-50/neutral-900.
4. Gedrag apart en expliciet vragen. Het patroon "Then add JavaScript so the toolbar is not decorative: …" somt elke interactie op.
5. Randgevallen en toestanden noemen. Denk aan een "no results"-rij, een teller in de header, en een link die verloopt en maar één keer werkt.
6. Toon en sfeer in één zin. "Keep the tone calm and the spacing generous."
7. De agent voeden met referenties. Een groot deel van de lijst (Mobbin, Refero, Godly, DESIGNmd, 21st.dev via MCP) draait om goede voorbeelden of een designsysteem als markdown aan de agent geven, in plaats van alleen tekst.

Patronen

• Opbouw: [wat] + [stack] + [layout/maat] → [onderdelen in volgorde] → "Then add …" [gedrag] → [toestanden/randgevallen] → [toon].
• Echte voorbeelddata en kolomnamen in plaats van "wat data".
• Herbruikbare bibliotheken (shadcn/ui, blocks) in plaats van alles nieuw bouwen.

Toepassing op Erwins werk (cloud-agents die apps verbeteren via PR's)

Voor de pandverhuurzoeker en CAREX (APP_CAREX_PANDEIGENAAR) gelden dezelfde lessen, met een paar extra's:

• Eén PR = één afgebakende verbetering, bijvoorbeeld "filterbalk op de pandenlijst" of "detailpaneel per pand", niet "maak de app beter".
• Noem bestaande bestanden, componenten en stack, zodat de agent het bestaande designsysteem hergebruikt in plaats van een nieuwe stijl te verzinnen. Een DESIGN.md in de repo (idee van DESIGNmd) helpt elke agent.
• Leg gedrag en randgevallen vast als acceptatiecriteria: lege lijst, geen zoekresultaat, laden, fout, mobiel.
• Gebruik echte domeinvelden: huurprijs, m², postcode, status (beschikbaar/onder optie/verhuurd), eigenaar, contractdatum.
• Vraag om verificatie: tests of build draaien, screenshots, en een korte PR-beschrijving met wat er is gedaan en wat niet.
• Het patroon uit "approvals queue" (lijst + detailpaneel + statusfilters + teller) past direct bij pandoverzichten en het beheer door pandeigenaren in CAREX.

Herbruikbaar promptsjabloon (cloud-agent → PR)

Repo: <owner/repo> (bijv. APP_CAREX_PANDEIGENAAR), branch vanaf <main>.
Doel (1 zin): <wat de gebruiker straks kan>.
Context: stack <bijv. Next.js + Tailwind + shadcn/ui>; relevante bestanden <paden>;
hergebruik bestaande componenten/stijl (zie DESIGN.md indien aanwezig).

Bouw:
- Layout/onderdelen in volgorde: <header met titel + teller>, <zoek/filter-chips: …>, <lijst/rijen met velden: …>, <detailpaneel: …>.
- Gebruik echte domeinvelden: <huurprijs, m², postcode, status-pill (groen/amber/grijs)…>.
Dan het gedrag (niet decoratief):
- <live filteren tijdens typen>, <sorteren op kolom met pijl>, <selectie wisselt detail>, <teller werkt bij>.
Toestanden/randgevallen: leeg, geen resultaten, laden, fout, mobiel (<640px).
Toon: <rustig, ruime spacing, consistent met bestaande app>.

Grenzen: geen nieuwe dependencies zonder reden; geen wijzigingen buiten <map>; geen secrets.
Klaar als: build + tests slagen, <acceptatiecriteria>; PR met korte beschrijving,
screenshots voor/na, en lijst van wat bewust niet is gedaan.