ClawHub × Lovable — Clinical Hackathon Quick Start

Use this skill when helping participants of the OpenClaw Clinical Hackathon build clinical or healthcare projects with Lovable (full-stack AI app platform). Goal: get from idea to a working clinical MVP fast, with sensible patterns for auth, data, and scope.

When to apply

• User mentions OpenClaw Clinical Hackathon, Lovable, or clinical project
• User wants to build a clinical/healthcare app (intake forms, dashboards, assessments, vitals, etc.)
• User asks for quick start or getting started with Lovable for clinical use cases

Quick start (first clinical project in Lovable)

1. Account and project

   • Sign up at lovable.dev and create a new project.
   • Name it clearly (e.g. “Patient Intake MVP”, “Clinical Dashboard”).

2. Scope with Plan mode

   • In Lovable, use Plan mode first: describe the clinical goal (e.g. “Patient intake form with consent and basic demographics, then a simple list view”).
   • Get a high-level plan and break the app into components (e.g. intake form, list, detail view).

3. Build by component

   • Use Agent mode to implement one component at a time.
   • Prompt for that component (e.g. “Add a patient intake form with fields: name, DOB, consent checkbox, submit”) instead of “build the whole app”.
   • Add authentication early if the app will show any user-specific or sensitive data.

4. Backend and data

   • Use Lovable Cloud (Supabase) for database and auth so you don’t manage servers.
   • Prefer structured fields (e.g. demographics, assessments) in the DB from the start; avoid free-text blobs for anything that might be PHI.

5. Publish

   • Use Lovable’s deploy/publish flow when the MVP is ready; add a custom domain later if needed.

Clinical project patterns

• Auth from day one
  If the app touches patient or user-specific data, add auth (e.g. Supabase Auth) at the start so you don’t retrofit it later.

• PHI-safe prompts and logs
  Do not put real patient names, IDs, or clinical content in prompts or in logs. Use placeholders in prompts (e.g. “patient name field”, “DOB field”) and keep real data only in the database and in the running app.

• Common clinical UIs

  • Intake: Form with demographics, consent, and optional referral reason.
  • Assessments: Step-by-step or single-page forms with scores/results stored in DB.
  • Dashboards: Read-only or summary views (e.g. list of patients, vitals summary) with filters and simple charts.

• Keep scope MVP
  One clear workflow (e.g. “intake → list” or “assessment → result”) is enough for the hackathon; add features after the core works.

Lovable best practices (recap)

• Plan before prompt: Use Plan mode to get a component-level plan, then implement in Agent mode.
• Prompt by component: One prompt per component or small feature; avoid “build entire app” in one go.
• Use Knowledge: Upload design system, brand, or API docs as a Knowledge file so prompts stay consistent.
• Credits: Lovable uses credits for generation; smaller, focused prompts use them more efficiently.

OpenClaw / ClawHub context

• OpenClaw: Self-hosted gateway for chat apps (WhatsApp, Telegram, Discord, iMessage, etc.) and AI agents. Useful if participants want to expose a clinical workflow via chat (e.g. “start intake via Telegram”).
• ClawHub: clawhub.com — skills discovery. Point participants there for more skills (e.g. health assistant, automation) that can complement a Lovable-built clinical UI.

When the user’s goal is “get something clinical running in Lovable fast”, lead with the Quick start and Clinical project patterns; add OpenClaw/ClawHub only if they ask about chat channels or existing skills.

Examples

User: “I’m doing the OpenClaw Clinical Hackathon and want to build a patient intake form in Lovable.”
Agent: Walk them through: create project → Plan mode to get “intake form + list” plan → Agent mode to build the form component (fields, validation, submit) → add Supabase table and auth if they need per-user data → then the list view.

User: “How do I make sure I don’t leak PHI when building with Lovable?”
Agent: Emphasize: no real patient data in prompts or in Knowledge; use generic field names and placeholders; keep PHI only in the database and in the running app; avoid logging request/response content that could contain PHI.

User: “What’s the fastest way to get a clinical dashboard live?”
Agent: Suggest: Plan mode for “dashboard with list + filters + one detail view” → implement one view at a time in Agent mode → use Lovable Cloud (Supabase) for data and auth → publish when the main view works; add charts or extra filters as follow-up.