---
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

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 to bind the current local repository to Remix.
- Use `remix_collab_remix` when the user wants a new local checkout forked from an existing Remix app.
- 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.

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_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.
