@remixhq/claude-plugin 0.1.14 → 0.1.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remixhq/claude-plugin",
-  "version": "0.1.14",
+  "version": "0.1.16",
   "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.9",
-    "@remixhq/mcp": "^0.1.9"
+    "@remixhq/core": "^0.1.11",
+    "@remixhq/mcp": "^0.1.11"
   },
   "devDependencies": {
     "@types/node": "^25.4.0",

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

@@ -21,6 +21,9 @@ Recommended sequence:
    - an explicit id was provided,
    - or app-grounded context shows those broader scopes are readable and relevant.
 4. When the user asks about a scope outside the current repo context, prefer explicit ids over cwd inference.
+5. When listing apps, prefer scoped or ownership-aware discovery before broad readable discovery:
+   - prefer `organizationId` or `projectId` when the relevant tenant scope is known,
+   - otherwise use `ownership` and `accessScope="explicit_member"` when the user means “apps I can actually work on.”
 
 Important rules:
 
@@ -29,3 +32,4 @@ Important rules:
 - 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.
 - Use explicit ids when switching from "what is this repo?" to "tell me about that other org/project/app".
+- Do not default to broad unscoped app listing when the task is work-oriented; reserve `accessScope="all_readable"` for explicit public or broad readable discovery.

package/skills/init-or-remix/SKILL.md

@@ -23,9 +23,12 @@ 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 task starts from an existing app id and the user wants a new fork, prefer `remix_collab_remix`.
-4. If the task starts from an existing app id and the user wants the same app id locally, prefer `remix_collab_checkout`.
-5. After init, remix, or checkout, use `remix_collab_status` in the resulting repo to inspect readiness.
+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:
 
@@ -34,6 +37,8 @@ Important note:
 - `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.

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

@@ -10,6 +10,7 @@ In a Remix-bound repo, treat Remix MCP tools as the authoritative workflow layer
 Canonical rules:
 
 - In a bound repo, Remix tools are the required workflow layer for collaboration work.
+- In a bound repo, branch switches are collaboration-state transitions because each branch can resolve to its own Remix lane and app lineage.
 - 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`.
@@ -36,6 +37,14 @@ Follow this order:
 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`.
 
+After switching branches:
+
+1. Run `remix_collab_status`.
+2. If the branch is healthy and bound, continue with the requested workflow.
+3. If the branch is unbound, initialize or provision that branch lane before mutation commands.
+4. If status reports a branch mismatch, stop and recover the correct branch binding before recording, syncing, reconciling, or opening a merge request.
+5. Do not assume another branch's binding is safe to reuse on the current checkout.
+
 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.