---
name: safe-collab-workflow
description: Use when working in a repo that may be bound to Remix, especially for collaboration, sync, merge request, or state-recovery tasks.
---

# Safe Remix Collaboration Workflow

In a Remix-bound repo, treat Remix MCP tools as the authoritative workflow layer for collaboration state and historical reasoning.

For normal Remix collaboration:

- use sync or reconcile tools to align local state with Remix,
- use merge request tools for review and approval flows,
- use memory summary/search/timeline tools when historical context is needed before broader repo inspection,
- use the explicit change-step diff tool only after identifying a relevant `changeStepId`,
- let the installed hook handle automatic per-turn recording.

In this plugin setup, turn recording is automatic at the end of each completed assistant response in a bound repo:

- changed turn => `remix_collab_add`
- no-diff turn => `remix_collab_record_turn`

Normal rule:

- do not proactively call `remix_collab_add` or `remix_collab_record_turn` during ordinary work
- use those tools manually only for explicit user intent, operational recovery, backfills, or debugging

Raw git mutation commands must not be used for ordinary bound-repo collaboration work. Raw git reads are reserved for exact repository facts, not for normal collaboration-state or historical-reasoning flows.

Follow this order:

1. Start with `remix_collab_status`.
2. Use the returned recommendation and warnings to choose the next tool.
3. Prefer preview tools before apply tools:
   - `remix_collab_sync_preview` before `remix_collab_sync_apply`
   - `remix_collab_reconcile_preview` before `remix_collab_reconcile_apply`
4. Treat reconcile as high risk and only use it when sync is unavailable and clearly required.
5. Prefer Remix merge request tools over raw git merge flows for collaboration review work.
6. When you need historical context, hidden intent, failed attempts, merge/reconcile lineage, or pre-change risk context, check Remix memory before falling back to broader repo exploration:
   - `remix_collab_memory_summary`
   - `remix_collab_memory_search`
   - `remix_collab_memory_timeline`
7. Use raw git history only after Remix memory has narrowed the relevant change, or when the user explicitly asks for exact commit, blame, ancestry, or patch-level detail.
8. Only call `remix_collab_memory_change_step_diff` after you already have a specific `changeStepId`.

Important rules:

- If the repo is unbound, use `remix_collab_init` for the current repo, `remix_collab_remix` for a new fork from an existing app lineage, or `remix_collab_checkout` to materialize an existing app as-is.
- In a bound repo, do not use raw git `commit`, `push`, `pull`, `merge`, `rebase`, or `reset` for ordinary Remix collaboration work.
- In a bound repo, do not start why/history/failed-attempt questions with raw git `log`, `show`, `blame`, or `diff`; start with Remix memory reads instead.
- Do not manually fire per-turn recording calls during ordinary work. The end-of-response hook records one turn once per completed assistant response.
- Use raw git reads only when the task is clearly about exact repository facts or a separate GitHub-only branch workflow rather than Remix state.
- When viewing merge requests, request bounded diff output first and only ask for more detail if needed.
- For merge-request listing, choose the explicit queue that matches the intent: `remix_collab_review_queue`, `remix_collab_my_merge_requests`, or `remix_collab_list_app_merge_requests` with required `queue` set to `app_reviewable`, `app_outgoing`, or `app_related_visible`.
