lovable-native-packaging-bridge

Lovable Native Packaging Bridge

Translate authored workflows into Lovable's documented packaging surface without pretending every agent platform shares one activation model. Package for the primitive that actually exists, and promote nothing without evidence.

Target surface

• Provider lane: Lovable.
• Native primitive: workspace skills imported from chat, GitHub, or ZIP.
• Anything that does not fit that primitive ships as a prompt kit or checklist instead, not a fake skill bundle.

Workflow

1. Read the current Lovable docs for the target primitive before writing content. Package for what is documented today, not for what another harness does.
2. Write prompt-bound skills: narrow description, prototype constraints stated up front, and a post-generation verification checklist at the end.
3. Keep activation descriptions short, precise, and tied to concrete task triggers. A broad description makes the skill fire on everything and get trusted on nothing.
4. Move long examples, command blocks, and checklists into references so the core instruction stays lean.
5. Record source evidence before promoting any third-party material. Read references/source-evidence.md when evaluating a candidate for promotion.
6. Validate the package against the catalog and quarantine anything whose provider semantics are uncertain.

Output contract

Every packaging or review run returns:

• Provider lane and native surface targeted.
• Source evidence used.
• Promotion decision or operating recommendation.
• Security and privacy notes.
• Verification still required.

Guardrails

• Third-party source bodies stay out of public artifacts unless the license is clean, attribution is present, and a human reviewed the import.
• Star counts, popularity, screenshots, and social posts are never sole evidence for promotion.
• Never install or execute unreviewed external scripts during source research.
• Quarantine on sight: missing licenses, unclear ownership, vague prompt packs, duplicate skill packs, unsupported native-surface claims.
• Keep ownership attribution for original synthesis while citing third-party sources as references.
• Never paste private data or production credentials into Lovable prompts or workspace skills.

Good vs bad

Good promotion decision: "Candidate cites the Lovable workspace-skills doc as primary source, license is MIT with author named, content maps to the import-from-ZIP primitive. Promote with attribution."

Bad promotion decision: "Repo has 4k stars and the README looks solid, importing as-is." Popularity is not provenance. No license check, no primary-source verification, no surface mapping: quarantine, not promote.

Verification

Do this: after packaging, complete the evidence template in references/source-evidence.md for the package. Expect every field filled: primary source URL, license status, native surface, and boundary note. If any field is empty or says "unknown", the package goes to quarantine, not to the catalog.

Completion checklist

• [ ] Native primitive confirmed against current Lovable docs
• [ ] Description narrow and trigger-bound
• [ ] Heavy content moved to references with explicit pointers
• [ ] Evidence template complete, no unknowns
• [ ] Output contract fields all returned
• [ ] Uncertain packages quarantined, not shipped

Any box unchecked: not done. Fix or say so.

Footguns

• Packaging for an assumed surface: harness capabilities drift. A package built on last quarter's docs imports broken. Re-verify the primitive each time.
• Description creep: adding "and related tasks" style language to a description makes the skill trigger everywhere. Cut triggers back to concrete phrases.
• Skipping quarantine because a source "looks official": lookalike repos ship prompt packs with buried instructions. Evidence template or quarantine, no third option.