@mr.dj2u/knowledge 0.1.7 → 0.1.8

package/dist/content/reference/mcp-sdk-transport.md

@@ -1,30 +1,30 @@
-# MCP SDK Transport Pattern
-
-Source pattern: `mds-app-mcp/src/index.ts`.
-
-## Core Shape
-
-- Create a high-level `McpServer` from `@modelcontextprotocol/sdk/server/mcp.js`.
-- Register static markdown resources with stable `mds://` URIs.
-- Register tools with schemas and handlers that return MCP text content.
-- Register prompts for reusable agent workflows.
-- Connect with `StdioServerTransport` for local agent use.
-- Keep HTTP/SSE transport as a later hosting concern unless a client needs it.
-
-## MDS Suite Decision
-
-Phase 1 uses stdio as the production MCP transport because it works for local
-Codex/Claude workflows and avoids server lifecycle complexity. The server
-still exposes pure functions for tests and direct CLI verification:
-
-- `createMrdjMcpServer()`
-- `startStdioServer()`
-- `listResources()`
-- `readResource(uri)`
-- `executeTool(name, input)`
-
-## Resource Rule
-
-MCP resources must be generated from `packages/knowledge`, not hand-copied into
-`packages/mcp-server`.
-
+# MCP SDK Transport Pattern
+
+Source pattern: `mds-app-mcp/src/index.ts`.
+
+## Core Shape
+
+- Create a high-level `McpServer` from `@modelcontextprotocol/sdk/server/mcp.js`.
+- Register static markdown resources with stable `mds://` URIs.
+- Register tools with schemas and handlers that return MCP text content.
+- Register prompts for reusable agent workflows.
+- Connect with `StdioServerTransport` for local agent use.
+- Keep HTTP/SSE transport as a later hosting concern unless a client needs it.
+
+## MDS Suite Decision
+
+Phase 1 uses stdio as the production MCP transport because it works for local
+Codex/Claude workflows and avoids server lifecycle complexity. The server
+still exposes pure functions for tests and direct CLI verification:
+
+- `createMrdjMcpServer()`
+- `startStdioServer()`
+- `listResources()`
+- `readResource(uri)`
+- `executeTool(name, input)`
+
+## Resource Rule
+
+MCP resources must be generated from `packages/knowledge`, not hand-copied into
+`packages/mcp-server`.
+

package/dist/content/reference/reference-repo-evacuation.md

@@ -1,31 +1,31 @@
-# Reference Repo Evacuation
-
-Phase 1 captured the useful patterns from the temporary multi-root workspace so
-Mr. DJ's Dev Suite can run from a clean single-folder workspace.
-
-## Captured Sources
-
-| Source repo | Captured knowledge | Suite destination |
-| --- | --- | --- |
-| `mds-app-mcp` | MCP SDK server construction, stdio transport, resource registration, prompt registration, and guide loading pattern. | `reference/mcp-sdk-transport.md`, MCP server implementation |
-| `mds-pokemon-mcp` | MCP family naming and guide/resource convention. | Knowledge resource URI rules |
-| `mds-fne-mcp` | MCP family naming and tool/resource split. | Knowledge resource URI rules |
-| `time2pay` | Uniwind setup, CI-equivalent checks, env handling, Expo deployment shape, Doctor dogfood target. | Patterns, Doctor fixtures, `reference/doctor-dogfood.md` |
-| `DJsPortfolio` | API route proxy patterns, Drizzle schema examples, docs organization, route structure, Doctor dogfood target. | API/database/project patterns |
-| `PokePages` | Dynamic route hierarchies, Zustand stores, Drizzle migrations, Doctor dogfood target. | Routing/state/database patterns |
-| `not-hot-dog` | Small app route structure and docs memory convention. | Project/routing patterns |
-| `expo-super-template` | Post-create defaults, Uniwind Metro/global CSS setup, onboarding target shape, Doctor dogfood target. | Styling/onboarding guides |
-| `core-monorepo` | Turborepo package layout, shared package exports, package-manager detection, Doctor dogfood target. | Project/deployment patterns |
-| `mercury-bank-sdk` | Library package export fields, npm workspace scripts, build/test/typecheck workflow. | Project/library and package CI patterns |
-| `ads-sdk` | Small TypeScript SDK package shape and publish build workflow. | Package/CI reference notes |
-| `quantum-api` | Dual ESM/CJS SDK build pattern and generated package metadata workflow. | Package/CI reference notes |
-
-## Evacuation Rules
-
-- Keep repo names and relative file paths as source notes; do not depend on
-  machine-specific absolute paths.
-- Keep reference repos read-only during harvest.
-- Delete `temp/` clones after their patterns are promoted or intentionally
-  discarded.
-- A new engineer should be able to open only Mr. DJ's Dev Suite and still access
-  all Phase 1 knowledge through `packages/knowledge`.
+# Reference Repo Evacuation
+
+Phase 1 captured the useful patterns from the temporary multi-root workspace so
+Mr. DJ's Dev Suite can run from a clean single-folder workspace.
+
+## Captured Sources
+
+| Source repo | Captured knowledge | Suite destination |
+| --- | --- | --- |
+| `mds-app-mcp` | MCP SDK server construction, stdio transport, resource registration, prompt registration, and guide loading pattern. | `reference/mcp-sdk-transport.md`, MCP server implementation |
+| `mds-pokemon-mcp` | MCP family naming and guide/resource convention. | Knowledge resource URI rules |
+| `mds-fne-mcp` | MCP family naming and tool/resource split. | Knowledge resource URI rules |
+| `time2pay` | Uniwind setup, CI-equivalent checks, env handling, Expo deployment shape, Doctor dogfood target. | Patterns, Doctor fixtures, `reference/doctor-dogfood.md` |
+| `DJsPortfolio` | API route proxy patterns, Drizzle schema examples, docs organization, route structure, Doctor dogfood target. | API/database/project patterns |
+| `PokePages` | Dynamic route hierarchies, Zustand stores, Drizzle migrations, Doctor dogfood target. | Routing/state/database patterns |
+| `not-hot-dog` | Small app route structure and docs memory convention. | Project/routing patterns |
+| `expo-super-template` | Post-create defaults, Uniwind Metro/global CSS setup, onboarding target shape, Doctor dogfood target. | Styling/onboarding guides |
+| `core-monorepo` | Turborepo package layout, shared package exports, package-manager detection, Doctor dogfood target. | Project/deployment patterns |
+| `mercury-bank-sdk` | Library package export fields, npm workspace scripts, build/test/typecheck workflow. | Project/library and package CI patterns |
+| `ads-sdk` | Small TypeScript SDK package shape and publish build workflow. | Package/CI reference notes |
+| `quantum-api` | Dual ESM/CJS SDK build pattern and generated package metadata workflow. | Package/CI reference notes |
+
+## Evacuation Rules
+
+- Keep repo names and relative file paths as source notes; do not depend on
+  machine-specific absolute paths.
+- Keep reference repos read-only during harvest.
+- Delete `temp/` clones after their patterns are promoted or intentionally
+  discarded.
+- A new engineer should be able to open only Mr. DJ's Dev Suite and still access
+  all Phase 1 knowledge through `packages/knowledge`.

package/dist/content/skills/api-routes.md

@@ -1,33 +1,33 @@
-# 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).
-
+# 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/dist/content/skills/continue-development.md

@@ -1,32 +1,32 @@
-# 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.
+# 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/dist/content/skills/debugging.md

@@ -1,32 +1,32 @@
-# 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.
+# 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/dist/content/skills/deployment.md

@@ -1,32 +1,32 @@
-# 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.
-
+# 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/dist/content/skills/dev-server-management.md

@@ -1,32 +1,32 @@
-# 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.
+# 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/dist/content/skills/env-vars.md

@@ -1,32 +1,32 @@
-# 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.
-
+# 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/dist/content/skills/expo-router-architecture.md

@@ -1,33 +1,33 @@
-# 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.
-
+# 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.
+