Graduate From Lovable

I'm about to connect my Lovable project to GitHub so I can also work on it in [WHERE I'LL EDIT LOCALLY]. I'm a beginner with Git.

My app: [WHAT MY APP DOES]
It uses: [WHAT IT USES]

Here's what I know about how Lovable's GitHub sync works:
- Connecting creates a brand-new GitHub repository. It can't link to a repository I already have.
- Sync is two-way: Lovable pushes its edits to GitHub, and commits pushed to the synced branch come back into Lovable.
- Lovable only edits and syncs one branch at a time, usually main.
- If I disconnect and reconnect later, Lovable creates a new repository instead of reusing the old one.

Please give me a short checklist, in order, for:
1. What to do in Lovable before I connect, so nothing is half-finished.
2. Connecting, in plain words.
3. Checking afterward that the code really landed on GitHub.
4. The three mistakes beginners make most often in the first week, and how to avoid each one.
Keep it under 250 words. If you're not sure about something specific to Lovable, tell me to check Lovable's docs instead of guessing.

My Lovable project syncs with GitHub. I want to work on it locally without ever overwriting Lovable's work.

Repository: [MY REPO URL]
Lovable's synced branch: [SYNCED BRANCH]
My first local change: [MY FIRST CHANGE]

Please:
1. Give me the exact Git commands to clone the repo and create a feature branch for my first change, with a good branch name. Explain each command in one line.
2. Explain in plain words why Lovable stays on [SYNCED BRANCH] while I work on my feature branch.
3. Show me how to merge my feature branch into [SYNCED BRANCH] when it's done, using a normal merge, not a squash or a rebase.
4. List the commands I must never run on [SYNCED BRANCH] (like force-push), and tell me what to do instead when I want to undo something.

Don't change any files. This repository was built with Lovable, and I'm opening it in an editor for the first time. I'm a beginner.

What the app does: [WHAT MY APP DOES]
The part I want to change first: [THE PART I WANT TO CHANGE FIRST]

Please read the repository and explain:
1. The main folders and what each one is for, in one line each.
2. Where the pages and components for [THE PART I WANT TO CHANGE FIRST] live.
3. Every place the app talks to the database, login, or an outside service, with file paths.
4. Every environment variable the code reads, where it's read, and whether it ends up in the browser. Don't print any secret values.
5. Anything in supabase/functions/ or a migrations folder, and what each one seems to do.
6. The commands from package.json to install, run, and build the app.
If something is unclear, say so instead of guessing.

Write an AGENTS.md file for the root of this repository. This project was built in Lovable and still syncs with Lovable through GitHub, so Lovable and I both edit it.

My codebase notes: [MY CODEBASE NOTES]
Things that must keep working: [THINGS THAT MUST KEEP WORKING]

Include short sections for:
1. What the app is and the main tech it uses.
2. How to install, run, and build it (exact commands).
3. Where things live (pages, components, database calls, backend functions).
4. Branch rules: never commit directly to the synced branch, never force-push, rebase, or squash it, and work on feature branches.
5. Backend rules: changes in supabase/functions/ or migration folders aren't deployed automatically, so flag them in your summary.
6. Never put secrets in variables that start with VITE_, because those end up in the browser.
7. The features that must keep working, and how to check each one.
Keep it under 120 lines. Show me the file before you save it.

Help me run this Lovable project on my computer for the first time. I'm a beginner.

My computer: [MY COMPUTER]
What's installed: [WHAT'S INSTALLED]
Any error I got: [ANY ERROR I GOT]

Please:
1. Read the README and package.json, and tell me what I need installed and the exact commands to install and start the app.
2. Check which environment variables the app needs, and whether a .env file is already in the repo. Tell me which values I still need and where to find them, without printing any values.
3. Warn me clearly if my local app will read and write the same database as my live app, and tell me how to test safely.
4. If I pasted an error, explain it in one line and give me the fix.
5. Tell me exactly what I should see when it's working.

My Lovable app works in Lovable but fails when I run it on my computer.

What fails: [WHAT FAILS]
The error: [THE ERROR]
When I created the project in Lovable: [WHEN I CREATED THE PROJECT]

Check these possible causes and say "likely", "possible", or "unlikely" for each, with one line why:
1. Login: my login provider only redirects to URLs it knows, and my local URL isn't on the list yet.
2. Secrets: secrets stored in Lovable aren't in the repository, so server code that needs them is missing values on my computer.
3. Connectors and Lovable AI: their credentials are managed by Lovable and can't be copied out.
4. Missing install step or wrong environment variable.
Then give me the fix for the most likely cause, step by step. If the fix is "test this in Lovable's preview instead", say so plainly.

I edit my app in both Lovable and my own editor. Write me a short handoff routine I can follow every time.

How I split the work: [HOW I SPLIT THE WORK]
Lovable's synced branch: [SYNCED BRANCH]

Facts about Lovable's GitHub sync:
- Lovable shows a sync status card in its project Git settings. "In sync" means both sides are on the same commit.
- Commits on other branches don't appear in Lovable until they're merged into the synced branch.
- After a merge, I should tell Lovable what I changed so its next edit builds on my work.
- A merge doesn't change my published app. I have to publish again in Lovable.

Please write:
1. A "before I leave Lovable" checklist (3 to 5 steps).
2. A "before I go back to Lovable" checklist (3 to 5 steps), including the git commands to update my local copy and merge my feature branch.
3. A fill-in message I can paste into Lovable's chat after a merge that tells it which files I changed and what it must keep working.
Keep each checklist short enough to fit on a sticky note.

My Lovable project and GitHub got out of step. Help me fix it without losing work. Don't run any commands yet. Explain first.

What Lovable says: [WHAT LOVABLE SAYS]
What I did recently: [WHAT I DID RECENTLY]
Branches I see on GitHub: [BRANCHES I SEE ON GITHUB]

What I know from Lovable's docs:
- "Diverged" means Lovable and GitHub each have commits the other doesn't. Lovable then pushes its changes to a branch called lovable-sync, and the next sync from GitHub replaces Lovable's version of the branch with the GitHub version.
- When a push replaces Lovable's work, Lovable saves a backup first, and the project owner can choose "Restore Lovable work" or "Keep repository version".
- A lovable-sync branch should be merged with a normal merge commit, not a squash or rebase.

Please:
1. Explain in plain words what most likely happened.
2. Tell me which work could be at risk right now, and the safest first step to protect it.
3. Give me the steps to get back to one clean synced branch, with each Git command explained in one line.
4. Tell me the one habit that would have prevented this.

I changed backend files in my Lovable project from my own editor, and the commit has synced to Lovable.

Files I changed: [FILES I CHANGED]
What the change does: [WHAT THE CHANGE DOES]

I know that Lovable doesn't deploy a changed Edge Function or run a new migration file when commits sync.

Please:
1. Sort my changed files into: Edge Functions (supabase/functions/), migrations (supabase/migrations/ or drizzle/migrations/), or other.
2. For each Edge Function, write the short message I should send in Lovable's chat to deploy it, and tell me how to check it worked.
3. For any database change, explain what it changes in plain words, whether it could delete or damage existing data, and write the message I should send in Lovable's chat to make the change properly.
4. Give me a 3-step test I can run in the Lovable preview to confirm everything works.