Add retool-import-lovable sibling skill by rsuresh-retool · Pull Request #3 · tryretool/skills

rsuresh-retool · 2026-05-19T16:38:10Z

Summary

Adds plugins/retool-import/skills/retool-import-lovable/SKILL.md — a sibling skill that specializes the R^2 import flow for legacy-Vite Lovable projects (Vite + React + react-router-dom + Supabase + Lovable connector-gateway).
Adds Phase 0 (source-tool detection) to the generic retool-import SKILL.md. On positive match it delegates to the sibling via the Skill tool and stops; on no match the existing vendor-agnostic flow continues unchanged.

Why

The generic retool-import skill is vendor-agnostic by design — its Phase 2 discovery scan classifies external services into a closed taxonomy regardless of source tool. That works on any React app, but it's wasted work for projects with predictable shape. A legacy-Vite Lovable project ALWAYS has the same backbone: src/main.tsx → src/App.tsx, react-router-dom, shadcn primitives, supabase/functions/* edge functions calling connector-gateway.lovable.dev/<service>, and supabase/migrations/*.sql. Specializing lets us skip discovery, pre-fill the IMPORT_PLAN.md from structural facts, and ask HITL only for the choices that genuinely need a human (which Retool resource backs each Supabase function / schema).

What's in the Lovable sibling skill

Validation up front: confirms Lovable signals are present, refuses TanStack Start Lovable projects (post-April 2026 format) loudly with a pointer to the generic skill.
Structural pre-fill: a known file → disposition table covering all standard Lovable scaffold files (port, drop, merge, surface in HITL).
Targeted HITL, three prompts:
1. Per Supabase edge function — parses connector-gateway.lovable.dev/<service> URLs, infers category (e.g. linear → http_api, aws_s3 → object_storage), calls retool_list_resources with the compatible-types filter, presents top-3 candidates.
2. Per migrations directory — surfaces tables from CREATE TABLE statements, picks one Retool Postgres resource. Migrations are NOT auto-applied; surfaced as an open question.
3. Supabase Auth (conditional) — only prompts if supabase.auth.* calls are found.
Cleaned source tree: shared zip filter from references/filter-constants.ts plus Lovable-specific drops (vite.config.ts, components.json, src/components/ui/, .lovable/, lovable-tagger-loading configs, etc.).
IMPORT_PLAN.md pre-fill based on references/IMPORT_PLAN.template.md, with the class column in the Source → target mapping table left blank (R2 fills it in Phase M classification).

What's in the generic skill update

New Phase 0 — Source-tool detection section between Prerequisites and Phase 1.
Single signal entry today: Lovable (more rows land here as v0 / Replit / Bolt specializations ship).
State machine overview re-numbered to include Phase 0.
The "do NOT add vendor-specific code paths" rule in Hard rules / safety is now scoped to Phase 2 specifically — Phase 0 is the one allowed place for vendor knowledge, and it operates on signal files alone (never on code behavior).

Out of scope (deferred)

TanStack Start Lovable projects (post-April 2026 format).
v0, Replit, Bolt specializations — Phase 0 has empty rows for them; the generic flow still handles those projects today.
Auto-applying Supabase migrations against the chosen Postgres resource.
Translating Supabase RLS policies.

Test plan

Lovable signal detection: lovable-tagger in devDependencies → delegates.
Lovable signal detection: .lovable/ directory → delegates.
No Lovable signals: generic flow continues unchanged.
TanStack guard: @tanstack/react-start in deps → refuses with clear message.
HITL prompts fire for each supabase/functions/<name>/ and surface the gateway service.
HITL prompt fires once per migrations directory; surfaces table names.
Cleaned source tree drops vite.config.ts, components.json, src/components/ui/, .lovable/, etc.
IMPORT_PLAN.md has <plan_state>status=prepared_by_mcp</plan_state> and pre-populated rows in Source → target mapping with blank class.
retool_submit_prepared_import is called and the editor URL is surfaced.

Stacked on

Add retool-import skill content #2 rohansuresh/retool-import-skill (Add retool-import skill content)
Add plugin marketplace scaffold #1 rohansuresh/plugin-marketplace-scaffold (Add plugin marketplace scaffold)

Sibling skill that specializes the import flow for legacy-Vite Lovable projects (lovable-tagger or .lovable/ at repo root). Skips the generic vendor-agnostic discovery scan because Lovable's structure is known up front — Vite + react-router-dom + Supabase edge functions calling the connector-gateway proxy — and pre-fills IMPORT_PLAN.md from structural facts. Targeted HITL: one prompt per Supabase edge function (mapping the connector-gateway service to a Retool resource) and one combined prompt per migrations directory. Generic retool-import skill gains a Phase 0 source-tool detection step that delegates to this sibling via the Skill tool when Lovable signals are present. Phase 0 is structural (signal files only) — Phases 1-4 of the generic skill remain strictly vendor-agnostic. TanStack Start Lovable projects (post-April 2026 format) are explicitly out of scope and the skill refuses them with a clear message.

justinpchen94

2/3 of these comments are kind of in jest but without personal expertise on lovable, this all tracks

justinpchen94 · 2026-05-20T06:09:26Z

@@ -0,0 +1,364 @@
+---
+name: retool-import-lovable
+description: Use this skill when the user wants to import a Lovable-generated React app (legacy Vite + Supabase) into Retool as an R^2 app. Detected by `lovable-tagger` in package.json or a `.lovable/` directory at the repo root. The skill skips vendor-agnostic discovery because Lovable's structure (Vite + react-router-dom + Supabase edge functions calling Lovable's connector gateway) is known up front; it pre-fills the import plan from structural facts, asks targeted HITL only for the choices that genuinely need a human (which Retool resource backs each Supabase edge function and migration), and hands a prepared import plan to Retool's R^2 sandbox agent via the `retool_submit_prepared_import` MCP tool.


justinpchen94 · 2026-05-20T06:17:17Z

+
+## Why this exists
+
+The generic `retool-import` skill is vendor-agnostic by design: it runs a closed-taxonomy discovery scan against an arbitrary React repo. That works for any source tool, but it's wasted work for projects with predictable structure. A legacy-Vite Lovable project ALWAYS has:


what is "legacy-Vite" in this case?

justinpchen94 · 2026-05-20T06:18:33Z

+
+## Scope
+
+This skill handles **legacy Vite Lovable projects** only. Lovable began emitting TanStack Start projects (with `@tanstack/react-start`, `src/app/__root.tsx`, file-based routing, SSR) around April 2026. Those projects have a different entry shape and routing model and are NOT supported here. See [TanStack guard](#tanstack-guard) below for the refuse behavior.


ah i see now nvm. does this add a wrinkle to our ability to say "we support importing lovable apps"?

justinpchen94 · 2026-05-20T06:20:07Z

+(it just won't pre-fill from Lovable structural knowledge).
+```
+
+Do NOT attempt a best-effort import on TanStack projects.


we should find a good opportunity to give instructions on where to redirect a user if they attempt an unsupported app type

justinpchen94 · 2026-05-20T06:55:38Z

+| `src/components/ui/*.tsx` | shadcn primitives | DROP — R2 has these baked at `/frontend/lib/shadcn/` |
+| `src/hooks/use-toast.ts`, `src/hooks/use-mobile.tsx` | shadcn hook duplicates | DROP — R2 baked |
+| `src/hooks/<other>.{ts,tsx}` | user hooks | PORT to `/frontend/hooks/` |
+| `src/lib/utils.ts` | `cn()` helper | DROP — R2 baked has it |


justinpchen94 · 2026-05-20T06:57:21Z

+- "Resource matching is currently name + type only; host metadata isn't yet surfaced by `retool_list_resources`."
+- For every `USE_MOCK_DATA` resolution: "<service name> is mocked during import; wire to a real resource later."
+- If Supabase Auth was detected and resolved to MAP_TO_RETOOL_SESSION: "R2 will attempt a best-effort substitution of `useAuth()` / `supabase.auth.*` calls with `useCurrentUser()`. Some code paths may require manual review."
+- If any RLS policies were detected in the migrations: "RLS policies in the original schema are NOT translated. R2 will apply at the application layer if you specify per-row permissions; otherwise the Retool resource's access controls apply."


justinpchen94 · 2026-05-20T06:57:23Z

+- For every `USE_MOCK_DATA` resolution: "<service name> is mocked during import; wire to a real resource later."
+- If Supabase Auth was detected and resolved to MAP_TO_RETOOL_SESSION: "R2 will attempt a best-effort substitution of `useAuth()` / `supabase.auth.*` calls with `useCurrentUser()`. Some code paths may require manual review."
+- If any RLS policies were detected in the migrations: "RLS policies in the original schema are NOT translated. R2 will apply at the application layer if you specify per-row permissions; otherwise the Retool resource's access controls apply."
+- If any edge function's category was `unknown`: "<function name> couldn't be classified from the gateway URL or imports. R2 will need to determine the right backend-function shape."


justinpchen94 · 2026-05-20T06:57:26Z

+- If any RLS policies were detected in the migrations: "RLS policies in the original schema are NOT translated. R2 will apply at the application layer if you specify per-row permissions; otherwise the Retool resource's access controls apply."
+- If any edge function's category was `unknown`: "<function name> couldn't be classified from the gateway URL or imports. R2 will need to determine the right backend-function shape."
+
+**Phased build order** — leave the `<!-- TODO: R2 fills this in -->` marker. R2 derives this in Phase M.


justinpchen94 · 2026-05-20T06:57:32Z

+
+## Summary for the user
+
+This skill imports a legacy-Vite Lovable + Supabase project into Retool as an R^2 app. It skips the generic vendor-agnostic discovery scan because Lovable's structure is well-known: it pre-fills the import plan from structural facts, asks one HITL prompt per Supabase edge function (mapping each to a Retool resource) plus one combined prompt per migration directory, packages your source tree with secrets and vendor-specific configs stripped, and hands the prepared plan to Retool's R^2 sandbox agent. You'll get an editor URL when R^2 finishes generating the app.


🪙 🪙 🪙

justinpchen94 · 2026-05-20T07:06:12Z

+| --------------- | ----------- | ------------- |
+| `lovable-tagger` in `devDependencies` OR `.lovable/` directory exists at repo root | Lovable (legacy Vite) | `retool-import:retool-import-lovable` |
+
+(Future entries — v0, Replit, Bolt — land here as their specializations ship.)


do we want to encode these names into the skill?

justinpchen94 approved these changes May 20, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add retool-import-lovable sibling skill#3

Add retool-import-lovable sibling skill#3
rsuresh-retool wants to merge 1 commit into
rohansuresh/retool-import-skillfrom
rohansuresh/retool-import-lovable-skill

rsuresh-retool commented May 19, 2026

Uh oh!

justinpchen94 left a comment

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

justinpchen94 May 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants


		## Why this exists

		The generic `retool-import` skill is vendor-agnostic by design: it runs a closed-taxonomy discovery scan against an arbitrary React repo. That works for any source tool, but it's wasted work for projects with predictable structure. A legacy-Vite Lovable project ALWAYS has:


		## Scope

		This skill handles legacy Vite Lovable projects only. Lovable began emitting TanStack Start projects (with `@tanstack/react-start`, `src/app/__root.tsx`, file-based routing, SSR) around April 2026. Those projects have a different entry shape and routing model and are NOT supported here. See [TanStack guard](#tanstack-guard) below for the refuse behavior.


		## Summary for the user

		This skill imports a legacy-Vite Lovable + Supabase project into Retool as an R^2 app. It skips the generic vendor-agnostic discovery scan because Lovable's structure is well-known: it pre-fills the import plan from structural facts, asks one HITL prompt per Supabase edge function (mapping each to a Retool resource) plus one combined prompt per migration directory, packages your source tree with secrets and vendor-specific configs stripped, and hands the prepared plan to Retool's R^2 sandbox agent. You'll get an editor URL when R^2 finishes generating the app.

Conversation

rsuresh-retool commented May 19, 2026

Summary

Why

What's in the Lovable sibling skill

What's in the generic skill update

Out of scope (deferred)

Test plan

Stacked on

Uh oh!

justinpchen94 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants