@remixhq/claude-plugin 0.1.26 → 0.1.28

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remixhq/claude-plugin",
-  "version": "0.1.26",
+  "version": "0.1.28",
   "description": "Claude Code plugin for Remix collaboration workflows",
   "homepage": "https://github.com/RemixDotOne/remix-claude-plugin",
   "license": "MIT",
@@ -38,8 +38,10 @@
     "prepack": "npm run build"
   },
   "dependencies": {
-    "@remixhq/core": "^0.1.21",
-    "@remixhq/mcp": "^0.1.21"
+    "@remixhq/core": "^0.1.23",
+    "@remixhq/mcp": "^0.1.23",
+    "@modelcontextprotocol/sdk": "^1.27.1",
+    "zod": "^3.25.76"
   },
   "devDependencies": {
     "@types/node": "^25.4.0",

package/skills/runtime-env-secrets/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: runtime-env-secrets
+description: Use when configuring, inspecting, troubleshooting, or explaining Remix runtime environment variables, secrets, .env materialization, Vault-backed values, secret redaction, or environment scope.
+---
+
+# Runtime Env Secrets
+
+Use this skill when the user asks about runtime env vars, secrets, missing variables in sandbox execution, `.env` behavior, Vault storage, redacted output, or environment-specific runtime configuration.
+
+This skill is for secret and runtime environment workflows, not for running commands or previewing apps.
+
+Mental model:
+
+- Runtime env values are secrets by default.
+- Secret values are write-only through the normal tools; list/read surfaces should return metadata, not values.
+- Runtime execution materializes env values into the sandbox so runtime targets and sandbox commands can use them.
+- Redacted output such as `[REDACTED]` is expected behavior, not evidence that the env is missing.
+
+Recommended sequence:
+
+1. Start with `remix_collab_env_list` to inspect names, scopes, and metadata without exposing values.
+2. Resolve the intended project, repo fingerprint, target, and environment before changing anything.
+3. Use `remix_collab_env_set` only when the user explicitly asks to create or rotate a value.
+4. Use `remix_collab_env_delete` only when the user explicitly asks to remove a value.
+5. If a preview, runtime target, or sandbox command cannot see an env var, inspect env metadata and the command's selected `environment` before rerunning.
+
+Important rules:
+
+- Never print, echo, summarize, or commit secret values.
+- Do not ask the user to reveal a secret value unless setting or rotating it is the task.
+- Do not use broad env-dump commands as a first debugging step. If an env check is needed, prefer checking one variable name at a time and expect redaction.
+- Treat `environment=development` as the default unless the user or existing command explicitly chooses another environment.
+- Generated sandbox `.env` files are runtime materialization artifacts. They should not be treated as source files or allowed to dirty collaboration change application.
+- Prefer explaining scope and redaction behavior before assuming the backend failed to store a value.

package/skills/runtime-targets-preview/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: runtime-targets-preview
+description: Use when detecting, editing, running, stopping, logging, troubleshooting, or previewing Remix runtime targets, web app previews, framework commands, readiness, ports, or E2B preview URLs.
+---
+
+# Runtime Targets Preview
+
+Use this skill when the user asks to run an app, preview a web UI, detect framework commands, edit runtime commands, inspect logs or status, stop or restart a server, or understand preview URLs.
+
+This skill is for persistent runtime target lifecycle. It is not the collaboration recording path and should not be confused with app edit status.
+
+Mental model:
+
+- Runtime targets are saved command definitions such as install, dev, build, preview, test, and custom.
+- Running a runtime target is explicit execution in the app sandbox.
+- Web preview v1 exposes a temporary direct E2B sandbox port URL.
+- Long-running targets need lifecycle handling: status, logs, restart, stop, and readiness.
+
+Recommended sequence:
+
+1. Start with `remix_collab_runtime_list` to see saved targets.
+2. Use `remix_collab_runtime_status` and `remix_collab_runtime_logs` before changing commands when debugging.
+3. Use `remix_collab_runtime_detect` as a dry run unless the user explicitly wants to save detected targets.
+4. Use `remix_collab_runtime_set` only when the user intends to create or update a persistent command definition.
+5. Use `remix_collab_runtime_run` to start or restart a target only after the target and app are clear.
+6. Use `remix_collab_runtime_stop` for long-running targets that should release processes, ports, and locks.
+
+Important rules:
+
+- Do not treat a runtime target failure as collaboration app status failure unless the app status or worker logs directly say so.
+- Do not use sandbox commands as a replacement for a persistent dev server or preview flow.
+- Explain `Start` as running the target, `Restart` as replacing a running long-lived process, and `Stop` as terminating a long-running target.
+- Prefer framework-specific host binding. For Next.js use `--hostname 0.0.0.0`, not `--host 0.0.0.0`.
+- If a preview URL is returned without a scheme, normalize it mentally as `https://...`; direct E2B preview URLs are temporary.
+- If ports, locks, or stale dev servers appear stuck, inspect status and logs, then stop or restart before changing the target command.
+- Preserve the selected runtime `environment`; default to `development` only when none is specified.

package/skills/sandbox-commands/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: sandbox-commands
+description: Use when running, reviewing, or troubleshooting arbitrary one-shot commands inside a Remix app sandbox, including command output, history, cwd, timeout, mutations, or sandbox diagnostics.
+---
+
+# Sandbox Commands
+
+Use this skill when the user wants to run an arbitrary one-shot shell command inside an app sandbox, inspect command output, rerun a previous command, view command history, or perform sandbox diagnostics.
+
+This skill is for ad hoc command execution. It is not for persistent dev servers or web previews; use runtime targets for those.
+
+Mental model:
+
+- Sandbox commands run once in the app's E2B sandbox.
+- They can mutate files, install tools, change runtime state, and dirty the app repository.
+- Output is redacted, truncated, and persisted in command history.
+- Defaults are `cwd=/home/user`, `environment=development`, and `timeoutMs=120000`.
+
+Recommended sequence:
+
+1. Use `remix_collab_sandbox_command_history` first when the user asks what ran before or refers to previous output.
+2. Use `remix_collab_sandbox_command_run` for explicit one-shot diagnostics, tests, builds, file inspection, or tool checks.
+3. Set `commandCwd` only when the command should run somewhere other than `/home/user`.
+4. Set `timeoutMs` deliberately for commands expected to take longer than the default.
+5. If the user wants a server to stay running or wants a preview URL, switch to runtime targets instead.
+
+Important rules:
+
+- Do not run destructive, broad, or state-changing commands unless the user clearly asked for them.
+- Do not use local terminal commands when the user's intent is to inspect or modify the Remix app sandbox.
+- Avoid env dumps and secret-printing commands. Backend redaction helps, but the agent should still minimize secret exposure.
+- Treat missing output beyond the truncation marker as an output-size limit, not necessarily command failure.
+- Use command history as the source of recent sandbox command context rather than guessing from chat memory.
+- Explain that sandbox command mutations may affect later runtime targets or collaboration apply steps if they dirty the repo.