@mr.dj2u/cli 0.1.1 → 0.1.3

package/bundles/claude-code/skills/expo-router-architecture/SKILL.md

@@ -0,0 +1,37 @@
+---
+description: Use when structuring, reviewing, or refactoring Expo Router route code.
+---
+
+# 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/claude-code/skills/expo-ssr-safety/SKILL.md

@@ -0,0 +1,36 @@
+---
+description: Use when preparing or debugging Expo Router web/server output paths.
+---
+
+# 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/bundles/claude-code/skills/fix-seo/SKILL.md

@@ -0,0 +1,34 @@
+---
+description: Apply SEO metadata fixes for Expo web routes with MCP guidance and post-fix verification.
+disable-model-invocation: true
+---
+
+# /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 `mr-djs-dev-suite` 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/claude-code/skills/plugin-creation/SKILL.md

@@ -0,0 +1,45 @@
+---
+description: Use when building or extending an MDS plugin bundle for any agent client (Claude Code, Codex, Cursor, etc.).
+---
+
+# 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/claude-code/skills/prepare-deploy/SKILL.md

@@ -0,0 +1,36 @@
+---
+description: Prepare an Expo project for release using deployment-focused skills plus Doctor parity checks.
+disable-model-invocation: true
+---
+
+# /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 `mr-djs-dev-suite` 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/claude-code/skills/production-server-patterns/SKILL.md

@@ -0,0 +1,35 @@
+---
+description: Use when setting up or debugging how an Expo project serves production traffic.
+---
+
+# 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/claude-code/skills/project-onboarding/SKILL.md

@@ -0,0 +1,35 @@
+---
+description: Use when onboarding an existing Expo app into the MDS workflow after project creation.
+---
+
+# 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/claude-code/skills/project-research-plan/SKILL.md

@@ -0,0 +1,34 @@
+---
+description: Turn rough product notes/research into actionable MDS project memory and next-phase plan.
+disable-model-invocation: true
+---
+
+# /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 `mr-djs-dev-suite` 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/claude-code/skills/research-plan-intake/SKILL.md

@@ -0,0 +1,36 @@
+---
+description: Use when a user has partial product context (notes, research docs, or incomplete project memory) and needs it transformed 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/claude-code/skills/review-expo-project/SKILL.md

@@ -0,0 +1,37 @@
+---
+description: Review an Expo project with MCP-first diagnostics and skill-guided remediation.
+disable-model-invocation: true
+---
+
+# /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 `mr-djs-dev-suite` 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/claude-code/skills/run-doctor/SKILL.md

@@ -0,0 +1,37 @@
+---
+description: Run MDS Doctor as the primary health check for an Expo project.
+disable-model-invocation: true
+---
+
+# /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 `mr-djs-dev-suite` 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/claude-code/skills/seo-metadata/SKILL.md

@@ -0,0 +1,35 @@
+---
+description: Use when preparing Expo web routes for crawlability, sharing previews, and production indexing behavior.
+---
+
+# 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/claude-code/skills/super-stack-startup/SKILL.md

@@ -0,0 +1,38 @@
+---
+description: Use when kicking off a new app with `create-expo-super-stack` and transitioning into phase-based MDS 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/claude-code/skills/uniwind-theming/SKILL.md

@@ -0,0 +1,36 @@
+---
+description: Use when setting up or maintaining Tailwind v4 + Uniwind styling in Expo projects.
+---
+
+# 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/codex/.codex-plugin/plugin.json

@@ -0,0 +1,42 @@
+{
+  "name": "mr-djs-dev-suite",
+  "version": "0.1.3",
+  "description": "MDS Expo development workflows for review, onboarding, deployment readiness, and project continuation.",
+  "author": {
+    "name": "DJ Grimsley",
+    "url": "https://davidjgrimsley.com"
+  },
+  "homepage": "https://github.com/DavidJGrimsley/mr-djs-dev-suite",
+  "repository": "https://github.com/DavidJGrimsley/mr-djs-dev-suite",
+  "license": "MIT",
+  "keywords": [
+    "expo",
+    "react-native",
+    "mcp",
+    "doctor",
+    "onboarding",
+    "codex-plugin"
+  ],
+  "skills": "./skills/",
+  "mcpServers": "./.mcp.json",
+  "interface": {
+    "displayName": "Mr. DJ's Dev Suite",
+    "shortDescription": "MCP-first Expo review, doctor, onboarding, and deploy workflows",
+    "longDescription": "Generate and use MDS skills plus command playbooks for Expo project review, onboarding, deployment prep, SEO fixes, and phase-based continuation with reliable MCP and CLI fallback paths.",
+    "developerName": "MDS",
+    "category": "Coding",
+    "capabilities": [
+      "Interactive",
+      "Read",
+      "Write"
+    ],
+    "websiteURL": "https://github.com/DavidJGrimsley/mr-djs-dev-suite",
+    "defaultPrompt": [
+      "Review my Expo project and give me the next safe implementation steps.",
+      "Run a deployment-readiness check with Doctor and fix blockers first.",
+      "Continue the next task from my project/todo.md using MDS phase order."
+    ],
+    "brandColor": "#0A6A6A",
+    "screenshots": []
+  }
+}

package/bundles/codex/.mcp.json

@@ -0,0 +1,11 @@
+{
+  "mcpServers": {
+    "mr-djs-dev-suite": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "@mr.dj2u/mcp-server"
+      ]
+    }
+  }
+}

package/bundles/codex/README.md

@@ -0,0 +1,48 @@
+# Mr. DJ's Dev Suite Codex Plugin
+
+The Mr. DJ's Dev Suite Codex plugin bundle is generated from `packages/knowledge` and ships the Codex-native MDS surface: plugin manifest, MCP server config, generated skills, and command prompts.
+
+## What's Included
+
+- Codex plugin manifest: `.codex-plugin/plugin.json`
+- MCP server config: `.mcp.json`
+- Generated skills: `skills/<skill-id>/SKILL.md`
+- Command prompt files: `commands/*.md`
+
+The source of truth for skills remains `packages/knowledge/src/content/skills`.
+
+## One-Command Install
+
+Project scope installs MCP plus the local marketplace/plugin enable blocks into `.codex/config.toml`, copies this plugin into `plugins/mr-djs-dev-suite`, and registers it in `.agents/plugins/marketplace.json`:
+
+```sh
+mds agent install --client codex --scope project --target /path/to/your/expo-app
+mds agent verify --client codex --scope project --target /path/to/your/expo-app
+```
+
+User scope installs MCP plus the local marketplace/plugin enable blocks into `~/.codex/config.toml`, copies the plugin into `~/plugins/mr-djs-dev-suite`, and registers it in `~/.agents/plugins/marketplace.json`:
+
+```sh
+mds agent install --client codex --scope user
+mds agent verify --client codex --scope user
+mds agent install --client codex --scope user --dry-run
+```
+
+After install, restart Codex if needed so it picks up `mr-djs-dev-suite@mds-local`.
+
+## MCP-Only Fallback
+
+Use this when you only want predictable MCP tools/prompts and not the plugin/skills bundle:
+
+```sh
+mds mcp install --client codex --scope project --target /path/to/your/expo-app
+mds mcp install --client codex --scope user
+```
+
+## Regenerate
+
+```sh
+pnpm --filter @mr.dj2u/knowledge build
+```
+
+Do not edit generated plugin skills directly; update `packages/knowledge` and rebuild.

package/bundles/codex/commands/continue-development.md

@@ -0,0 +1,27 @@
+# /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 `mr-djs-dev-suite` 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.