@mr.dj2u/cli 0.1.0 → 0.1.2

package/bundles/codex/skills/uniwind-theming/SKILL.md

@@ -0,0 +1,31 @@
+# Skill: Uniwind Theming
+
+Use when setting up or maintaining Tailwind v4 + Uniwind styling in Expo projects.
+
+## Main rule
+
+Prefer Uniwind with Tailwind v4 defaults, keep theme tokens centralized, and ensure bundler/style wiring is consistent across environments.
+
+## Checks
+
+- Confirm Tailwind v4 and Uniwind dependencies/config are aligned with project SDK.
+- Confirm `global.css` import order loads Tailwind before Uniwind layers.
+- Confirm Metro/bundler integration uses `withUniwindConfig` (or project-equivalent wiring).
+- Confirm design tokens are centralized and reused instead of ad-hoc values.
+- Confirm platform-specific style behavior is intentional and documented.
+
+## Preferred structure
+
+- Keep token definitions in one source module/file.
+- Keep style-system setup in project bootstrap/config files, not scattered across screens.
+- Keep shared class patterns in reusable UI components.
+
+## Example fix
+
+- Problem: Global styles load in the wrong order, causing token classes to fail on web.
+- Fix: Reorder style imports, verify Metro integration, and move duplicate token literals into shared theme config.
+
+## Agent behavior
+
+- Preserve existing design intent while fixing setup drift.
+- Delegate framework styling primitives to official Expo/Uniwind docs, then apply MDS conventions for token consistency and onboarding readiness.

package/bundles/vscode-copilot/.github/agents/mds.agent.md

@@ -0,0 +1,22 @@
+---
+name: "MDS"
+description: "MDS Expo project intelligence agent for Doctor, onboarding, deploy checks, and phase continuation."
+---
+
+# MDS Agent
+
+You are the Mr. DJ's Dev Suite agent for Expo projects. Prefer MDS MCP tools first, then CLI fallbacks.
+
+## Tool Routing
+
+- Use `doctor_scan_project` before release or broad refactors.
+- Use `doctor_scan_file` for focused route, env, SSR, or API changes.
+- Use `generate_refactor_plan` before moving architecture across folders.
+- Use `generate_deploy_checklist` before release or client handoff.
+- Use `list_skills`, `get_skill`, and `get_guide` before giving framework-specific guidance.
+
+## Guardrails
+
+- Keep project intent in `project/info.md` and technical rules in `project/guidelines.md`.
+- Prefer Expo-owned guidance for framework mechanics; MDS adds project memory, checks, defaults, and workflows.
+- Do not skip unresolved `# TodoForContext(optional):` markers before implementation.

package/bundles/vscode-copilot/.github/copilot-instructions.md

@@ -0,0 +1,8 @@
+<!-- BEGIN MDS COPILOT INSTRUCTIONS -->
+# Mr. DJ's Dev Suite Copilot Instructions
+
+- Treat `project/` as the source of truth for product intent, roadmap, style, and technical rules.
+- Prefer MDS MCP tools before broad edits: `doctor_scan_project`, `doctor_scan_file`, `generate_refactor_plan`, and `generate_deploy_checklist`.
+- Use `list_skills`, `get_skill`, and `get_guide` for MDS guidance, while delegating framework mechanics to official Expo/React Native guidance when available.
+- Keep route files thin, env secrets server-only, and release work gated by Doctor checks.
+<!-- END MDS COPILOT INSTRUCTIONS -->

package/bundles/vscode-copilot/.github/prompts/continue-development.prompt.md

@@ -0,0 +1,32 @@
+---
+mode: "agent"
+description: "Run the MDS Continue Development workflow with MCP-first diagnostics and CLI fallback."
+---
+
+# /continue-development
+
+Resume work on an onboarded project by following MDS phase order from `project/todo.md`.
+
+## Arguments
+
+- `projectPath`: onboarded app path (default: current directory).
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Call `continue_project` first to get the active-phase brief.
+3. Pull `get_skill` for `continue-development` to enforce phase-first sequencing.
+4. If blockers appear, use `doctor_scan_project` and `doctor_explain_result` for targeted remediation before feature work.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client codex --scope project`
+2. Direct CLI flow:
+   - `mds continue <projectPath>`
+   - `mds doctor <projectPath>` when blockers are unclear.
+
+## Verification And Output
+
+- Confirm the chosen task belongs to the active phase or has an explicit deferral note.
+- Output: selected next task, blockers, and validation commands to run after implementation.

package/bundles/vscode-copilot/.github/prompts/create-expo-super-stack.prompt.md

@@ -0,0 +1,35 @@
+---
+mode: "agent"
+description: "Run the MDS Create Expo Super Stack workflow with MCP-first diagnostics and CLI fallback."
+---
+
+# /create-expo-super-stack
+
+Create a new Expo app with the MDS Super Stack flow, using this knowledge package as the shared source of truth for agent-facing text and the published CLI as the execution source of truth.
+
+## Arguments
+
+- `parentDir`: folder where the new app directory should be created.
+- `appName`: app folder name.
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Invoke the MCP prompt `create_expo_super_stack` from a parent directory when you want guided intake.
+3. Keep the conversation one question per turn and summarize the captured choices before generation.
+4. Treat the MCP prompt as the intake surface and the CLI as the generator, so CLI changes are picked up automatically when the published command changes.
+5. After generation, move into the new app folder and invoke `continue_project` (or prompt `continue_mds_project`) for the first implementation session.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client codex --scope project`
+2. Direct CLI generation:
+   - `npx -y create-expo-super-stack <appName>`
+3. Then onboard/continue from inside the generated app using the current CLI behavior:
+   - `mds continue <new-app-path>`
+
+## Verification And Output
+
+- Confirm generated app has `project/info.md`, `project/todo.md`, `project/style.md`, and `project/guidelines.md`.
+- Output: generated app path, onboarding status, and immediate next command.

package/bundles/vscode-copilot/.github/prompts/fix-seo.prompt.md

@@ -0,0 +1,34 @@
+---
+mode: "agent"
+description: "Run the MDS Fix Seo workflow with MCP-first diagnostics and CLI fallback."
+---
+
+# /fix-seo
+
+Apply SEO metadata fixes for Expo web routes with MCP guidance and post-fix verification.
+
+## Arguments
+
+- `projectPath`: Expo project path (default: current directory).
+- `routeOrFile`: optional route/file focus for targeted checks.
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Pull `get_skill` for `seo-metadata`.
+3. Optionally run `doctor_scan_file` for focused route files, then `doctor_scan_project` for full checks.
+4. Use `knowledge_list_resources` (`kind: "rule"`) to ensure canonical/indexing strategy is complete.
+5. Implement metadata, canonical, robots, and sitemap corrections in route ownership boundaries.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client codex --scope project`
+2. Direct CLI checks:
+   - `mds doctor <projectPath> --ci`
+   - Run project-specific web build/preview commands to verify metadata output.
+
+## Verification And Output
+
+- Confirm canonical tags, social metadata, and sitemap/robots behavior on affected routes.
+- Output: changed files, resolved SEO gaps, and any remaining manual verification steps.

package/bundles/vscode-copilot/.github/prompts/prepare-deploy.prompt.md

@@ -0,0 +1,36 @@
+---
+mode: "agent"
+description: "Run the MDS Prepare Deploy workflow with MCP-first diagnostics and CLI fallback."
+---
+
+# /prepare-deploy
+
+Prepare an Expo project for release using deployment-focused skills plus Doctor parity checks.
+
+## Arguments
+
+- `projectPath`: release candidate project path (default: current directory).
+- `includeSeo`: whether to include web metadata/indexing checks (default: `true` when web is targeted).
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Run `doctor_scan_project` in `ci` mode for release parity.
+3. Pull `get_skill` for `deployment`; if web is involved also pull `seo-metadata`.
+4. Use `knowledge_list_resources` (`kind: "rule"`) to confirm env hygiene, SSR safety, and metadata requirements.
+5. Call `generate_deploy_checklist` so SEO, scripts, and release-readiness gaps are reflected in the next steps.
+6. Produce a release checklist mapped to current failing checks.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client codex --scope project`
+2. Direct CLI path:
+   - `mds doctor <projectPath> --ci`
+   - Run project scripts: `lint`, `type-check`, `test`, and production build/profile scripts.
+
+## Verification And Output
+
+- Re-run `doctor_scan_project` (or CLI equivalent) until blockers are cleared.
+- Keep the response user-facing and checklist-driven; avoid internal tool chatter and avoid asking for a PR unless the user requested GitHub workflow.
+- Output: release readiness status, unresolved blockers, and rollback/readiness notes.

package/bundles/vscode-copilot/.github/prompts/project-research-plan.prompt.md

@@ -0,0 +1,34 @@
+---
+mode: "agent"
+description: "Run the MDS Project Research Plan workflow with MCP-first diagnostics and CLI fallback."
+---
+
+# /project-research-plan
+
+Turn rough product notes/research into actionable MDS project memory and next-phase plan.
+
+## Arguments
+
+- `projectPath`: target project path (default: current directory).
+- `inputs`: attached notes/docs to normalize into canonical memory files.
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Pull `get_skill` for `research-plan-intake` (and `project-onboarding` when onboarding context is mixed in).
+3. Call `knowledge_list_resources` for `guide` and `reference` resources as needed for structure and validation.
+4. Normalize clear context directly; ask focused follow-up only where ambiguity changes implementation direction.
+5. Update project memory files and produce an implementation-ready next-phase plan.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client codex --scope project`
+2. Direct CLI fallback:
+   - Use `mds onboard <projectPath>` for structured intake when memory files are missing.
+   - Use `mds continue <projectPath>` after memory normalization to select the next task.
+
+## Verification And Output
+
+- Confirm `project/info.md`, `project/style.md`, and `project/todo.md` align with extracted research context.
+- Output: resolved unknowns, outstanding questions, and the recommended next implementation slice.

package/bundles/vscode-copilot/.github/prompts/review-expo-project.prompt.md

@@ -0,0 +1,37 @@
+---
+mode: "agent"
+description: "Run the MDS Review Expo Project workflow with MCP-first diagnostics and CLI fallback."
+---
+
+# /review-expo-project
+
+Review an Expo project with MCP-first diagnostics and skill-guided remediation.
+
+## Arguments
+
+- `projectPath`: absolute or relative project path (default: current directory).
+- `mode`: Doctor mode (`fast`, `ci`, or `full`; default: `ci`).
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Call `continue_project` to summarize current project state and blockers.
+3. Call `doctor_scan_project` with `projectPath` and `mode`.
+4. For each warning/error, call `doctor_explain_result`, then pull targeted guidance with `get_skill` (for example: `project-onboarding`, `debugging`, `deployment`).
+5. If the findings affect release readiness, call `generate_deploy_checklist` so the next steps stay checklist-driven instead of PR-driven.
+6. Call `knowledge_list_resources` with `kind: "guide"` if extra reference context is needed.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client codex --scope project`
+2. If MCP still cannot run, use direct CLI flows:
+   - `mds continue <projectPath>`
+   - `mds doctor <projectPath> --ci`
+
+## Verification And Output
+
+- Keep the response user-facing: summarize findings and next steps without echoing internal tool chatter or file-read noise.
+- Re-run `doctor_scan_project` (or `mds doctor --ci`) after fixes.
+- If the user is validating an installed agent bundle, include `mds agent verify --client <client> --target <path>` in the follow-up commands.
+- Output: blocker summary, failing checks, recommended next task, and concrete follow-up commands. Avoid proposing a PR unless the user explicitly asks for a GitHub workflow.

package/bundles/vscode-copilot/.github/prompts/run-doctor.prompt.md

@@ -0,0 +1,37 @@
+---
+mode: "agent"
+description: "Run the MDS Run Doctor workflow with MCP-first diagnostics and CLI fallback."
+---
+
+# /run-doctor
+
+Run MDS Doctor as the primary health check for an Expo project.
+
+## Arguments
+
+- `projectPath`: project root path (default: current directory).
+- `mode`: `fast`, `ci`, or `full` (default: `ci`).
+- `runScripts`: whether Doctor should execute project scripts (default: `true` for `ci` mode).
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Call `doctor_scan_project` with selected arguments.
+3. For each non-pass result, call `doctor_explain_result`.
+4. If the check is release-related or web-facing, call `generate_deploy_checklist` before giving next steps.
+5. Pull targeted implementation guidance with `get_skill` (typically `deployment`, `debugging`, or `dev-server-management`).
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client codex --scope project`
+2. Direct CLI alternatives:
+   - `mds doctor <projectPath>`
+   - `mds doctor <projectPath> --ci`
+   - `mds doctor <projectPath> --json`
+
+## Verification And Output
+
+- Re-run Doctor after each fix batch.
+- Keep the response concise and user-facing; do not surface internal tool chatter or intermediate file reads.
+- Output: check summary, blocking errors first, and the exact command used for re-check.

package/bundles/vscode-copilot/.github/skills/api-routes/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: "API Routes Skill"
+description: "Instructions for secure Expo Router API routes."
+---
+
+# Skill: API Routes
+
+Use when creating, reviewing, or debugging Expo Router API route handlers.
+
+## Main rule
+
+Keep route handlers thin and defensive: validate input, enforce auth/authorization before data access, and return consistent typed responses.
+
+## Checks
+
+- Confirm each endpoint handles allowed methods explicitly and rejects unsupported methods.
+- Validate request params/body with schema guards before business logic executes.
+- Enforce auth first for privileged operations; never rely on client-provided roles.
+- Keep service-role credentials on server-only paths and avoid exposing them to client bundles.
+- Confirm error responses are structured and safe (no stack traces or secret values).
+
+## Preferred structure
+
+- Use one route module per resource concern.
+- Parse and validate request data first, then call feature/service logic.
+- Keep DB and external API logic in service modules, not inline in route files.
+- Use a shared response envelope pattern for success and failure paths.
+
+## Example fix
+
+- Problem: A `POST` route writes directly to DB with unchecked body data.
+- Fix: Add schema validation, early auth check, and move write logic into a service function before returning a typed response object.
+
+## Agent behavior
+
+- Apply the smallest safe refactor that adds validation/auth boundaries first.
+- Delegate framework primitive questions to official Expo API route guidance, then layer MDS project-specific rules (env boundaries, doc updates, Doctor compatibility).
+

package/bundles/vscode-copilot/.github/skills/continue-development/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Continue Development Skill"
+description: "Instructions for choosing and progressing the next task from project/todo.md."
+---
+
+# Skill: Continue Development
+
+Use when resuming work on an onboarded app and selecting the next task from `project/todo.md`.
+
+## Main rule
+
+Continue phase-by-phase: finish in-progress phase items first, and only defer/move tasks with an explicit note and user confirmation.
+
+## Checks
+
+- Confirm project memory files are present and current before task selection.
+- Identify the active phase and incomplete tasks in `project/todo.md`.
+- Confirm blockers/context markers are resolved before feature implementation.
+- Confirm any deferral includes a clear reason and destination note.
+- Re-run Doctor/checks after significant phase tasks are completed.
+
+## Preferred structure
+
+- Start each session by summarizing current phase state and next recommended task.
+- Keep task updates minimal and explicit in `project/todo.md`.
+- Keep roadmap changes aligned with product intent in `project/info.md`.
+
+## Example fix
+
+- Problem: Agent jumps to a later phase feature while current phase has unresolved blockers.
+- Fix: Return to active phase tasks, complete or formally defer blockers, then proceed to later phase work.
+
+## Agent behavior
+
+- Optimize for forward progress without losing roadmap integrity.
+- Avoid silently reordering roadmap priorities; ask for confirmation before major sequencing changes.
+- Treat this as an MDS-only workflow skill: use official Expo or React Native guidance for framework mechanics, then apply MDS phase order, project memory, and Doctor checks.

package/bundles/vscode-copilot/.github/skills/debugging/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Debugging Skill"
+description: "Instructions for reproducible issue triage and root-cause-first fixes."
+---
+
+# Skill: Debugging
+
+Use when diagnosing broken behavior, flaky tooling, or unclear failures in Expo projects.
+
+## Main rule
+
+Debug by narrowing scope quickly: reproduce, isolate, capture evidence, apply the smallest safe fix, then verify.
+
+## Checks
+
+- Reproduce the issue consistently and record exact command/path/error output.
+- Confirm environment assumptions (platform, output mode, env vars, script path) match the failing context.
+- Run targeted checks first (`mds doctor`, focused tests, route/file scans) before broad reruns.
+- Separate root-cause signals from secondary cascade errors.
+- Re-verify with the same reproduction path after the fix.
+
+## Preferred structure
+
+- Keep debugging notes concise in task output or project memory when the issue is recurring.
+- Prefer deterministic scripts over ad-hoc manual sequences.
+- Escalate from narrow test scope to broader validation only after targeted checks pass.
+
+## Example fix
+
+- Problem: Route crashes only on web server output with ambiguous stack traces.
+- Fix: Reproduce in server mode, isolate browser-global usage in shared module, add guards, rerun targeted test and Doctor scan.
+
+## Agent behavior
+
+- Start with high-risk failures (security, data loss, crashers), then address lower-risk warnings.
+- Keep users unblocked with concrete next commands and avoid speculative broad refactors before evidence is clear.
+- Delegate framework primitive questions to official Expo or React Native guidance, then apply MDS reproduction discipline, Doctor checks, and project-memory context.

package/bundles/vscode-copilot/.github/skills/deployment/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Deployment Readiness Skill"
+description: "Instructions for local checks before shipping an Expo app."
+---
+
+# Skill: Deployment Readiness
+
+Use before merging or releasing an Expo project to shared environments.
+
+## Main rule
+
+Treat deployment as a repeatable checklist: pass local quality gates, verify runtime configuration, and document rollback expectations before ship.
+
+## Checks
+
+- Run lint, type-check, tests, Expo Doctor, and production build/profile checks when scripts exist.
+- Verify env vars are documented and separated by client/server exposure level.
+- Confirm output mode and hosting assumptions match the selected platform strategy.
+- Confirm metadata/indexing basics are defined for web exports.
+- Record release and rollback notes for the current change batch.
+
+## Preferred structure
+
+- Keep release checks in scripts that CI and agents can run consistently.
+- Gate merge/publish flows on the same Doctor and package validation criteria.
+- Keep deployment conventions in `project/guidelines.md` and release tasks in `project/todo.md`.
+
+## Example fix
+
+- Problem: Release pipeline runs tests but skips Expo Doctor and build profile checks.
+- Fix: Add missing scripts, wire them into pre-merge checks, and document the required sequence in project memory.
+
+## Agent behavior
+
+- Run project-defined checks first; do not invent alternate release criteria.
+- Delegate framework deployment primitives to official Expo guidance, then apply MDS workflow rules for docs, Doctor parity, and rollback readiness.
+

package/bundles/vscode-copilot/.github/skills/dev-server-management/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Dev Server Management Skill"
+description: "Instructions for recovering Expo/Metro local dev-server state and resolving port/cache conflicts."
+---
+
+# Skill: Dev Server Management
+
+Use when Expo or Metro local development servers fail to boot cleanly, hang, or bind to conflicting ports.
+
+## Main rule
+
+Use a deterministic reset path first; do not work around unstable server state with ad-hoc port fallbacks.
+
+## Checks
+
+- Run `mds clear-expo-start`  before manual troubleshooting.
+- If a conflict remains, run `mds free-port <port...>` for blocked ports.
+- Confirm Expo/Metro caches are cleared before retrying startup.
+- Treat fallback to port `8082` as an unresolved state that requires full reset.
+- Confirm the same recovery scripts are available to teammates and automation.
+
+## Preferred structure
+
+- Keep project scripts for clear-expo-start and targeted port cleanup.
+- Standardize a single restart path in project memory (`project/guidelines.md`).
+- Use explicit “fresh” commands when booting local or production-like flows.
+
+## Example fix
+
+- Problem: `expo start` repeatedly falls back to `8082` after a partial crash.
+- Fix: Run `mds clear-expo-start`, free remaining blocked ports, clear cache, and restart via the project's clear-expo-start script.
+
+## Agent behavior
+
+- Prefer established MDS cleanup commands over custom shell sequences.
+- Avoid introducing alternate fallback port workflows that hide root-cause server state issues.
+- Delegate Expo or Metro mechanics to official Expo guidance, then apply MDS reset commands, script consistency, and onboarding defaults.

package/bundles/vscode-copilot/.github/skills/env-vars/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Environment Variables Skill"
+description: "Instructions for public/private env variable boundaries."
+---
+
+# Skill: Environment Variables
+
+Use when adding, reviewing, or debugging app configuration and secrets handling.
+
+## Main rule
+
+Keep a hard boundary between public client config and private server secrets; anything sensitive must never cross into `EXPO_PUBLIC_*` variables.
+
+## Checks
+
+- Confirm secrets (service-role keys, private tokens, payment secrets, passwords) are server-only.
+- Confirm `EXPO_PUBLIC_*` values are safe to expose in client bundles.
+- Validate required env keys exist for each runtime mode used by the project.
+- Ensure Supabase anon key usage is scoped to client-safe flows and service-role usage is server-only.
+- Verify env naming/docs are consistent across `.env` files, scripts, and project memory.
+
+## Preferred structure
+
+- Keep env access centralized through small typed config helpers.
+- Separate client-safe config and server-only config modules.
+- Document required keys and local setup in project memory and onboarding outputs.
+
+## Example fix
+
+- Problem: A route imports `EXPO_PUBLIC_SUPABASE_SERVICE_ROLE_KEY` from client config.
+- Fix: Move service-role key to server-only env access, switch client flow to anon key, and update docs/checks.
+
+## Agent behavior
+
+- Prioritize removing exposure risk before refactoring for style.
+- Delegate framework/env-loading primitives to official Expo guidance, then enforce MDS-specific security boundaries and Doctor alignment.
+

package/bundles/vscode-copilot/.github/skills/expo-router-architecture/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: "Expo Router Architecture Skill"
+description: "Instructions for reviewing and building thin Expo Router route files."
+---
+
+# Skill: Expo Router Architecture
+
+Use when structuring, reviewing, or refactoring Expo Router route code.
+
+## Main rule
+
+Keep route files thin: routing and composition belong in `app/`, while business/data logic lives in feature, service, and shared modules.
+
+## Checks
+
+- Confirm route files avoid direct DB calls, heavy business logic, and large side-effect chains.
+- Confirm shared UI blocks are extracted to component modules.
+- Confirm cross-route state is managed in stores/hooks instead of duplicated route-local logic.
+- Confirm route grouping/layout usage is intentional and not overloaded at root.
+- Confirm file size/complexity trends support long-term maintainability.
+
+## Preferred structure
+
+- Keep `app/` files focused on params, navigation, and screen composition.
+- Place business workflows in `src/features`.
+- Place side effects/integrations in `src/services` or `src/data`.
+- Keep reusable UI in `src/components` and cross-cutting helpers in hooks/utilities.
+
+## Example fix
+
+- Problem: A route file performs data fetching, mutation, and form business rules inline.
+- Fix: Move fetch/mutation logic to service modules, move workflow rules to a feature module, and keep the route as a thin screen wrapper.
+
+## Agent behavior
+
+- Prefer small, incremental extractions over broad rewrites.
+- Delegate framework routing primitives to official Expo Router guidance, then apply MDS rules for maintainable app-folder boundaries and Doctor-compatible architecture.
+

package/bundles/vscode-copilot/.github/skills/expo-ssr-safety/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Expo SSR Safety Skill"
+description: "Instructions for avoiding web/server runtime crashes."
+---
+
+# Skill: Expo SSR Safety
+
+Use when preparing or debugging Expo Router web/server output paths.
+
+## Main rule
+
+Assume server runtime first: guard browser-only APIs, isolate native-only code, and keep shared modules safe in both client and server contexts.
+
+## Checks
+
+- Guard `window`, `document`, `navigator`, `localStorage`, and `sessionStorage` access.
+- Confirm client-only packages are not imported by server/API execution paths.
+- Confirm storage/session access happens in client-safe lifecycle points.
+- Verify API routes and server modules do not rely on browser globals.
+- Validate dynamic imports or adapters for platform-specific behavior.
+
+## Preferred structure
+
+- Use small environment-check helpers for browser-global access.
+- Split client-only logic behind platform/runtime-specific modules.
+- Keep server-safe defaults and explicit fallbacks in shared utilities.
+
+## Example fix
+
+- Problem: Shared auth helper reads `localStorage` at module load and crashes SSR.
+- Fix: Move storage access into guarded runtime functions and provide a server-safe fallback.
+
+## Agent behavior
+
+- Fix crash-risk paths first, then clean up architecture.
+- Delegate framework SSR primitives to official Expo docs, then apply MDS-specific guard patterns and Doctor rule compatibility.
+