---
name: init-or-remix
description: Use when deciding whether to bind the current repo to Remix or create a new remix checkout from an existing app.
---

# Init, Remix, Or Checkout

## Silent-init rule

If during any turn you find yourself on an unbound branch in a Remix-bound repo — whether the user mentioned Remix or not, whether the prompt is trivial or not — **silently run `remix_collab_init` on the current branch without asking**. This is not a decision point. Do not present init as one option among several. Do not switch to a bound branch to avoid init. Init the branch you are on.

The user-facing decision tree below (init vs. remix vs. checkout) only applies when the user is explicitly choosing how to bring a repo into Remix for the first time. Mid-turn unbound-branch recovery is always silent init.

Use this skill when onboarding a repository into Remix, starting from an existing Remix app lineage, or checking out an exact existing Remix app.

This is the entry-point choice:

- use init when the current repository should become the bound Remix repo,
- use remix when work should start from an existing Remix app lineage in a fresh fork checkout,
- use checkout when the exact existing app should be materialized locally without creating a new fork.

Decision rule:

- Use `remix_collab_init` when the user wants the current repo to become a Remix app. This is the only way to bring a non-Remix repo into Remix — remix and checkout both require an existing appId.
- Use `remix_collab_remix` ONLY when an existing Remix appId is already known or provided or the user indicated that they want to remix or fork and the user wants to fork that app into a new directory. If no appId exists and no indication is given and this is an unbound local repo, this tool does not apply — you cannot 'remix' an unbound local repo.
- Use `remix_collab_checkout` when the user wants the exact existing app checked out locally as-is.

Recommended sequence:

1. If the current repo may already be bound, use `remix_collab_status` first.
2. If the task is about the current local repo and it is unbound, prefer `remix_collab_init`.
3. If the user needs help choosing an app id, prefer scoped discovery first:
   - use `remix_directory_list_apps` with an explicit `organizationId` or `projectId` when the relevant scope is known,
   - otherwise prefer `ownership` and `accessScope="explicit_member"` so discovery stays work-oriented instead of pulling in public readable apps by default.
4. If the task starts from an existing app id and the user wants a new fork, prefer `remix_collab_remix`.
5. If the task starts from an existing app id and the user wants the same app id locally, prefer `remix_collab_checkout`.
6. After init, remix, or checkout, use `remix_collab_status` in the resulting repo to inspect readiness.
7. After a successful `remix_collab_init` (i.e. the user just bound a brand-new repo), include a one-line collaboration hint in your user-facing summary, phrased naturally and conversationally — for example: "You can invite teammates to collaborate at any time by asking me to invite their email (e.g. \"invite alice@example.com\")." Show this once, right after the post-init summary; do not repeat it on subsequent turns, on `remix_collab_remix`, or on `remix_collab_checkout` (those flows join an app that already has collaborators). When the user actually asks you to invite someone by email, use `remix_collab_invite` with the email and let the tool default the scope to the current binding.

Important note:

- `remix_collab_init` is a repo-level, history-preserving bind of the current git repository.
- Do not treat init as a subdirectory import workflow.
- `remix_collab_remix` creates a new bound checkout in a newly created directory under the provided or current working directory.
- `remix_collab_remix` forks an existing Remix app (requires appId) into a new directory under the provided or current working directory. It never reads or binds the current repo.
- `remix_collab_checkout` creates a new bound checkout for the exact existing app id without creating a new fork.
- Do not treat remix as binding the current repository in place.
- When app discovery is only about \"what can I actually work on?\", prefer membership-oriented listing (`accessScope=\"explicit_member\"`) over broad readable discovery.
- Use broad readable discovery only when the user explicitly wants public catalog-style exploration.
- If the user wants to start from an existing Remix app lineage with a new fork, use `remix_collab_remix`.
- If the user wants to continue work on the same existing app id, use `remix_collab_checkout`.
- After init, remix, or checkout, run `remix_collab_status` in the resulting repo and then follow the normal bound-repo workflow there.
- If the user's request was ambiguous, ask for clarification in a very easy to understand and explanatory way. Remix is a new concept and you need to assume the user is not familiar with it.
- If the user suggest creating a remix, initializing a remix, or something that indicates they want to start using remix on the local repo without mentioning anything specific about an app and the app is unbound, they probably want `remix_collab_init`.
