Improvement: Suggest git branch structure to user to avoid personal data leaks

[rasstamann]

Idea: Add instructions for the agent concerning branch/fork naming based on the context that the code is being used for.
Use cases for the repo are:

1. Using main to develop features
2. Using main for personal use
3. Using fork to develop features
4. Using fork for personal use.
   These four use cases should be described as part of the context to the main agent. Agent should be made aware of what's the current use case for the active session. Based on current work (development or personal use) and branch used (main or fork), the first time the use case is accessed, the agent should suggest an appropriate branch/fork name to the user in order to compartmentalize things more cleanly.
   Critical point here is personal data leak: agent should suggest that personal use branches should be kept stored locally only or made as forks and pushed to a private repo.
   I was aware enough to avoid the data leak by pushing it to public repos, I think others might not be.

[MadsLorentzen]

Thanks @rasstamann - the concern you're pointing at is real, and it has bitten actual users of this template: more than one fork has ended up with a filled-in profile on a public master. So I took this seriously and went digging before answering.

What I found is that the root cause wasn't missing branch guidance - it was that the docs were actively wrong. SETUP.md section 8 literally said "your fork is private working space, so commit them" about the profile files. Forks of public GitHub repositories are always public and can't be made private, so the setup instructions were telling people to commit personal data somewhere they had every reason to believe was private. That's on the template, not on the users.

That's fixed as of d4b406e, prompted by this discussion:

• SETUP.md section 8 now states plainly that a fork is public, and documents the safe remote setup: a private repository with this repo added as the upstream remote, so you keep receiving updates without ever pushing profile data to a fork. Keeping personalization in local, never-pushed commits works too.
• /setup now ends with a privacy note at the exact moment profile data first lands in tracked files - so every user who onboards sees it, whether or not they ever read SETUP.md.

On the fuller proposal - the agent inferring which of the four use cases a session is in and suggesting branch/fork names accordingly - I'm going to pass, and I want to be straight about why. The agent can't reliably know whether a session is "feature development" or "personal use" (plenty of sessions are both), and a wrong guess produces confidently wrong advice, which is worse than none. The compartmentalization your four quadrants aim at is real, but the load-bearing distinction turned out to be simpler: public remote vs. private/local, stated once at the right moments. That's what shipped.

Genuinely glad you raised this - "I was aware enough to avoid it, others might not be" is exactly the kind of report that improves the template for everyone downstream.