@remixhq/claude-plugin 0.1.17 → 0.1.18

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remixhq/claude-plugin",
-  "version": "0.1.17",
+  "version": "0.1.18",
   "description": "Claude Code plugin for Remix collaboration workflows",
   "homepage": "https://github.com/RemixDotOne/remix-claude-plugin",
   "license": "MIT",
@@ -31,8 +31,8 @@
     "prepack": "npm run build"
   },
   "dependencies": {
-    "@remixhq/core": "^0.1.12",
-    "@remixhq/mcp": "^0.1.12"
+    "@remixhq/core": "^0.1.13",
+    "@remixhq/mcp": "^0.1.13"
   },
   "devDependencies": {
     "@types/node": "^25.4.0",

package/skills/identity-and-scope-routing/SKILL.md

@@ -28,6 +28,7 @@ Recommended sequence:
 Important rules:
 
 - In a bound repo, treat the app as the default anchor for scope reasoning.
+- When the user asks for an app dashboard URL and the `appId` is known, answer with `https://dashboard.remix.one/apps/<appId>`.
 - Do not assume the bound app's project or organization is readable just because the app is readable.
 - Treat warnings on cwd-derived results as meaningful partial context, not as failure.
 - If cwd inference cannot safely resolve a broader scope, prefer the app-level answer and explain the boundary.

package/skills/review-merge-request/SKILL.md

@@ -19,17 +19,19 @@ Recommended sequence:
     - `app_outgoing` for requests opened from this app
     - `app_related_visible` for all open visible requests where this app is source or target
 2. Use `remix_collab_view_merge_request` to inspect the request.
-3. Request bounded diff output first. Only request a larger diff if needed to answer the review task accurately.
-4. If approval is requested:
+3. If the current repo reports `await_finalize`, use `remix_collab_drain_finalize_queue`, then re-check `remix_collab_status` before request-merge or target-mutating approval flows.
+4. Request bounded diff output first. Only request a larger diff if needed to answer the review task accurately.
+5. If approval is requested:
    - use `remix_collab_approve_remote` when local target repo sync is not needed
    - use `remix_collab_approve_and_sync_target` only when you are in the correct target repo context and the user wants local sync too
-5. Use `remix_collab_reject` when the correct outcome is rejection.
+6. Use `remix_collab_reject` when the correct outcome is rejection.
 
 Important rules:
 
 - In a bound repo, use Remix review tools as the default path for MR handling.
 - Choose an explicit queue instead of treating merge requests as one broad inbox.
 - Do not treat raw `git merge` as the way Remix merge requests are approved or applied.
+- Do not assume a successful `remix_collab_finalize_turn` already created a remote change step; drain and re-check when status reports `await_finalize`.
 - If approval would mutate the local target repo, explain that before applying it.
 - If the repo context is unclear, stay in remote-only review mode until the target repo is confirmed.
 - Before the final response, use `remix_collab_finalize_turn` to record the completed review turn.

package/skills/safe-collab-workflow/SKILL.md

@@ -14,6 +14,7 @@ Canonical rules:
 - Historical intent questions go to Remix memory before raw git history.
 - Raw git mutation is not the normal collaboration path in a bound repo.
 - Before the final response, you must record exactly one completed turn with `remix_collab_finalize_turn`.
+- `remix_collab_finalize_turn` is queued only. It captures the local boundary first; a remote change step does not exist yet until the finalize queue drains.
 - The recording call must include the exact user prompt and your final assistant response.
 - Do not finish the response before recording the completed turn.
 - Prefer preview tools before apply tools whenever both exist.
@@ -28,14 +29,15 @@ Follow this order:
 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. Prefer Remix merge request tools over raw git merge flows for collaboration review work.
-5. 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:
+4. If status reports `await_finalize`, use `remix_collab_drain_finalize_queue`, then re-check `remix_collab_status` before merge-related or recovery flows.
+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`
-6. Only call `remix_collab_memory_change_step_diff` after you already have a specific `changeStepId`.
-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. Before the final response, call `remix_collab_finalize_turn`.
+7. Only call `remix_collab_memory_change_step_diff` after you already have a specific `changeStepId`.
+8. 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.
+9. Before the final response, call `remix_collab_finalize_turn`.
 
 After switching branches:
 
@@ -51,6 +53,7 @@ Important rules:
 - 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.
 - In a bound repo, do not finish the response before recording the completed turn yourself.
+- Do not treat a successful `remix_collab_finalize_turn` call as proof that the turn is already available for merge-request or remote-history workflows. Drain and re-check when status reports `await_finalize`.
 - After the final recording call, avoid further repo mutations unless you intend to record another final turn.
 - 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.

package/skills/submit-change-step/SKILL.md

@@ -1,32 +1,31 @@
 ---
-name: submit-change-step
-description: Use when code edits are complete in a Remix-bound repo and the work should be recorded as a Remix change step.
+name: finalize-turn-workflow
+description: Use when code edits or review work are complete in a Remix-bound repo and the turn should be recorded with `remix_collab_finalize_turn`.
 ---
 
-# Submit Remix Change Step
+# Finalize A Remix Turn
 
-Use this skill after edits are complete and the task should be captured as the final recorded turn in a Remix-bound repo.
+Use this skill after edits or review work are complete and the task should be captured as the final recorded turn in a Remix-bound repo.
 
-This skill is specifically about what `remix_collab_finalize_turn` needs to record the completed work correctly.
+This skill is specifically about the queued-finalize model behind `remix_collab_finalize_turn`.
 
 Workflow:
 
 1. Run `remix_collab_status` first to confirm the repo is bound and inspect current warnings.
-2. Use `remix_collab_finalize_turn` before the final response, with the exact user prompt and your final assistant response.
-3. Let `remix_collab_finalize_turn` choose the changed-turn path from the live worktree by default.
-4. Provide an explicit external diff only when the task requires recording a diff that is not present in the current worktree.
+2. If status recommends `await_finalize`, do not record again and do not request a merge yet. Use `remix_collab_drain_finalize_queue`, then re-check `remix_collab_status`.
+3. When the repo is ready, use `remix_collab_finalize_turn` before the final response, with the exact user prompt and your final assistant response.
+4. Treat `remix_collab_finalize_turn` as capturing the local workspace boundary and queueing remote processing, not as immediate proof that a remote change step already exists.
 
 Important behavior:
 
 - `remix_collab_finalize_turn` is the authoritative recording path for completed work instead of raw git commit or push.
-- When the diff comes from the live worktree, Remix may discard tracked changes and captured untracked paths locally as part of auto-sync.
-- When the diff comes from an external source, automatic local discard+sync is skipped because the external diff may not match the current worktree.
-- The resulting git commit is created on the Remix side first and appears in the local repo after sync or auto-sync.
-- Surface these side effects clearly to the user when they matter.
+- `remix_collab_finalize_turn` is queued only. A remote change step does not exist yet until the finalize queue drains successfully.
+- A successful finalize call means local capture and queueing succeeded. It does not mean merge-request or remote-history workflows can assume the turn is already materialized remotely.
+- If `remix_collab_status` reports `await_finalize`, use `remix_collab_drain_finalize_queue` and re-check status before merge-related or recovery flows.
 - If the user wants to understand current repo state before recording, re-run `remix_collab_status`.
 - Do not make further repo mutations after the final recording call unless you intend to record another completed turn.
-- If `remix_collab_finalize_turn` reports that the change step succeeded remotely but local sync failed, do not retry finalize immediately.
-- In that recovery case, treat the tool's `recommendedNextActions` and `error.hint` as authoritative, starting with `remix_collab_status`, then `remix_collab_sync_preview`, then `remix_collab_sync_apply` when appropriate.
-- If the error surfaces a preserved diff backup path, mention it explicitly and preserve it as the fallback recovery artifact while you repair local sync state.
+- Do not retry finalize immediately just because a remote record is not visible yet; queue drain is the next step, not a second finalize.
+- If finalize or drain returns `recommendedNextActions` or an `error.hint`, treat those as authoritative and lead with `remix_collab_status` before broader recovery work.
+- If the tool surfaces a preserved local recovery artifact, mention it explicitly and keep it available while you repair repo state.
 
-Use external diff input only when the task explicitly requires it. Otherwise prefer the current worktree.
+Use the live worktree as the source of truth for finalized work. If the repo is not ready, fix the preflight state first rather than trying to bypass it.