@mr.dj2u/knowledge 0.1.0

package/dist/content/reference/doctor-dogfood.md

@@ -0,0 +1,42 @@
+# Doctor Dogfood Notes
+
+Phase 1 dogfood targets:
+
+- `time2pay`
+- `DJsPortfolio`
+- `PokePages`
+- `expo-super-template`
+- `core-monorepo`
+
+## Expected Use
+
+Before the reference repos are removed from the workspace, run Doctor in
+non-mutating mode against each target and record whether the suite can produce a
+structured report. The goal is not to make every external repo perfect; it is to
+prove Doctor handles real Expo and monorepo shapes without crashing.
+
+## Minimum Acceptance
+
+- `doctor --json --scripts=false` completes for each target.
+- Reports include project docs, package scripts, env hygiene, Expo config, SSR,
+  SEO, and app architecture where applicable.
+- Findings are actionable and avoid leaking env values.
+
+## Phase 1 Run Summary
+
+Command shape:
+
+```bash
+node packages/cli/dist/cli.js doctor <target> --json --scripts=false
+```
+
+| Target | Errors | Warnings | Passed | Skipped | Notes |
+| --- | ---: | ---: | ---: | ---: | --- |
+| `time2pay` | 0 | 1 | 7 | 0 | Structured report completed. |
+| `DJsPortfolio` | 0 | 2 | 6 | 0 | Structured report completed. |
+| `PokePages` | 1 | 3 | 4 | 0 | Package scripts reference missing built server files. |
+| `expo-super-template` | 1 | 3 | 4 | 0 | Package scripts reference a missing server file. |
+| `core-monorepo` | 0 | 2 | 3 | 3 | Structured report completed for monorepo root. |
+
+The dogfood pass proves Doctor can scan the required reference shapes without
+needing those repos mounted permanently.

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

@@ -0,0 +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`.
+

package/dist/content/reference/package-ci-patterns.md

@@ -0,0 +1,24 @@
+# Package And CI Patterns
+
+Harvested from `core-monorepo`, `mercury-bank-sdk`, `ads-sdk`, and
+`quantum-api`.
+
+## Useful Patterns
+
+- Root `ci` scripts should compose lint, typecheck, tests, and build in the
+  same order expected by GitHub checks.
+- Package managers differ by repo; Doctor should detect `packageManager` first,
+  then lockfiles.
+- SDK packages should expose `types`, ESM entry points, and clear build scripts.
+- Dual ESM/CJS packages need explicit metadata generation for the CJS output
+  folder instead of relying on package-manager magic.
+- Monorepos should let root scripts fan out through Turbo or workspace commands,
+  while leaf packages keep simple `build`, `typecheck`, and `test` scripts.
+
+## Doctor Implications
+
+- Missing `lint` or `typecheck` is a warning for local repos.
+- Broken script file targets are errors.
+- `--ci` should run available checks, not assume every repo has the same script
+  names.
+

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

@@ -0,0 +1,31 @@
+# Reference Repo Evacuation
+
+Phase 1 captured the useful patterns from the temporary multi-root workspace so
+`mds-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 `mds-dev-suite` and still access
+  all Phase 1 knowledge through `packages/knowledge`.

package/dist/content/resource-index.json

@@ -0,0 +1,67 @@
+[
+  "checklists/ship-test-loop.md",
+  "checklists/unified-agent-bundle-validation.md",
+  "examples/ship-test-loop.md",
+  "examples/unified-agent-bundle-bootstrap.md",
+  "guides/animation-performance.md",
+  "guides/post-create-onboarding.md",
+  "patterns/api/api-routes.md",
+  "patterns/api/error-handling.md",
+  "patterns/database/drizzle-schema.md",
+  "patterns/database/migrations.md",
+  "patterns/database/query-organization.md",
+  "patterns/database/relations.md",
+  "patterns/deployment/build-configuration.md",
+  "patterns/deployment/ci-cd-patterns.md",
+  "patterns/deployment/environment-config.md",
+  "patterns/deployment/hosting-setup.md",
+  "patterns/project/configuration-patterns.md",
+  "patterns/project/documentation-org.md",
+  "patterns/project/folder-structure.md",
+  "patterns/project/library-exports.md",
+  "patterns/project/monorepo-structure.md",
+  "patterns/routing/dynamic-routes.md",
+  "patterns/routing/file-based-routing.md",
+  "patterns/routing/route-groups.md",
+  "patterns/state/persistence-middleware.md",
+  "patterns/state/selector-hooks.md",
+  "patterns/state/store-organization.md",
+  "patterns/state/zustand-patterns.md",
+  "patterns/styling/component-styling.md",
+  "patterns/styling/responsive-patterns.md",
+  "patterns/styling/theme-configuration.md",
+  "patterns/styling/uniwind-setup.md",
+  "prompts/continue-development.md",
+  "prompts/create-expo-super-stack.md",
+  "prompts/fix-seo.md",
+  "prompts/onboard-new-expo-app.md",
+  "prompts/prepare-deploy.md",
+  "prompts/project-research-plan.md",
+  "prompts/review-expo-project.md",
+  "prompts/run-doctor.md",
+  "prompts/ship-test-loop.md",
+  "reference/create-expo-stack-uniwind.md",
+  "reference/doctor-dogfood.md",
+  "reference/mcp-sdk-transport.md",
+  "reference/package-ci-patterns.md",
+  "reference/reference-repo-evacuation.md",
+  "rules/app-folder-architecture.md",
+  "rules/env-hygiene.md",
+  "rules/seo-metadata.md",
+  "rules/ssr-safety.md",
+  "skills/api-routes.md",
+  "skills/continue-development.md",
+  "skills/debugging.md",
+  "skills/deployment.md",
+  "skills/dev-server-management.md",
+  "skills/env-vars.md",
+  "skills/expo-router-architecture.md",
+  "skills/expo-ssr-safety.md",
+  "skills/plugin-creation.md",
+  "skills/production-server-patterns.md",
+  "skills/project-onboarding.md",
+  "skills/research-plan-intake.md",
+  "skills/seo-metadata.md",
+  "skills/super-stack-startup.md",
+  "skills/uniwind-theming.md"
+]

package/dist/content/rules/app-folder-architecture.md

@@ -0,0 +1,13 @@
+# App Folder Architecture Rule
+
+Keep Expo Router route files focused on routing, layout, screen composition, and
+small view-state glue.
+
+Warn when route files:
+
+- exceed the configured line budget,
+- import database clients directly,
+- contain heavy form or business logic,
+- duplicate large UI chunks,
+- use browser globals without a client-only guard.
+

package/dist/content/rules/env-hygiene.md

@@ -0,0 +1,9 @@
+# Environment Hygiene Rule
+
+Never expose secrets through `EXPO_PUBLIC_` variables. Public variables are
+bundled for the client.
+
+Treat names containing `SECRET`, `SERVICE_ROLE`, `PRIVATE`, `PASSWORD`,
+`TOKEN`, or `STRIPE_SECRET` as unsafe when they are prefixed with
+`EXPO_PUBLIC_`.
+

package/dist/content/rules/seo-metadata.md

@@ -0,0 +1,7 @@
+# SEO Metadata Rule
+
+Production Expo web routes should have a route-level metadata strategy.
+
+Warn when web apps have no obvious title, description, sitemap, robots, Open
+Graph, canonical, or dynamic-route metadata plan.
+

package/dist/content/rules/ssr-safety.md

@@ -0,0 +1,9 @@
+# SSR Safety Rule
+
+Expo web routes must not assume browser-only globals are available during
+render.
+
+Warn on unguarded `window`, `document`, `localStorage`, `sessionStorage`, and
+`navigator` references in route files. Prefer `useEffect`, explicit
+`typeof window !== 'undefined'` guards, or a storage adapter.
+

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

@@ -0,0 +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).
+

package/dist/content/skills/continue-development.md

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

package/dist/content/skills/debugging.md

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

package/dist/content/skills/deployment.md

@@ -0,0 +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.
+

package/dist/content/skills/dev-server-management.md

@@ -0,0 +1,31 @@
+# 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...>` (or legacy `mds free-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.

package/dist/content/skills/env-vars.md

@@ -0,0 +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.
+

package/dist/content/skills/expo-router-architecture.md

@@ -0,0 +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.
+

package/dist/content/skills/expo-ssr-safety.md

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

package/dist/content/skills/plugin-creation.md

@@ -0,0 +1,41 @@
+# 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 `mds-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 MCP-first with clear fallback paths.
+- Delegate framework guidance to Expo-owned skills/docs when available; layer MDS project-memory and workflow guidance on top.

package/dist/content/skills/production-server-patterns.md

@@ -0,0 +1,31 @@
+# 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/dist/content/skills/project-onboarding.md

@@ -0,0 +1,31 @@
+# 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/dist/content/skills/research-plan-intake.md

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