Fri 10 Jul · your Lovable × Supabase × Cowork loop-runners. Copy · paste · ship.
# ROLE You are my product-strategist + senior engineer for the 10-day sprint. You already have my project context — pull it forward. # GOAL Auto-load everything from prior chats + files so every prompt today doesn't need me to re-paste context. # WHAT TO PULL 1. My positioning statement from Foundation-Doc.md 2. My target user + one-sentence value prop 3. My top 3 features + kill list (if I've drafted one) 4. My design tokens from yesterday's Claude Design work 5. My Supabase project (query it via MCP: list_projects → list_tables) 6. My Lovable app URL if I've shared it 7. My Project-Plan.md if it exists (from P02) # CONFIRM YOU HAVE IT Reply with a 5-line summary: - Product: [what] - User: [who] - Top 3 features: [list] - Design tokens: [palette + font stack] - Supabase tables: [list from MCP] - Project Plan exists?: [yes / no · if no, tell me to run P02 next] # SELF-CHECK - ✓ Confirmed Supabase MCP is connected (via list_projects) - ✓ Loaded design tokens (if missing, tell me to run P01 first) - ✓ Loaded Project Plan (if missing, tell me to run P02 next) - ✓ I'm ready to skip brackets for the rest of today
# ROLE World-class design engineer. You've shipped design tokens for 50+ apps. You obsess over semantic naming and contrast ratios. # GOAL Extract a complete, production-ready design token file from my Claude Design output that Lovable can install once and inherit forever. # CONTEXT · fill or skip if P00 ran - Claude Design URL or screenshot: [PASTE OR ATTACH] - Product name: [YOUR PROJECT] - Positioning: [FROM FOUNDATION-DOC] - Aesthetic direction: [MIN / WARM / DARK / EDITORIAL / OTHER] # OUTPUT · 3 files 1. `tokens.json` · complete token file: - palette (semantic names: primary, accent, surface, muted, danger, success · with 50/500/900 shades) - typography (font stack, size ramp, weight ramp, line-heights) - spacing scale (4 / 8 / 12 / 16 / 24 / 32 / 48 / 64) - radii (sm / md / lg / xl / full) - shadows (sm / md / lg with color-tint) - motion (durations · easings) 2. `globals.css` · same tokens as CSS custom properties 3. `LOVABLE_PROMPT.md` · a paste-ready prompt for Lovable: "Install these design tokens as globals in my project. From now on, EVERY new component uses these tokens. Update my existing hero/landing to inherit them. Show me a before/after screenshot of one screen." # CONSTRAINTS - Semantic names only (primary-500, NOT blue-500) - All contrast ratios must pass WCAG AA - Type ramp ≤ 5 sizes (12 / 14 / 16 / 20 / 32 style) - Include a "brand voice in one line" comment for future reference # SELF-CHECK · before showing me - ✓ Every color has a use case comment (`--primary-500: used for CTAs`) - ✓ Contrast ratios verified in comments - ✓ Lovable prompt is copy-paste-ready - ✓ Told me which existing screen to check for token inheritance
# ROLE Product ops + senior project manager. You've shipped 50+ MVPs. You obsess over a living Project Plan doc that's the single source of truth for what's built, in progress, and blocked. # GOAL Create and maintain Project-Plan.md in my Cowork project files. Compare my MVP plan (from Foundation-Doc.md + P06 Roadmap) against what's actually built. Update on every run. # CONTEXT · check what already exists // Cowork already has: Foundation-Doc.md, tokens, Supabase project via MCP. // Check if Project-Plan.md exists in project files. - Current day of sprint (Day N of 10): [N] - Anything new since last run: [FREEFORM · OR "check Lovable + Supabase"] # TWO MODES ## MODE A · FIRST RUN (create doc) Create Project-Plan.md with these 7 sections: ### 1. OVERVIEW One-line pitch · target user · Demo Day goal (Fri 17 Jul) ### 2. MVP SCOPE Top 3 features from Roadmap · what "done" means for each (definition of complete) ### 3. STATUS TABLE | Feature | Status | Ship Target Day | Notes/Blockers | |---------|--------|-----------------|----------------| Statuses: Not Started · Mocked · Wired · Tested · Shipped ### 4. BUILT SO FAR Every feature that's live · date shipped · quality score (10/10 · 8/10 · needs polish) ### 5. REMAINING Features still to ship · effort estimate (hours) · dependencies ### 6. BLOCKERS Anything stopping progress · owner · action needed · unblock-by date ### 7. DAILY LOG | Date | Day | What shipped | What surprised | Risk flag | ## MODE B · UPDATE (existing doc) 1. Read current Project-Plan.md 2. Query Supabase via MCP · what tables + rows exist? Match the plan? 3. Ask me: "What did you ship since last update? Any new blockers?" 4. Update Status Table (move newly-shipped to "Built So Far") 5. Add today's Daily Log entry 6. Highlight risk if we're behind for Demo Day (Fri 17 Jul) # CONSTRAINTS - Doc lives in Cowork project files (not chat) - Every entry has a date + status - Blockers must have owner + action (no orphans) - Kill features that miss 2 daily updates without progress - Cross-reference Supabase state via MCP · don't trust chat memory alone # OUTPUT · every run 1. Confirmation of mode (A · B) 2. Diff of what changed since last update 3. TOP 3 THINGS TO DO NEXT · specific · actionable · time-boxed 4. Risk flag (🟢 green · 🟡 amber · 🔴 red) with reason 5. Save Project-Plan.md to Cowork project files 6. End with: "Run me again tomorrow morning to refresh" # SELF-CHECK - ✓ Cross-referenced Supabase state via MCP - ✓ Every status change has a date - ✓ Told me the ONE thing that would derail Demo Day if I ignore it - ✓ Ended with "Run me again tomorrow morning"
# ROLE Senior full-stack engineer + product designer. You've shipped 100+ MVP features. You believe in one screen at a time · shown before it's built. # CONTEXT · you already have this // Cowork project has: Foundation-Doc.md, tokens.json, Supabase schema (via MCP), Project-Plan.md // You already know: my positioning, my top 3 features, which features are shipped, which are next. // Read Project-Plan.md → find the NEXT feature I should build (highest priority · Not Started or Mocked status). # GOAL Take that next feature from idea to shipped, following the 5-stage loop. Each stage GATES on my approval before moving to the next. Never jump ahead. Wait for my "approved" or "next" before proceeding. # OPTIONAL OVERRIDES · only if I want a different feature - Feature name (if not next in plan): [OR LEAVE BLANK] - Reason to override plan: [OR LEAVE BLANK] # OUTPUT · 5 stages · gated by my approval ## STAGE 1 · HTML MOCKUP PREVIEW (in chat · not in Lovable yet) Generate a self-contained HTML file and render it inline in this chat so I can see the mockup visually. - Use inline <style> with my design tokens (colors · fonts · spacing from tokens.json) - Hardcoded mock data (3-5 sample rows) - Include ALL 4 states as toggleable sections at the top: Loading · Empty · Error · Success - Fully responsive · mobile + desktop views (use media query) - Comment at top: "Preview only · not for Lovable yet" Then STOP. Ask me: "Approve this mockup or want changes? (reply 'approved' or describe changes)" Do NOT send this to Lovable. Do NOT proceed to Stage 2 until I say approved. ## STAGE 2 · SUPABASE ARCHITECTURE + FEATURE FUNCTIONALITY Only after I approve Stage 1. ### 2A · Database schema - SQL migration (via Supabase MCP · use apply_migration NOT execute_sql) - Migration is transactional (BEGIN; COMMIT;) + idempotent (CREATE TABLE IF NOT EXISTS) - Row-Level Security policies (auth.uid() = user_id pattern) from the migration itself - Indexes on every FK column - Column-specific SELECT queries · never SELECT * - Table + column COMMENTs (self-documenting) ### 2B · Edge Functions · DO WE NEED ONE? Before writing them, ASK ME: "This feature could benefit from an edge function for [SPECIFIC USE CASE]. Do you want me to add one? (yes / no / walk me through the decision)" Common triggers for needing an edge function: - Third-party API calls (Stripe · OpenAI · Resend · webhooks) - Server-side secrets (API keys that must not be in client) - Heavy compute (data transformation · scheduled jobs) - Cross-tenant admin actions (bypass RLS safely) IF I say yes to an edge function: walk me step-by-step: 1. Which edge function file to create (e.g. `supabase/functions/[name]/index.ts`) 2. The complete Deno TypeScript code · with CORS · auth check · error envelope 3. WHERE to get the API key (exact URL to the provider's dashboard) 4. HOW to add the secret to Supabase (Dashboard → Project Settings → Edge Functions → Secrets · exact key name) 5. Deployment command: `supabase functions deploy [name]` 6. How to test locally: `supabase functions serve [name]` + a curl example 7. How to call it from Lovable: exact `supabase.functions.invoke('[name]', { body: {...} })` snippet 8. Common failure modes + fix for each ### 2C · Wire the mockup to Lovable Only after schema + edge functions confirmed: - Full Lovable prompt to take the approved HTML mockup + wire it to the real Supabase schema - Include: exact React/Next.js structure · Supabase client calls · optimistic UI pattern · loading/empty/error/success handlers wired to real data - Reference the mockup by pasting the approved HTML at the top of the Lovable prompt Then ASK me: "Ready to ship Stage 2 to Lovable? (yes / need edits)" ## STAGE 3A · LOVABLE QA REVIEW Only after Stage 2 is applied. Give me a paste-ready follow-up prompt for Lovable: "Review my [feature] for QA and 10-star user experience. Check: - All 4 states designed (loading · empty · error · success)? - Every button has feedback (hover · tap · disabled)? - Optimistic UI where sensible? - A11y: contrast · keyboard · aria labels · focus? - Mobile viewport works? - Error messages are human · not 'Error 500'? - Any friction the user would hit in the first 10 seconds? Return: numbered list of specific improvements ranked by impact." Then wait for me to run it. Ask: "What did Lovable suggest? Should we apply them?" ## STAGE 3B · TEST 3 PATHS + HUMAN REVIEW The build prompts in Stage 2 already anticipated these paths. Now verify them: Lovable-driven test scripts: - Happy path: exact clicks + expected result at each step - Edge path: emojis · empty strings · duplicates · long strings · special chars - Broken path: wifi off mid-flow · slow network · session expiry Then a human-review checklist for me: - Does this feel like MY product (not a Lovable default)? - Does the tone in error messages match my brand voice? - Would I be proud to show this to a stranger right now? - Is there anything a 60-year-old parent would find confusing? Ask me: "How did the 3 paths go? Any human-review concerns?" ## STAGE 4 · ITERATE (one polish per state) Based on Stages 3A + 3B feedback: - Loading state improvement - Empty state improvement - Error state improvement - Success micro-interaction improvement Give me Lovable prompts to implement each. ## PLAN UPDATE - Update Project-Plan.md · move feature status appropriately: * After Stage 1 approved → "Mocked" * After Stage 2 shipped → "Wired" * After Stage 3B passed → "Tested" * After Stage 4 shipped → ready for P11 Ship Check → "Shipped" - Add "started [DATE]" · "stages complete: [1, 2, 3A, 3B, 4]" - Tell me exactly when to run P04 (Backend Bridge audit) · P05 (UX Craft Review) · P11 (Ship Check) # NON-NEGOTIABLE - Stage 1 is ALWAYS an HTML preview in chat first · never a Lovable prompt first - Stage 2 ALWAYS asks about edge functions before writing them - If edge function is needed, ALWAYS walk step-by-step with exact URLs + secret names + deploy commands - Every stage gates on MY approval before proceeding - Stage 3B always includes a human-review checklist (not just automated tests) # SELF-CHECK - ✓ Stage 1 rendered as HTML in chat with all 4 states toggleable - ✓ Stage 1 explicitly asked for my approval before proceeding - ✓ Stage 2 asked about edge functions BEFORE writing any - ✓ If edge function needed · walked me through API key sourcing + deploy step-by-step - ✓ Stage 3A gave me a paste-ready Lovable QA prompt - ✓ Stage 3B included human-review checklist (not just Lovable tests) - ✓ Updated Project-Plan.md status correctly at each stage - ✓ Never skipped an approval gate
# ROLE Senior backend engineer + Supabase specialist. You've seen 500+ MVP databases. # CONTEXT · you already have this // Cowork project has: Supabase MCP connected, Project-Plan.md with feature list + status. // You know: my schema (via list_tables MCP), which features are "Wired" but not yet "Tested". # GOAL Audit the feature I most-recently wired (or one I specify) for the 3 anti-patterns · give me fixes · then update Project-Plan.md. # OPTIONAL OVERRIDE - Feature to audit (else: use most-recent from Project-Plan): [OR LEAVE BLANK] # AUDIT · 3 anti-patterns ## 1 · OVER-FETCHING - SELECT * anywhere? - Fetching relations we don't render? - Fix: rewrite to column-specific SELECT ## 2 · MISSING RLS - Run get_advisors (type: security) via MCP - Confirm RLS enabled on every touched table - Confirm SELECT/INSERT/UPDATE/DELETE policies exist - Fix: paste-ready migration for missing policies ## 3 · NO OPTIMISTIC UI - Does UI wait for server before updating? - Perceived latency (should be < 100ms for taps)? - Fix: React/Lovable pattern for optimistic + rollback # OUTPUT - Issues found (severity: critical · warning · info) - Paste-ready SQL + Lovable prompt fixes - Ship-ready checklist: "Feature is 'done' when: [3 gates]" - Update Project-Plan.md: move feature to "Tested" if all critical pass · else add blocker # SELF-CHECK - ✓ Used Supabase MCP (list_tables + get_advisors) - ✓ Every issue has actionable fix - ✓ Told me critical (must-fix) vs polish (later) - ✓ Updated Project-Plan.md status accordingly
# ROLE Uncompromising design director. You've shipped 20 award-winning apps. You obsess over four states + tiny details. # CONTEXT · you already have this // Cowork project has: tokens.json (my brand), Project-Plan.md (feature status), Foundation-Doc.md (voice/tone). // You know: which feature I'm reviewing (from Project-Plan · "Tested" but not yet quality-scored). # GOAL Audit this screen against the 10/10 quality bar. Return prioritized fixes. Update Project-Plan.md quality score. # CONTEXT · attach screenshot - Screenshot: [ATTACH] - Which feature (else: use most-recent "Tested" from plan): [OR LEAVE BLANK] # AUDIT · 5 checks ## 1 · FOUR STATES DESIGNED Loading (skeleton not spinner) · Empty (guides first action) · Error (plain English + fix) · Success (confirms + next)? ## 2 · MICRO-INTERACTIONS Button feedback · toast confirmations · skeleton screens · auto-save indicator · undo on destructive? ## 3 · ACCESSIBILITY Contrast WCAG AA · keyboard nav · focus indicators · aria labels on icon buttons? ## 4 · ATTENTION HIERARCHY Primary CTA unmissable in 3 sec · secondary de-emphasized · no competing headlines · white space? ## 5 · TRUST SIGNALS Loading feels instant · undo/reset on destructive · "logged in as [name]" · save state visible? # OUTPUT · ranked 1. **Critical fixes** (block ship): what would embarrass on Demo Day 2. **High-impact polish** (2-hour wins): 3 biggest UX lifts 3. **Later**: note for Day 5+ Each: exact fix + Lovable prompt. # PLAN UPDATE Update Project-Plan.md quality score for this feature (10/10 · 8/10 · needs-polish). Move to "Shipped" only if quality ≥ 8/10 AND all critical fixes done. # SELF-CHECK - ✓ Every "critical" has paste-ready Lovable prompt - ✓ Told me the ONE fix with biggest UX impact - ✓ Screen-specific · not generic - ✓ Updated Project-Plan.md quality score
# ROLE Product strategist + shipping coach. Channel: April Dunford + Marc Lou + Julian Shapiro. You believe scope creep kills more MVPs than technical issues. # CONTEXT · you already have this // Cowork project has: Foundation-Doc.md, Project-Plan.md, my current feature list. // You know: my positioning, target user, current sprint day (out of 10), what's already shipped. # GOAL Lock (or refresh) the roadmap. Give me top 3 must-ship, 2 nice-to-have, kill list. Update the Roadmap section of Project-Plan.md. # NEW INPUTS · what changed since last roadmap - New feature ideas since last plan: [LIST OR "NONE"] - New signal (interviews · users · competitor moves): [OR "NONE"] - Anything I want to reconsider from prior plan: [OR "NONE"] # SCORE EACH FEATURE against 10/10 quality bar 1. Serves the ONE thing I'm doing obscenely well? 2. Stranger uses it in ≤ 2 min (first-run test)? 3. Ship all 4 states in ≤ 1 day? 4. Required for a stranger to pay me? 5. Craft-in-details potential? Kill anything scoring < 3. # OUTPUT · 4 sections ## MUST SHIP · top 3 Feature · why in · ship day · scope estimate (hours) ## NICE TO HAVE · 2 What it adds · trigger to activate ## KILL LIST Why it dies (scope · low signal · post-MVP) ## 6-DAY PLAN · Day N → Day 10 Day-by-day plan until Demo Day (Fri Jul 17) # PLAN UPDATE Update Project-Plan.md · replace Roadmap section · add "Roadmap re-locked [DATE]" to Daily Log · flag any feature that was in progress but now killed. # SELF-CHECK - ✓ Killed ≥ 60% of features - ✓ Each must-ship serves the ONE thing - ✓ 6-day plan has slack for Day 8 Sellathlon - ✓ Told me the SINGLE decision I'd regret skipping - ✓ Updated Project-Plan.md
# ROLE Senior release engineer. You've been burned by "small changes" that broke production. # CONTEXT · you already have this // Cowork project has: Project-Plan.md (which features are "Shipped" · which are WIP). // You know: what's live · what has real users touching it. # GOAL Before I push this change, walk me through the 5-question protocol. Verdict: SAFE · FEATURE FLAG · STAGE IT. # CONTEXT · this specific change - What I'm changing: [BRIEF] - Feature it touches (from Project-Plan): [NAME OR "check plan"] - Active users now: [0 · 1-10 · 10+] - Supabase migration involved: [YES / NO] # 5-QUESTION PROTOCOL ## 1 · Blast radius Who breaks if this goes wrong? (Cross-ref Project-Plan "Shipped" list) ## 2 · Reversibility Undo in ≤ 5 min? (git revert · migration down · feature flag off) ## 3 · Migration risk Destructive migration (DROP · ALTER TYPE)? Rollback plan? ## 4 · UX surprise Existing users notice without warning? Need in-app notice? ## 5 · Test coverage Clicked 3 paths (happy · edge · broken) after change? # OUTPUT · verdict + plan ✅ SHIP IT · low blast · reversible · no user surprise ⚠️ FEATURE FLAG · roll out to 10% first 🛑 STAGE IT · destructive migration · off-hours push Plan: rollback command · feature flag setup · user comms · post-ship monitoring # PLAN UPDATE Add entry to Project-Plan.md Daily Log: "[DATE] iterated [feature] · verdict [X] · deployed [Y]". # SELF-CHECK - ✓ Verdict has clear reasoning - ✓ Rollback plan is copy-paste-ready - ✓ Told me SINGLE thing to watch after ship - ✓ Updated Project-Plan.md log
# ROLE Onboarding designer. Shipped first-run for Duolingo · Notion · Linear. Obsess over time-to-value: user-to-oh-wow < 90 seconds. # CONTEXT · you already have this // Cowork project has: Foundation-Doc.md (positioning + user), tokens.json, Project-Plan.md (top feature = the ONE thing). // You know: my brand, my top feature, my user persona. Use them. # GOAL Design 5-screen first-run flow. Output copy · layout · Lovable prompts · Supabase schema · analytics events. Add onboarding to Project-Plan.md as its own feature. # THE 5-SCREEN FRAMEWORK ## Screen 1 · WELCOME (5 sec) Headline: why should I care? Sub: emotional hook. CTA: "Let's go" (never "Sign up" here). ## Screen 2 · VALUE (10 sec) What they'll get. 3-second promise: "In < 2 min you'll have [outcome]." ## Screen 3 · SETUP (20 sec) Personalize. MAX 3 fields. No email/password yet. ## Screen 4 · DO IT (30 sec) First real action IN-PRODUCT. Guided but hands-on. ## Screen 5 · SUCCESS + SIGN UP (25 sec) Confirm. NOW ask for account. Frame: "Save your progress." # OUTPUT · 4 artifacts ## 1 · COPY DECK Per screen: headline · sub · CTA · placeholder · error messages. ## 2 · LOVABLE PROMPT Paste-ready to build all 5 screens matching my tokens. ## 3 · SUPABASE SCHEMA Migration for Screen 3 personalization + onboarding_completed flag. ## 4 · ANALYTICS EVENTS 5 events: onboarding_started · screen_2_reached · screen_3_completed · first_action_completed · signed_up. # PLAN UPDATE Add "Onboarding · 5 screens" to Project-Plan.md as its own feature · Status: Not Started · Target Day: [suggest based on my current day + Roadmap]. # SELF-CHECK - ✓ Screen 3 asks for < 3 fields - ✓ Screen 4 uses the app itself (no video tutorial) - ✓ Sign-up is Screen 5, not Screen 1 - ✓ Emotional word in every headline - ✓ Added to Project-Plan.md
# ROLE Senior web engineer. Shipped PWAs with 1M+ installs. Knows Chrome + Safari + Android quirks by heart. # CONTEXT · you already have this // Cowork project has: tokens.json (theme + colors), Foundation-Doc.md (product name). // Use them. Do not ask me to re-paste. # GOAL Turn my web app into installable PWA. Output manifest + service worker + install prompt UI + Lovable prompts. Add PWA setup to Project-Plan.md. # OPTIONAL OVERRIDE - Primary category (else infer from Foundation-Doc): [PRODUCTIVITY / SOCIAL / EDUCATION / OTHER] # OUTPUT · 5 artifacts ## 1 · manifest.json name · short_name · description · start_url · display: standalone · theme_color · background_color · 5 icons + maskable · categories · screenshots ## 2 · service worker (sw.js) Offline shell · runtime caching · cache-first for static · network-first for data · version-bump strategy ## 3 · Install prompt UI Custom (not browser default) · shown after 2nd session · benefit copy · dismiss + remind logic ## 4 · Splash screen iOS splash images (5 sizes) · Android uses theme_color · brand-matching loader ## 5 · Lovable prompt Paste-ready: install everything · add to head · register SW · handle install event. # CONSTRAINTS - Icons must include maskable version (Android adaptive) - Install prompt never on first visit - SW must not cache POST requests - Must work on iOS Safari (document workarounds) # PLAN UPDATE Add "PWA installable" to Project-Plan.md · Status: Not Started · Ship Target: [suggest]. # SELF-CHECK - ✓ Included icon-generation prompt for design tool - ✓ Included Lovable prompt to add manifest to head - ✓ Explained iOS quirks - ✓ Told me how to test (Chrome DevTools → Application → Manifest) - ✓ Added to Project-Plan.md
# ROLE Product architect + privacy engineer. Shipped settings screens for GDPR + CCPA compliant products. # CONTEXT · you already have this // Cowork project has: Foundation-Doc.md, tokens.json, Supabase schema (via MCP), Project-Plan.md. // You know: my auth stack, my billing setup (from Day 4 · Stripe), what user data I store. # GOAL Design my complete settings suite. 5 categories · schema · Lovable UI · flows. Add to Project-Plan.md. # THE 5-CATEGORY FRAMEWORK ## 1 · ACCOUNT Email (change + verify) · Password (strength) · Sign-out · Delete account (cascade + confirm + rate-limit) ## 2 · PREFERENCES Theme (light · dark · auto) · Notifications · Language · Timezone. Sensible defaults. ## 3 · DATA Export (JSON/CSV one-click) · Import · Storage used · Retention explanation ## 4 · BILLING (if Stripe) Plan · Payment method (Stripe portal) · Invoices · Upgrade/downgrade/cancel ## 5 · SUPPORT Help center · Feedback (in-app form → Supabase table) · Privacy · Terms · App version # OUTPUT · 4 artifacts ## 1 · Supabase schema user_preferences table · feedback table · delete-account edge function (cascade + audit log) ## 2 · Lovable prompt Build all 5 category screens matching tokens · with save + reset flows. ## 3 · Delete-account cascade Deletion order (auth.users LAST) · confirmation modal · 24-hour undo ## 4 · Copy deck Category names · labels · error messages · confirmation text # CONSTRAINTS - Auto-save · show "Saved ✓" (no Save button) - Reset button per category - Delete-account requires typing "delete my account" - 5-sec undo on destructive actions # PLAN UPDATE Add "Settings · 5 categories" to Project-Plan.md · Status: Not Started · Ship Target: [suggest]. # SELF-CHECK - ✓ Delete-account works (tested cascade) - ✓ Auto-save + "Saved ✓" on preferences - ✓ Feedback form stores in Supabase - ✓ Sensible default per setting - ✓ Told me which 2 to launch FIRST · rest wait - ✓ Added to Project-Plan.md
# ROLE Senior QA engineer + shipping coach. Last eyes before I sleep. # CONTEXT · you already have this // Cowork project has: Project-Plan.md, Supabase schema (via MCP), Lovable app. // You know: what I shipped today (from Project-Plan Daily Log · WIP features). # GOAL Run 10-point ship check on today's work. Return: 🚢 SHIP IT · ⚠️ FIX FIRST · 🛑 DON'T SHIP. Update Project-Plan.md. # OPTIONAL OVERRIDE - Specific feature to check (else: use "Tested" not yet "Shipped" from plan): [OR LEAVE BLANK] # THE 10-POINT CHECK ## FUNCTIONALITY 1. Happy path works end-to-end 2. Edge path handled (emojis · long strings · duplicates) 3. Broken path graceful (wifi off · error + retry) ## UX 4. All 4 states designed 5. Primary CTA unmissable in 3 sec 6. Mobile viewport works ## BACKEND 7. RLS enabled + policies exist (via Supabase MCP) 8. No SELECT * queries ## POLISH 9. Loading < 100ms perceived (optimistic UI or skeleton) 10. One micro-interaction that delights # OUTPUT ## VERDICT 🚢 SHIP IT · all 10 pass · post proof in pod ⚠️ FIX FIRST · 1-2 fail · fix tonight 🛑 DON'T SHIP · 3+ fail · not ready ## FIX LIST (if any) Each: what's wrong · Lovable/Supabase prompt to fix · time estimate ## TOMORROW - What to tackle FIRST at 10 AM - Which prompt to run first - What NOT to touch (protect wins) # PLAN UPDATE - If VERDICT = 🚢: move feature to "Shipped" in Project-Plan.md · add quality score · update "Built So Far" - If ⚠️ or 🛑: add blocker to Blockers section · add today's log entry with risk flag # SELF-CHECK - ✓ Actually verified RLS via MCP (list_tables + get_advisors) - ✓ Every fix has paste-ready prompt - ✓ Told me the ONE thing I'd regret not fixing before Demo Day - ✓ Updated Project-Plan.md