@mr.dj2u/cli 0.1.0 → 0.1.2

package/bundles/vscode-copilot/.github/skills/plugin-creation/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: "MDS Plugin Creation Skill"
+description: "Instructions for building a new MDS plugin bundle for Claude Code, Codex, Cursor, or any AI agent client."
+---
+
+# Skill: MDS Plugin Creation
+
+Use when building or extending an MDS plugin bundle for any agent client (Claude Code, Codex, Cursor, etc.).
+
+## Main rule
+
+Plugins are thin bundles. `packages/knowledge` is the source of truth for skills, command prompts, checklists, and examples. Do not hand-author plugin skill/command copies in plugin folders.
+
+## Structure conventions
+
+Every MDS plugin lives in `plugins/<client-name>/`:
+
+```
+plugins/<client-name>/
+  README.md
+  CLAUDE.md            # Claude-specific merge instructions (if relevant)
+  .mcp.json
+  commands/            # generated command markdown from canonical prompt specs
+  skills/              # generated skill files
+```
+
+## Checks
+
+- Skill markdown lives only in `packages/knowledge/src/content/skills/`.
+- Prompt/command markdown lives only in `packages/knowledge/src/content/prompts/`.
+- `plugins/<client>/skills/` remains generated output and is not manually edited.
+- Commands reference real MCP tool names from `packages/mcp-server`.
+- MCP config uses the `mr-djs-dev-suite` server key.
+
+## Adding a plugin capability
+
+1. Add or update canonical content in `packages/knowledge/src/content/*`.
+2. Update canonical prompt metadata in `packages/knowledge/src/prompts/index.ts`.
+3. Regenerate outputs via `pnpm --filter @mr.dj2u/knowledge build`.
+4. Verify generated plugin assets under `plugins/codex/` and `plugins/claude-code/`.
+
+## Agent behavior
+
+- Prefer extending canonical knowledge specs over patching generated plugin files.
+- Keep command prompts action-oriented and generated from canonical prompt specs, with clear fallback paths.
+- Delegate framework guidance to Expo-owned skills/docs when available; layer MDS project-memory and workflow guidance on top.

package/bundles/vscode-copilot/.github/skills/production-server-patterns/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: "Production Server Patterns Skill"
+description: "Instructions for choosing and running Expo production serving modes."
+---
+
+# Skill: Production Server Patterns
+
+Use when setting up or debugging how an Expo project serves production traffic.
+
+## Main rule
+
+Pick one explicit production serving mode per environment and codify it in scripts; avoid mixed runtime assumptions.
+
+## Checks
+
+- Confirm selected mode is documented: managed Expo/EAS, Express adapter, or dual-server.
+- Confirm serving scripts match the selected runtime (`npx expo serve`, `node server.js`, or dual process scripts).
+- Confirm routing boundaries are clear when app and API are separate services.
+- Confirm env var ownership differs correctly across app server and API server in dual-server mode.
+- Confirm “fresh” start scripts exist where server state/caches can cause drift.
+
+## Preferred structure
+
+- Define `serve:prod` and `serve:prod:fresh` scripts for the chosen mode.
+- Keep server bootstrap and adapter code in dedicated files/modules.
+- Keep deployment notes aligned with runtime mode in project memory.
+
+## Example fix
+
+- Problem: Team mixes Expo serve and custom Express commands, causing inconsistent behavior.
+- Fix: Select one primary mode per environment, standardize scripts, and document routing/env boundaries.
+
+## Agent behavior
+
+- Use the project’s declared serving mode unless a migration is explicitly requested.
+- Delegate framework runtime primitives to official Expo docs, then enforce MDS conventions for script consistency, environment boundaries, and operational clarity.

package/bundles/vscode-copilot/.github/skills/project-onboarding/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: "Project Onboarding Skill"
+description: "Instructions for onboarding an existing Expo app into MDS project memory and workflow."
+---
+
+# Skill: Project Onboarding
+
+Use when onboarding an existing Expo app into the MDS workflow after project creation.
+
+## Main rule
+
+Establish project memory and workflow defaults first, then scaffold only the selected technical additions.
+
+## Checks
+
+- Confirm onboarding target is the existing app folder (not a parent directory).
+- Confirm project memory files exist or are generated: `project/info.md`, `project/todo.md`, `project/style.md`, `project/guidelines.md`.
+- Confirm unresolved context markers are cleared before deep implementation work.
+- Confirm selected defaults (styling, state, data, CI, route placement) are documented in project memory.
+- Run Doctor after onboarding changes to validate baseline health.
+
+## Preferred structure
+
+- Use conversational intake to capture audience, flows, data needs, platform targets, and deployment intent.
+- Keep visual guidance in `project/style.md`; keep technical/agent rules in `project/guidelines.md`.
+- Keep onboarding outputs phase-based so follow-up work can continue from `project/todo.md`.
+
+## Example fix
+
+- Problem: Team starts coding before onboarding, causing missing docs and conflicting architecture assumptions.
+- Fix: Run onboarding flow, generate canonical project memory, reconcile open context markers, then resume implementation using phase order.
+
+## Agent behavior
+
+- Ask one focused onboarding question at a time when required by the flow.
+- Delegate framework primitive setup guidance to official Expo resources, then layer MDS project-memory and workflow automation rules.

package/bundles/vscode-copilot/.github/skills/research-plan-intake/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Research Plan Intake Skill"
+description: "Instructions for turning raw research and notes into canonical MDS project memory."
+---
+
+# Skill: Research Plan Intake
+
+Use when a user has partial product context (notes, research docs, or incomplete project memory) and needs it transformed into canonical MDS project memory.
+
+## Main rule
+
+Normalize fragmented input into decision-ready `project/info.md` and `project/style.md` structure without inventing missing product facts.
+
+## Checks
+
+- Parse provided artifacts and classify each required section as clear, ambiguous, or unknown.
+- Reuse clear sections directly; ask focused follow-up only for ambiguous or missing high-impact decisions.
+- Keep visual guidance in style memory and technical/process guidance in guidelines memory.
+- Confirm resulting project memory aligns with current roadmap phase and target platforms.
+- Record unresolved unknowns explicitly instead of guessing.
+
+## Preferred structure
+
+- Accept inputs from pasted markdown, notes, and prior project memory files.
+- Map extracted content into canonical sections with concise normalization.
+- Produce follow-up questions only where answers materially change implementation direction.
+
+## Example fix
+
+- Problem: User provides a long brainstorm doc with no clear MVP flow or audience.
+- Fix: Extract known context, mark missing decision points, ask targeted follow-up, then generate canonical project memory sections.
+
+## Agent behavior
+
+- Preserve user intent and wording where it is already clear.
+- Keep uncertainty visible and collaborative; do not fill strategic gaps with assumptions that can misdirect implementation.
+- Treat this as an MDS-only project-memory skill: use official framework guidance only after product intent is clear, then record the MDS workflow context agents need.

package/bundles/vscode-copilot/.github/skills/seo-metadata/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: "SEO Metadata Skill"
+description: "Instructions for production web metadata, canonical URLs, and indexing strategy."
+---
+
+# Skill: SEO Metadata
+
+Use when preparing Expo web routes for crawlability, sharing previews, and production indexing behavior.
+
+## Main rule
+
+Define metadata intentionally per route group and ensure canonical/indexing strategy is explicit before release.
+
+## Checks
+
+- Confirm title, description, and canonical strategy are defined for production web routes.
+- Confirm Open Graph and social preview metadata exist for key entry routes.
+- Confirm dynamic routes have deterministic metadata sources.
+- Confirm sitemap and robots strategy is documented for the chosen web output mode.
+- Confirm duplicate or conflicting titles/canonicals are resolved.
+
+## Preferred structure
+
+- Keep shared metadata defaults centralized and route-level overrides explicit.
+- Keep metadata source-of-truth close to route ownership boundaries.
+- Keep SEO rules documented in project memory so onboarding and Doctor checks align.
+
+## Example fix
+
+- Problem: Dynamic content routes ship with repeated title/description and no canonical mapping.
+- Fix: Add route-level metadata builder, include canonical generation logic, and update sitemap coverage.
+
+## Agent behavior
+
+- Prioritize production routes and highest-traffic entry points first.
+- Delegate framework metadata primitives to official Expo guidance, then enforce MDS standards for canonical/indexing completeness.

package/bundles/vscode-copilot/.github/skills/super-stack-startup/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: "Super Stack Startup Skill"
+description: "Instructions for running create-expo-super-stack while keeping packages/knowledge as the source of truth and handing off to phase-based app development."
+---
+
+# Skill: Super Stack Startup
+
+Use when kicking off a new app with `create-expo-super-stack` and transitioning into phase-based MDS development.
+
+## Main rule
+
+Run generator + onboarding as one guided flow, keep agent-facing wording sourced from `packages/knowledge`, and let the current CLI implementation remain the execution source of truth.
+
+## Checks
+
+- Confirm command runs from a parent directory where the app folder does not already exist.
+- Confirm stack choices and MDS intake values are captured before generation.
+- Confirm generated app includes project memory and onboarding next-step output.
+- Confirm prompt and skill text stay thin and defer detailed behavior to the canonical knowledge package.
+- Confirm unresolved context markers are resolved before coding begins.
+- Confirm follow-up uses `mds continue` from inside the generated app folder.
+
+## Preferred structure
+
+- Keep startup conversation in plain language and summarize choices before execution.
+- Keep generation details in scripts/flags, but keep user-facing flow conversational.
+- Keep post-generation workflow phase-based using the generated `project/todo.md`.
+- Prefer shared knowledge content over duplicating long onboarding prose in plugin or MCP wrappers.
+
+## Example fix
+
+- Problem: User runs generation inside an existing app folder and gets mixed state artifacts.
+- Fix: Restart from parent directory, regenerate cleanly, then continue in a new app-folder session.
+
+## Agent behavior
+
+- Prevent ambiguous execution context and confirm folder target before running generation.
+- Delegate framework/template primitives to upstream Expo tooling, then apply MDS memory shaping, defaults, and continue-workflow conventions.
+- Update `packages/knowledge` first when the wording or flow changes, then regenerate downstream surfaces from it.

package/bundles/vscode-copilot/.github/skills/uniwind-theming/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: "Uniwind Theming Skill"
+description: "Instructions for Tailwind v4 and Uniwind setup."
+---
+
+# 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/.vscode/mcp.json

@@ -0,0 +1,11 @@
+{
+  "servers": {
+    "mds": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "@mr.dj2u/mcp-server"
+      ]
+    }
+  }
+}

package/bundles/vscode-copilot/.vscode/settings.json

@@ -0,0 +1,14 @@
+{
+  "github.copilot.chat.codeGeneration.useInstructionFiles": true,
+  "chat.promptFilesLocations": {
+    ".github/prompts": true
+  },
+  "chat.agentFilesLocations": {
+    ".github/agents": true
+  },
+  "chat.useAgentSkills": true,
+  "chat.agentSkillsLocations": {
+    ".github/skills": true,
+    "~/.copilot/skills": true
+  }
+}

package/bundles/vscode-copilot/README.md

@@ -0,0 +1,32 @@
+# Mr. DJ's Dev Suite VS Code Copilot Bundle
+
+This bundle is generated from `packages/knowledge` and targets native VS Code Copilot customization surfaces:
+
+- `.vscode/mcp.json` for the MDS MCP server.
+- `.vscode/settings.json` for Copilot customization discovery settings.
+- `.github/copilot-instructions.md` for workspace instructions.
+- `.github/agents/mds.agent.md` for a custom Copilot agent.
+- `.github/prompts/*.prompt.md` for reusable prompt workflows.
+- `.github/skills/*/SKILL.md` for generated MDS skills.
+
+## Project Install
+
+```bash
+mds agent install --client vscode --scope project --target .
+```
+
+## User Install
+
+```bash
+mds agent install --client vscode --scope user
+```
+
+User-scope setup copies the generated assets into `~/.copilot` and uses VS Code's `code --add-mcp` flow for the MCP server when the `code` command is available. If it is not available, the CLI prints the exact manual command.
+
+## Verify
+
+```bash
+mds agent verify --client vscode --target .
+```
+
+Skills and prompt workflows are generated from the knowledge package. Do not edit generated copies by hand; update `packages/knowledge/src/content` or the generator scripts instead.

package/bundles/vscode-copilot/user/.copilot/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/user/.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/user/.copilot/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/user/.copilot/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/user/.copilot/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/user/.copilot/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/user/.copilot/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/user/.copilot/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/user/.copilot/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.
+