ClawKit for Lovable

ClawKit for Lovable is an independent OpenClaw plugin for people who love Lovable.dev's speed but are tired of wasted credits, invisible changes, fragile generated code, and apps that are hard to maintain after the first exciting demo.

It turns Lovable.dev into one focused UI/product tool inside a larger OpenClaw workflow. Lovable.dev can move fast on screens, layout, product flow, and visual polish. OpenClaw then brings the rest of the toolbelt: GitHub, local code editing, tests, browser verification, refactoring, PRs, project memory, and shipping discipline.

The promise is simple:

Use Lovable.dev for speed. Use ClawKit for Lovable to stop the project becoming expensive, messy, invisible, or impossible to scale.

The install name remains @clawkit/clawkit-for-lovable, and the market-facing product name is ClawKit for Lovable so users searching for Lovable.dev help, Lovable rescue, or Lovable GitHub/refactoring workflows can immediately understand what it does.

ClawKit is independent and is not affiliated with or endorsed by Lovable.dev.

Why Lovable.dev Users Need This

Lovable.dev is powerful, but serious users often hit the same wall:

• Lovable.dev spends credits trying to fix the same issue again and again.
• Lovable.dev says something is done, but the screen does not visibly change.
• The app looks promising, but the generated code is duplicated, brittle, or hard to extend.
• GitHub sync becomes confusing once Lovable.dev, local edits, and PR work overlap.
• Fixing one screen breaks another route, layout, state flow, or build.
• The user needs real engineering tools, not another broad prompt.

ClawKit for Lovable sits above Lovable.dev and helps OpenClaw decide the right next move:

• Run ClawKit for Lovable Brain so the user does not need to know tool names.
• Create a credit-smart plan before spending Lovable.dev credits.
• Send a narrow, high-quality prompt to Lovable.dev only when Lovable.dev is the right tool.
• Stop wasting Lovable.dev credits on jobs OpenClaw should handle directly in code.
• Connect the project to GitHub as the source of truth.
• Verify builds, screenshots, browser state, console errors, and visible results.
• Refactor Lovable.dev-generated code into cleaner, scalable, maintainable architecture.
• Keep project memory, decisions, do-not-change rules, and next actions across sessions.

Credit-Smart Planning

The highest-leverage feature is planning before prompting. A rough idea can burn through Lovable.dev credits if it is sent as one broad request, especially when the project later needs debugging, refactoring, GitHub repair, or production logic.

ClawKit for Lovable adds a Credit-Smart Planning layer:

• Turn a rough app idea into a staged Lovable.dev plan.
• Spend Lovable.dev credits on product shape, screens, visual direction, and workflow clarity.
• Move debugging, refactoring, architecture, tests, GitHub, CI, backend logic, auth, billing, integrations, and security to OpenClaw.
• Create a short prompt sequence with evidence gates instead of endless “try again” prompts.
• Audit a proposed Lovable.dev prompt before credits are spent.
• Stop prompting when the same issue repeats, the build fails, runtime errors appear, or the visible result does not change.

Example request:

I have a rough idea for a client portal. Create a credit-smart Lovable.dev plan first, then give me the smallest prompt sequence that gets the UI direction right without wasting credits on backend details.

ClawKit for Lovable Brain

ClawKit for Lovable Brain is the user-friendly orchestration layer. Instead of asking the user to choose between 30+ tools, OpenClaw can call lovable_brain and get the next best workflow. lovable_studio_brain remains as a backward-compatible alias for earlier installs, but the preferred Lovable product brain is lovable_brain.

The user can simply say:

Build this properly with Lovable.dev and do not waste my credits.

Or:

Rescue this Lovable.dev app and make it production-ready.

The Brain decides whether the situation is a new build, rescue, improvement, hardening pass, PR shipping pass, live publishing pass, or user-orientation moment. It returns:

• The recommended mode.
• The next action and why.
• The tools OpenClaw should use next.
• What to ask the user for, if anything.
• What belongs in Lovable.dev.
• What belongs in OpenClaw/GitHub.
• Stop conditions that prevent credit-wasting prompt loops.
• Evidence needed before accepting “done”.

This makes ClawKit for Lovable feel like a guided product framework rather than a command list.

Early Public Release

ClawKit for Lovable is an early public release. It is useful now for building, rescuing, verifying, refactoring, and shipping Lovable.dev projects with OpenClaw, and it will be updated continuously.

Constructive feedback is very welcome, especially:

• Lovable.dev apps ClawKit for Lovable failed to rescue.
• Workflows that felt confusing.
• Missing verification checks.
• Places where OpenClaw should use Lovable.dev versus code tools differently.
• Ideas for better agency/client delivery reports.

Open an issue or discussion on GitHub:

https://github.com/MarcSean1971/clawkit-for-lovable/issues

Lovable.dev is excellent for UI scaffolding, visual iteration, product flow, and fast app generation. OpenClaw is better at exact code, GitHub, tests, CI, debugging, integrations, browser checks, security, and shipping discipline. This plugin gives OpenClaw tools and a bundled skill for choosing the right surface at the right time.

The plugin assumes Lovable.dev output is a product draft, not finished architecture. OpenClaw should refactor, harden, test, and review the generated code before the app is treated as production-ready.

Product Promise

Build with Lovable.dev's speed. Rescue, verify, refactor, and ship with OpenClaw.

Lovable.dev got you 80% there. ClawKit for Lovable stops the last 20% from eating the whole project.

Users can ask:

My Lovable.dev app looks good but the code is messy and the latest change is not visible. Connect it to GitHub, verify what actually works, refactor the architecture, and prepare a PR.

Or:

Build a polished SaaS onboarding app. Use Lovable.dev for the first UI pass, then use OpenClaw to inspect the repo, fix the hard parts, verify the visible result, and make the code maintainable.

OpenClaw can then:

• Show users what is possible before they start.
• Help users choose a suitable configured OpenClaw model/profile.
• Open Lovable.dev with user approval and walk through the actual platform screens with trusted browser tools.
• Use Lovable MCP when connected, with browser and GitHub fallbacks.
• Turn rough app ideas into credit-smart Lovable.dev plans and strong prompts.
• Diagnose and rescue existing Lovable.dev apps that are broken, messy, invisible, expensive to keep prompting, or hard to extend.
• Launch Lovable.dev's Build-with-URL flow.
• Connect a Lovable.dev project to its GitHub repository workflow.
• Check whether the project is ready for Lovable.dev UI work, OpenClaw engineering, PR, or deploy steps.
• Route UI/product work to Lovable.dev.
• Verify that Lovable.dev's promised changes actually appear on screen.
• Publish or update a live project only after approval, access checks, and live URL verification.
• Route exact engineering work to GitHub and local code tools instead of burning more Lovable.dev credits.
• Keep a reusable project memory brief with URLs, repo state, stack, risks, and do-not-touch rules.
• Maintain a decision log and session brief so each new run starts from the latest agreed source of truth.
• Produce a handoff checklist for PR-quality delivery.
• Generate follow-up Lovable.dev prompts from repo, test, or screenshot findings.

What You Get

With ClawKit for Lovable, OpenClaw can help you move from a fragile Lovable.dev draft to a serious project workflow:

• Better prompts: narrower Lovable.dev prompts with acceptance criteria and preservation rules.
• Credit discipline: stop using Lovable.dev for bugs, refactors, tests, GitHub work, and exact code changes.
• Prompt linting: check a proposed Lovable prompt before spending credits.
• Rescue mode: diagnose blank screens, invisible changes, build errors, runtime failures, routing issues, and messy generated code.
• GitHub handoff: treat GitHub as the source of truth, with branches, PRs, verification notes, and generated-vs-coded sections.
• Visible proof: do not accept “done” until the build works and the expected change appears in browser or screenshot evidence.
• Visual QA: convert desktop/mobile screenshots and browser observations into pass/fail findings.
• Project dashboard: summarize mode, source of truth, status, confidence, blockers, approvals, links, and next best action in one readable card.
• Client handoff: produce a clean report with live/preview/repo links, what was built, verification, access notes, limitations, next steps, and maintenance plan.
• Maintainability pass: refactor Lovable.dev output into cleaner modules, better boundaries, stable state flow, reusable components, and reviewable code.
• Project memory: remember the goal, source of truth, routes, known bugs, decisions, do-not-change rules, and next action.
• Tool routing: let OpenClaw choose Lovable.dev, GitHub, local code tools, browser tools, or PR tooling based on the task.

When To Use It

Use ClawKit for Lovable when:

• You built something in Lovable.dev and now it is buggy, blank, stale, or confusing.
• You are spending too many Lovable.dev credits on repeated fixes.
• Lovable.dev says it changed something but you cannot see the result.
• You want to connect a Lovable.dev app to GitHub and make it production-ready.
• You need cleaner architecture, better components, tests, CI, or PR review.
• You want OpenClaw to decide whether the next step belongs in Lovable.dev or in code.

Tools

Install For Local Development

npm install
npm run build
openclaw plugins install -l .
openclaw gateway restart

Install From ClawHub

openclaw plugins install @clawkit/clawkit-for-lovable
openclaw plugins enable clawkit-for-lovable
openclaw gateway restart

Install From npm

openclaw plugins install npm:@clawkit/clawkit-for-lovable
openclaw plugins enable clawkit-for-lovable
openclaw gateway restart

Lovable Platform Walkthrough

ClawKit can now make Lovable.dev inspection a first-class workflow. lovable_platform_walkthrough_plan tells OpenClaw how to open Lovable.dev, confirm login state, inspect the dashboard/editor/preview/GitHub/status areas, press only approved buttons, and capture screenshots or browser notes.

The plugin itself still does not secretly control the browser. OpenClaw uses its trusted browser capability or the user's own browser session, then passes observations into lovable_platform_observation_report. This keeps the workflow useful and marketplace-safe:

• browser walkthrough for the actual Lovable.dev UI, screenshots, preview behavior, console errors, and visible proof;
• Lovable MCP for programmatic project actions when connected;
• GitHub/OpenClaw for source-of-truth engineering, tests, refactors, and PRs.

Approval is required before submitting prompts that spend credits, changing GitHub connections, deploying, publishing, billing, deleting, or sending private data.

Lovable MCP

Lovable documents an official Lovable MCP server at https://mcp.lovable.dev in research preview. lovable_mcp_connection_plan helps OpenClaw set up or reason about that connection, discover available tools at runtime, and decide when MCP is the right surface.

Use MCP for programmatic Lovable work such as creating projects, sending approved iteration messages, inspecting project state, or checking deployment/status when the connected MCP exposes those tools. Use browser walkthrough when the actual visual result matters. Use GitHub/OpenClaw for exact code, architecture, tests, security, and PR delivery.

Browser opening remains optional. lovable_build_url returns a URL without opening anything. lovable_open_build_url prepares the URL for OpenClaw's trusted browser tool; the plugin itself does not execute shell or browser commands.

{
  "tools": {
    "allow": ["clawkit-for-lovable"]
  }
}

Suggested User Flow

1. OpenClaw calls lovable_brain to choose the mode and next action.
2. OpenClaw calls lovable_user_onboarding or lovable_starter_guide when the user needs orientation.
3. User describes the product or existing app problem.
4. OpenClaw optionally calls lovable_model_strategy.
5. For a new build, OpenClaw calls lovable_credit_smart_plan, lovable_prompt_sequence, and lovable_credit_risk_audit.
6. For an existing broken app, OpenClaw calls lovable_stop_prompting_check, lovable_visible_result_check, and lovable_rescue_plan.
7. OpenClaw calls lovable_decide_route.
8. OpenClaw calls lovable_make_prompt only when Lovable.dev is the right tool.
9. If Lovable MCP is connected or requested, OpenClaw calls lovable_mcp_connection_plan and lovable_mcp_project_workflow.
10. OpenClaw calls lovable_build_url or, with approval, lovable_open_build_url.
11. When actual Lovable.dev UI state matters, OpenClaw calls lovable_platform_walkthrough_plan, uses trusted browser tools, then calls lovable_platform_observation_report.
12. User or OpenClaw monitors the Lovable.dev result.
13. Lovable.dev project is synced/exported to GitHub.
14. OpenClaw calls lovable_connect_github_repo with the repo URL and creates/opens a safe branch with trusted GitHub tools.
15. OpenClaw calls lovable_project_context and lovable_project_memory to create or refresh reusable project memory.
16. OpenClaw calls lovable_session_brief at the start of each later session.
17. OpenClaw calls lovable_next_action_plan to choose the safest next move.
18. OpenClaw calls lovable_project_readiness to check whether enough evidence exists for the next step.
19. OpenClaw gathers Git/package evidence with trusted tools, then runs lovable_repo_doctor and lovable_sync_risk_report.
20. OpenClaw uses GitHub/local tools for code, tests, CI, security, and PR.
21. OpenClaw runs lovable_visible_result_check to confirm the change is actually visible.
22. OpenClaw records important choices with lovable_decision_log.
23. OpenClaw refactors Lovable.dev-generated code for maintainability before shipping.
24. OpenClaw uses lovable_iteration_brief for another UI pass only when useful.
25. OpenClaw uses lovable_pr_summary before opening a PR.
26. If the user wants the app live, OpenClaw runs lovable_publish_readiness, lovable_publish_plan, asks for explicit approval, publishes through Lovable MCP or an approved browser/external deploy route, then runs lovable_publish_result_report.
27. OpenClaw uses lovable_project_dashboard throughout the workflow and lovable_client_handoff_report when the project is ready to review, ship, or hand off.

Prompt Lint, Visual QA, And End-To-End Planning

lovable_prompt_lint is the preflight check before spending Lovable credits. It flags prompts that are too broad, missing preserve/change/avoid/acceptance sections, or asking Lovable to handle work better suited to OpenClaw, such as auth, billing, database, security, tests, CI, deployment, or refactoring.

lovable_visual_qa_report is the post-Lovable visual check. Feed it expected screens/elements plus desktop/mobile screenshot observations, console errors, and network errors. It returns pass, needs-review, or fail with concrete next steps.

lovable_end_to_end_plan is the flagship “take this from idea to live” planner. It lays out the phases from orientation and credit-smart planning through Lovable UI generation, visible verification, GitHub hardening, publish, and client handoff.

Publish Mode

Users can ask:

Use ClawKit to publish this Lovable project.

Or:

Publish the verified version and give me the live URL.

Publishing is intentionally approval-gated because it creates or updates a live site. On some Lovable plans, anyone with the published link can access the app; Business and Enterprise workspaces may allow workspace-only access depending on settings. Project/editor access and published website access are separate.

Publish Mode follows this rhythm:

1. lovable_publish_readiness checks project id/URL, preview URL, build status, visible proof, console errors, secrets/env readiness, desired access, and available publish surface.
2. lovable_publish_plan chooses Lovable MCP, guided browser walkthrough, or GitHub/external deployment.
3. OpenClaw asks for the exact approval phrase: Yes, publish this Lovable project now.
4. lovable_publish_project returns the trusted execution route. The plugin itself does not secretly publish; OpenClaw uses the approved Lovable MCP tool, browser workflow, or external host workflow.
5. lovable_publish_result_report records the live URL, access level, verification, risks, and rollback/unpublish notes.

Use Lovable MCP when connected and a deploy/publish tool is discovered. Use browser walkthrough when the actual Lovable Publish modal needs inspection. Use GitHub/external deployment when the user wants Vercel, Netlify, Railway, VPS, or another host as the production surface.

Dashboard And Handoff

For a friendlier user experience, ClawKit can summarize the whole project in one state card:

Show me the ClawKit dashboard for this Lovable project.

lovable_project_dashboard returns a readable card plus structured fields for the agent: mode, source of truth, status, confidence, credit risk, publish confidence, links, current blocker, next best action, approvals, verified evidence, and risks.

Before publishing, lovable_publish_confidence gives a clear score and verdict such as do-not-publish, needs-review, ready-with-approval, or ready.

When a project is ready for a client, agency, or internal stakeholder, use:

Create a client handoff report.

lovable_client_handoff_report creates a handoff pack with live URL, preview URL, repository URL, what was built, verification, access/ownership notes, known limitations, next recommendations, and maintenance plan.

GitHub Connection

ClawKit does not log in to GitHub, clone repositories, or call GitHub APIs itself. It stays marketplace-safe and tells OpenClaw how to use its trusted GitHub/Git tools.

lovable_connect_github_repo turns a Lovable.dev project URL, GitHub repo URL, and optional trusted repo evidence into a clear plan:

• confirm the repo belongs to the Lovable.dev project;
• clone or open it with OpenClaw's trusted tools;
• create a safe working branch;
• pull Lovable.dev-synced changes;
• run repo doctor and verification checks;
• decide whether the next action belongs in Lovable.dev or code;
• prepare PR-ready evidence.

lovable_project_readiness then acts as a gate before major actions. It checks whether there is a Lovable.dev URL, GitHub repo URL, local repo, clean Git state, safe branch, verification output, visible-result proof, and PR summary.

Project Memory

lovable_project_context gives OpenClaw a reusable brief for each Lovable.dev app. It records the product goal, Lovable.dev URL, GitHub repo URL, local repo path, branch prefix, stack, package manager, verification commands, deployment target, last Lovable.dev prompt, last visible result, repo doctor summary, PR summary, known risks, blockers, and do-not-touch rules.

This is useful because Lovable.dev builds, GitHub sync, local edits, browser verification, and PR work often happen across multiple sessions. The context brief gives OpenClaw a clean source of truth before it chooses whether the next move belongs in Lovable.dev or in code.

Project Memory v1 adds a stronger continuity layer:

• lovable_project_memory records the current goal, source of truth, stack, routes, known bugs, refactor decisions, do-not-change rules, pending Lovable.dev prompts, GitHub tasks, visual QA notes, release readiness, and what changed since last session.
• lovable_decision_log records what was decided, why, who owns it, whether it is accepted or needs revisiting, and follow-up work.
• lovable_session_brief gives OpenClaw a safe opening summary before work begins: current truth, recent changes, do-not-touch rules, risks, and tool order.
• lovable_next_action_plan decides whether the next move should be user clarification, Lovable.dev prompting, GitHub inspection, local code work, visible-result verification, PR preparation, or shipping.

The practical promise is: before every big action, OpenClaw can say what it knows, what changed, and what it will not touch.

Rescue Existing Apps

ClawKit is not only for new builds. It can inspect and fix existing Lovable.dev apps, which is often where users feel the most pain.

Use lovable_rescue_plan when:

• The Lovable.dev app builds but the screen is blank.
• Lovable.dev says a feature exists but it is not visible.
• The app has TypeScript, runtime, route, auth, or data-loading errors.
• The generated code is messy, duplicated, brittle, or hard to extend.
• GitHub sync has become confusing.
• The user wants to make a Lovable.dev app production-ready.

Rescue mode tells OpenClaw what to fix directly in code, what to send back to Lovable.dev as a narrow UI prompt, what evidence is needed, and how to prepare the PR.

Starter Guide

The most important usability feature is education before action. Users should not need to know the tool names.

lovable_starter_guide gives them:

• What ClawKit can do.
• Best first choices.
• Copyable example requests.
• A simple idea-to-PR workflow.
• Decisions they control, including model choice and browser opening.
• Guardrails that explain why the workflow is safer than raw Lovable.dev prompting.

This makes the plugin feel like a friendly framework, not a command list.

Visible Result Verification

Lovable.dev may claim a change is complete while the app screen does not show it because of a programming, routing, state, CSS, or runtime error.

lovable_visible_result_check makes completion evidence-based:

• Build/typecheck/test status.
• Preview URL or local dev server.
• Screenshot/browser observations.
• Console errors.
• Expected visible changes.

If the result is not visible, OpenClaw should fix code errors directly or send Lovable.dev a narrow iteration brief.

Mood Indicator

Programming with AI can feel stressful when the agent misses the point or claims success too early. lovable_mood_indicator turns that moment into a repair loop.

It returns:

• A funny mood label.
• A light humor line.
• A user-care note.
• Self-healing notes for OpenClaw.
• Better next-response guidance.
• De-escalation moves.
• Execution rules for the current stage.

The mood indicator must be kind. It should never mock the user. Its real purpose is to make OpenClaw slow down, verify evidence, and repair the mismatch.

Model Choice

Users can choose the LLM/model profile if their OpenClaw setup has multiple configured models. This plugin does not provide model access itself; it guides selection.

Recommended pattern:

• Strong reasoning model for planning, architecture, security, and review.
• Strong coding model for refactors, tests, APIs, and debugging.
• Fast/cheap model for small prompt drafts and low-risk copy.

ClawKit Sync Doctor

The Sync Doctor is the core product wedge. It helps users avoid the common Lovable.dev/GitHub failure mode: fast visual iteration mixed with unclear Git state.

It checks:

• Whether the folder is a Git repo.
• Current branch and remote.
• Uncommitted changes when checked by OpenClaw's trusted Git/shell tools.
• Recent Lovable.dev-looking commits.
• Framework and package manager.
• Available verification scripts.
• Whether another Lovable.dev prompt is safe.

Use it after every Lovable.dev-to-GitHub sync and before every new broad Lovable.dev prompt.

Code Quality Doctrine

Lovable.dev should be used for speed, UI shape, and product imagination. It should not be trusted to produce clean, scalable, maintainable architecture by default.

OpenClaw should own:

• Refactoring generated components.
• Separating UI, state, data access, business rules, and integrations.
• Removing duplication and dead code.
• Improving names, file boundaries, and module structure.
• Adding tests and verification scripts.
• Reviewing auth, data access, secrets, and production risks.

OpenClaw Inside

Some apps should include OpenClaw as a feature for their own users. This is powerful, but it must be opt-in and designed safely.

Use lovable_openclaw_integration_plan to design it.

Recommended pattern:

• Lovable.dev builds the assistant UI only.
• The app backend mediates all OpenClaw access.
• OpenClaw implements scoped backend endpoints, auth, approval gates, audit logs, tests, and deployment controls.
• The browser never receives OpenClaw secrets or broad tool authority.
• Risky actions require human approval.

Safety Model

The plugin intentionally does not treat Lovable.dev as the source of truth. Lovable.dev is the product/UI accelerator; GitHub is the durable record.

Require user approval before:

• Publishing or deploying.
• Connecting paid services.
• Connecting GitHub on the user's behalf.
• Sending secrets or private production data to Lovable.dev.
• Overwriting production branches or deleting data.

Package Shape

• src/index.ts: OpenClaw plugin entry and registered tools.
• openclaw.plugin.json: native OpenClaw manifest.
• skills/clawkit-for-lovable/SKILL.md: agent behavior policy.
• docs/product-strategy.md: positioning and roadmap.

Roadmap

• Lovable.dev browser walkthrough recipes for common dashboard/project/GitHub/deploy flows.
• Deeper Lovable MCP tool mapping as the research-preview server stabilizes.
• Project URL and screenshot extraction.
• GitHub App/OAuth assisted handoff.
• PR templates with before/after screenshots.
• Policy engine for approval-gated actions.
• Lovable.dev project memory for active builds.