@mr.dj2u/cli 0.1.12 → 0.1.14

package/bundles/codex/skills/workflow-run-doctor/SKILL.md

@@ -1,51 +1,51 @@
----
-name: "MDS Run Doctor"
-description: "Use when the user asks Mr. DJ's Dev Suite to run Doctor, run a health check, run CI checks, diagnose project status, or explain MDS Doctor findings."
----
-
-# Codex Workflow Routing
-
-- This is a Mr. DJ's Dev Suite plugin workflow. Plugin skills and command markdown are guidance only.
-- Prefer callable MDS MCP tools exposed by `@mr.dj2u/mcp-server` when this workflow names them.
-- Do not use stale package names such as `@mrdj/cli`. The CLI package is `@mr.dj2u/cli`; the executable is `mds`.
-- If a workflow specifically requires guided MDS MCP tools and they are unavailable, stop and tell the user to refresh or reinstall the MDS plugin/MCP server instead of inventing defaults.
-- For ordinary CLI workflows that do allow fallback, prefer `mds <command>` from PATH, then `npx -y -p @mr.dj2u/cli@latest mds <command>`.
-
-# /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. Pull targeted implementation guidance with `get_skill` (typically `deployment`, `debugging`, or `dev-server-management`).
-
-## MDS Routing Guardrails
-
-- Treat a request to run MDS Doctor as a request for the MDS MCP tool, not as a request to run app-local npm scripts.
-- Do not run `npm run mds:doctor`, `npm run doctor`, or other project package scripts as the MDS Doctor path unless the user explicitly asks for app scripts.
-- Never invoke `@mrdj/cli`; that package name is wrong. The published CLI package is `@mr.dj2u/cli` and its executable is `mds`.
-
-## CLI / Manual Fallback
-
-1. If MCP is not configured, install it manually:
-   - `mds mcp install --client <client> --scope project`
-2. Direct CLI alternatives:
-   - `mds doctor <projectPath>`
-   - `mds doctor <projectPath> --ci`
-   - `mds doctor <projectPath> --json`
-3. If `mds` is not on PATH, invoke the published CLI by binary name:
-   - `npx -y -p @mr.dj2u/cli@latest mds doctor <projectPath> --ci`
-
-## Verification And Output
-
-- Re-run Doctor after each fix batch.
-- Output: check summary, blocking errors first, and the exact command used for re-check.
+---
+name: "MDS Run Doctor"
+description: "Use when the user asks Mr. DJ's Dev Suite to run Doctor, run a health check, run CI checks, diagnose project status, or explain MDS Doctor findings."
+---
+
+# Codex Workflow Routing
+
+- This is a Mr. DJ's Dev Suite plugin workflow. Plugin skills and command markdown are guidance only.
+- Prefer callable MDS MCP tools exposed by `@mr.dj2u/mcp-server` when this workflow names them.
+- Do not use stale package names such as `@mrdj/cli`. The CLI package is `@mr.dj2u/cli`; the executable is `mds`.
+- If a workflow specifically requires guided MDS MCP tools and they are unavailable, stop and tell the user to refresh or reinstall the MDS plugin/MCP server instead of inventing defaults.
+- For ordinary CLI workflows that do allow fallback, prefer `mds <command>` from PATH, then `npx -y -p @mr.dj2u/cli@latest mds <command>`.
+
+# /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. Pull targeted implementation guidance with `get_skill` (typically `deployment`, `debugging`, or `dev-server-management`).
+
+## MDS Routing Guardrails
+
+- Treat a request to run MDS Doctor as a request for the MDS MCP tool, not as a request to run app-local npm scripts.
+- Do not run `npm run mds:doctor`, `npm run doctor`, or other project package scripts as the MDS Doctor path unless the user explicitly asks for app scripts.
+- Never invoke `@mrdj/cli`; that package name is wrong. The published CLI package is `@mr.dj2u/cli` and its executable is `mds`.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client <client> --scope project`
+2. Direct CLI alternatives:
+   - `mds doctor <projectPath>`
+   - `mds doctor <projectPath> --ci`
+   - `mds doctor <projectPath> --json`
+3. If `mds` is not on PATH, invoke the published CLI by binary name:
+   - `npx -y -p @mr.dj2u/cli@latest mds doctor <projectPath> --ci`
+
+## Verification And Output
+
+- Re-run Doctor after each fix batch.
+- Output: check summary, blocking errors first, and the exact command used for re-check.

package/bundles/codex/skills/workflow-wrap-up/SKILL.md

@@ -1,80 +1,80 @@
----
-name: "MDS Wrap Up"
-description: "Use when the user has finished testing and wants Mr. DJ's Dev Suite to run the final wrap-up workflow (Doctor, git inclusion checks, PR loop, CI fix retries, and merge policy guardrails)."
----
-
-# Codex Workflow Routing
-
-- This is a Mr. DJ's Dev Suite plugin workflow. Plugin skills and command markdown are guidance only.
-- Prefer callable MDS MCP tools exposed by `@mr.dj2u/mcp-server` when this workflow names them.
-- Do not use stale package names such as `@mrdj/cli`. The CLI package is `@mr.dj2u/cli`; the executable is `mds`.
-- If a workflow specifically requires guided MDS MCP tools and they are unavailable, stop and tell the user to refresh or reinstall the MDS plugin/MCP server instead of inventing defaults.
-- For ordinary CLI workflows that do allow fallback, prefer `mds <command>` from PATH, then `npx -y -p @mr.dj2u/cli@latest mds <command>`.
-
-# /wrap-up
-
-Run the post-testing release wrap-up flow: final local checks, git inclusion confirmation, PR loop, and merge handling.
-
-## Goal
-
-When the developer says testing is complete, finish the handoff safely by:
-
-1. Marking completed todo items.
-2. Running `mds doctor --ci`.
-3. Reviewing `git status` and confirming intentionally excluded files.
-4. Running the publish/PR/check loop.
-5. Handling merge according to policy defaults and repo overrides.
-
-## Required Flow Order
-
-1. Update `project/todo.md` only for tasks clearly completed in this session.
-2. Run `mds doctor --ci` before any git mutation.
-3. Review `git status --short` and list changed files.
-4. Confirm any intentionally omitted files with the developer before staging.
-5. Publish through GitHub flow (branch push + PR).
-6. Poll checks and unresolved feedback.
-7. Fix failures locally, rerun Doctor, push updates, and poll again.
-8. Repeat up to 5 cycles total.
-
-## GitHub Skill Routing
-
-Use GitHub workflows in this order when available:
-
-1. `github` for repo/PR context and routing.
-2. `yeet` for commit/push/open-or-update PR flow.
-3. `gh-fix-ci` for failed checks/log inspection and CI-driven fix loops.
-4. `gh-address-comments` when unresolved review threads are blocking merge.
-
-## Merge Policy
-
-Evaluate policy in this order:
-
-1. Explicit user instruction in the current session.
-2. Optional repo config at `project/release-policy.json`.
-3. Defaults if config is absent.
-
-Supported repo config shape:
-
-```json
-{
-  "wrapUp": {
-    "autoMergeTest": true,
-    "autoMergeMain": false
-  }
-}
-```
-
-Default behavior:
-
-- Auto-merge to `test`: enabled.
-- Per-repo override: allowed.
-- Auto-merge to `main`: never allowed.
-
-If the workflow targets `main` directly (no `test` branch flow), stop before merge and tell the developer to merge manually.
-
-## Guardrails
-
-- Never auto-merge to `main`.
-- Do not skip `mds doctor --ci` between fix cycles.
-- Do not assume omitted files are intentional; confirm them.
-- If checks or blocking threads still fail after 5 cycles, stop and request human help with a concise blocker summary.
+---
+name: "MDS Wrap Up"
+description: "Use when the user has finished testing and wants Mr. DJ's Dev Suite to run the final wrap-up workflow (Doctor, git inclusion checks, PR loop, CI fix retries, and merge policy guardrails)."
+---
+
+# Codex Workflow Routing
+
+- This is a Mr. DJ's Dev Suite plugin workflow. Plugin skills and command markdown are guidance only.
+- Prefer callable MDS MCP tools exposed by `@mr.dj2u/mcp-server` when this workflow names them.
+- Do not use stale package names such as `@mrdj/cli`. The CLI package is `@mr.dj2u/cli`; the executable is `mds`.
+- If a workflow specifically requires guided MDS MCP tools and they are unavailable, stop and tell the user to refresh or reinstall the MDS plugin/MCP server instead of inventing defaults.
+- For ordinary CLI workflows that do allow fallback, prefer `mds <command>` from PATH, then `npx -y -p @mr.dj2u/cli@latest mds <command>`.
+
+# /wrap-up
+
+Run the post-testing release wrap-up flow: final local checks, git inclusion confirmation, PR loop, and merge handling.
+
+## Goal
+
+When the developer says testing is complete, finish the handoff safely by:
+
+1. Marking completed todo items.
+2. Running `mds doctor --ci`.
+3. Reviewing `git status` and confirming intentionally excluded files.
+4. Running the publish/PR/check loop.
+5. Handling merge according to policy defaults and repo overrides.
+
+## Required Flow Order
+
+1. Update `project/todo.md` only for tasks clearly completed in this session.
+2. Run `mds doctor --ci` before any git mutation.
+3. Review `git status --short` and list changed files.
+4. Confirm any intentionally omitted files with the developer before staging.
+5. Publish through GitHub flow (branch push + PR).
+6. Poll checks and unresolved feedback.
+7. Fix failures locally, rerun Doctor, push updates, and poll again.
+8. Repeat up to 5 cycles total.
+
+## GitHub Skill Routing
+
+Use GitHub workflows in this order when available:
+
+1. `github` for repo/PR context and routing.
+2. `yeet` for commit/push/open-or-update PR flow.
+3. `gh-fix-ci` for failed checks/log inspection and CI-driven fix loops.
+4. `gh-address-comments` when unresolved review threads are blocking merge.
+
+## Merge Policy
+
+Evaluate policy in this order:
+
+1. Explicit user instruction in the current session.
+2. Optional repo config at `project/release-policy.json`.
+3. Defaults if config is absent.
+
+Supported repo config shape:
+
+```json
+{
+  "wrapUp": {
+    "autoMergeTest": true,
+    "autoMergeMain": false
+  }
+}
+```
+
+Default behavior:
+
+- Auto-merge to `test`: enabled.
+- Per-repo override: allowed.
+- Auto-merge to `main`: never allowed.
+
+If the workflow targets `main` directly (no `test` branch flow), stop before merge and tell the developer to merge manually.
+
+## Guardrails
+
+- Never auto-merge to `main`.
+- Do not skip `mds doctor --ci` between fix cycles.
+- Do not assume omitted files are intentional; confirm them.
+- If checks or blocking threads still fail after 5 cycles, stop and request human help with a concise blocker summary.

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

@@ -1,22 +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. Treat callable MDS MCP tools as the runtime behavior surface and prompt markdown as guidance only.
-
-## 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.
+---
+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. Treat callable MDS MCP tools as the runtime behavior surface and prompt markdown as guidance only.
+
+## Tool Routing
+
+- Use `doctor_scan_project` before release or broad refactors.
+- Use `doctor_scan_file` for focused route, env, SSR, or API changes.
+- Use `generate_refactor_plan` before moving architecture across folders.
+- Use `generate_deploy_checklist` before release or client handoff.
+- Use `list_skills`, `get_skill`, and `get_guide` before giving framework-specific guidance.
+
+## Guardrails
+
+- Keep project intent in `project/info.md` and technical rules in `project/guidelines.md`.
+- Prefer Expo-owned guidance for framework mechanics; MDS adds project memory, checks, defaults, and workflows.
+- Do not skip unresolved `# TodoForContext(optional):` markers before implementation.

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

@@ -1,8 +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 callable 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 -->
+<!-- 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 callable MDS MCP tools before broad edits: `doctor_scan_project`, `doctor_scan_file`, `generate_refactor_plan`, and `generate_deploy_checklist`.
+- Use `list_skills`, `get_skill`, and `get_guide` for MDS guidance, while delegating framework mechanics to official Expo/React Native guidance when available.
+- Keep route files thin, env secrets server-only, and release work gated by Doctor checks.
+<!-- END MDS COPILOT INSTRUCTIONS -->

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

@@ -1,40 +1,40 @@
----
-mode: "agent"
-description: "Run the MDS Continue Development workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /continue-development
-
-Resume work on an onboarded project by following MDS phase order from `project/todo.md`.
-
-## Arguments
-
-- `projectPath`: onboarded app path (default: current directory).
-
-## MCP-First Workflow
-
-1. Confirm the `mds` MCP server is available.
-2. Call `continue_project` first to get the active-phase brief.
-3. Pull `get_skill` for `continue-development` to enforce phase-first sequencing.
-4. If blockers appear, use `doctor_scan_project` and `doctor_explain_result` for targeted remediation before feature work.
-
-## MDS Routing Guardrails
-
-- Treat a request to continue development with MDS as a request for the MDS MCP tool and phase rules first.
-- Do not jump directly into app edits until `continue_project` or the CLI fallback has identified the active phase and blockers.
-- Never invoke `@mrdj/cli`; that package name is wrong. The published CLI package is `@mr.dj2u/cli` and its executable is `mds`.
-
-## CLI / Manual Fallback
-
-1. If MCP is not configured, install it manually:
-   - `mds mcp install --client <client> --scope project`
-2. Direct CLI flow:
-   - `mds continue <projectPath>`
-   - `mds doctor <projectPath>` when blockers are unclear.
-3. If `mds` is not on PATH, invoke the published CLI by binary name:
-   - `npx -y -p @mr.dj2u/cli@latest mds continue <projectPath>`
-
-## 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.
+---
+mode: "agent"
+description: "Run the MDS Continue Development workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /continue-development
+
+Resume work on an onboarded project by following MDS phase order from `project/todo.md`.
+
+## Arguments
+
+- `projectPath`: onboarded app path (default: current directory).
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Call `continue_project` first to get the active-phase brief.
+3. Pull `get_skill` for `continue-development` to enforce phase-first sequencing.
+4. If blockers appear, use `doctor_scan_project` and `doctor_explain_result` for targeted remediation before feature work.
+
+## MDS Routing Guardrails
+
+- Treat a request to continue development with MDS as a request for the MDS MCP tool and phase rules first.
+- Do not jump directly into app edits until `continue_project` or the CLI fallback has identified the active phase and blockers.
+- Never invoke `@mrdj/cli`; that package name is wrong. The published CLI package is `@mr.dj2u/cli` and its executable is `mds`.
+
+## CLI / Manual Fallback
+
+1. If MCP is not configured, install it manually:
+   - `mds mcp install --client <client> --scope project`
+2. Direct CLI flow:
+   - `mds continue <projectPath>`
+   - `mds doctor <projectPath>` when blockers are unclear.
+3. If `mds` is not on PATH, invoke the published CLI by binary name:
+   - `npx -y -p @mr.dj2u/cli@latest mds continue <projectPath>`
+
+## Verification And Output
+
+- Confirm the chosen task belongs to the active phase or has an explicit deferral note.
+- Output: selected next task, blockers, and validation commands to run after implementation.

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

@@ -1,37 +1,39 @@
----
-mode: "agent"
-description: "Run the MDS Create Expo Super Stack workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /create-expo-super-stack
-
-Create a new Expo app with the MDS Super Stack flow, using the published CESS CLI as the execution source of truth and callable MDS MCP tools as the guided intake surface.
-
-## Arguments
-
-- `parentDir`: folder where the new app directory should be created.
-- `appName`: app folder name.
-
-## Required MDS MCP Tool Flow
-
-1. Confirm the `mds` MCP server is available.
-2. Drive intake with `create_expo_super_stack_intake_step`.
-3. Ask exactly one question per turn.
-4. Always show the returned default and options.
-5. Never invent or silently accept defaults on the user's behalf.
-6. When the intake tool returns `confirm`, summarize the returned `summaryLines` and ask the user to confirm.
-7. After explicit confirmation, set `answers.confirmed=true`, call the intake tool again, and proceed only when it returns `ready`.
-8. Then call `create_expo_super_stack_generate` with `confirmed: true`.
-
-## Failure Behavior
-
-1. If the guided intake or generate tools are unavailable, stop.
-2. Call `mds_runtime_versions` to diagnose stale plugin or MCP installs.
-3. Tell the user to refresh or reinstall the MDS plugin/MCP server.
-4. Do not fall back to `--mds-yes` or direct CLI shortcuts unless the user explicitly asked for a fast non-interactive run.
-
-## Verification And Output
-
-- Confirm generated app has `project/info.md`, `project/todo.md`, `project/style.md`, and `project/guidelines.md`.
-- Confirm `project/todo.md` includes the auto-derived roadmap generated from normalized `project/info.md`.
-- Output: generated app path, onboarding status, and the handoff to open a fresh agent session inside the new app folder and run `mds continue`.
+---
+mode: "agent"
+description: "Run the MDS Create Expo Super Stack workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /create-expo-super-stack
+
+Create a new Expo app with the MDS Super Stack flow, using the published CESS CLI as the execution source of truth and callable MDS MCP tools as the guided intake surface.
+
+## Arguments
+
+- `parentDir`: folder where the new app directory should be created.
+- `appName`: app folder name.
+
+## Required MDS MCP Tool Flow
+
+1. Confirm the `mds` MCP server is available.
+2. If the user pasted or attached `info.md` / project memory, call `create_expo_super_stack_extract_info` first.
+3. Seed the returned answers into `create_expo_super_stack_intake_step` and use intake only for missing or ambiguous questions.
+4. Ask exactly one question per turn.
+5. Always show the returned default and options.
+6. Never invent or silently accept defaults on the user's behalf.
+7. If extraction found the app name, do not ask a second display-name question.
+8. When the intake tool returns `confirm`, summarize the returned `summaryLines` and ask the user to confirm.
+9. After explicit confirmation, set `answers.confirmed=true`, call the intake tool again, and proceed only when it returns `ready`.
+10. Then call `create_expo_super_stack_generate` with `confirmed: true`.
+
+## Failure Behavior
+
+1. If the guided intake or generate tools are unavailable, stop.
+2. Call `mds_runtime_versions` to diagnose stale plugin or MCP installs.
+3. Tell the user to refresh or reinstall the MDS plugin/MCP server.
+4. Do not fall back to `--mds-yes` or direct CLI shortcuts unless the user explicitly asked for a fast non-interactive run.
+
+## Verification And Output
+
+- Confirm generated app has `project/info.md`, `project/todo.md`, `project/style.md`, and `project/guidelines.md`.
+- Confirm `project/todo.md` includes the auto-derived roadmap generated from normalized `project/info.md`.
+- Output: generated app path, onboarding status, and the handoff to open a fresh agent session inside the new app folder and run `mds continue`.

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

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

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

@@ -1,34 +1,34 @@
----
-mode: "agent"
-description: "Run the MDS Prepare Deploy workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /prepare-deploy
-
-Prepare an Expo project for release using deployment-focused skills plus Doctor parity checks.
-
-## Arguments
-
-- `projectPath`: release candidate project path (default: current directory).
-- `includeSeo`: whether to include web metadata/indexing checks (default: `true` when web is targeted).
-
-## MCP-First Workflow
-
-1. Confirm the `mds` MCP server is available.
-2. Run `doctor_scan_project` in `ci` mode for release parity.
-3. Pull `get_skill` for `deployment`; if web is involved also pull `seo-metadata`.
-4. Use `knowledge_list_resources` (`kind: "rule"`) to confirm env hygiene, SSR safety, and metadata requirements.
-5. 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 <client> --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.
-- Output: release readiness status, unresolved blockers, and rollback/readiness notes.
+---
+mode: "agent"
+description: "Run the MDS Prepare Deploy workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /prepare-deploy
+
+Prepare an Expo project for release using deployment-focused skills plus Doctor parity checks.
+
+## Arguments
+
+- `projectPath`: release candidate project path (default: current directory).
+- `includeSeo`: whether to include web metadata/indexing checks (default: `true` when web is targeted).
+
+## MCP-First Workflow
+
+1. Confirm the `mds` MCP server is available.
+2. Run `doctor_scan_project` in `ci` mode for release parity.
+3. Pull `get_skill` for `deployment`; if web is involved also pull `seo-metadata`.
+4. Use `knowledge_list_resources` (`kind: "rule"`) to confirm env hygiene, SSR safety, and metadata requirements.
+5. 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 <client> --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.
+- Output: release readiness status, unresolved blockers, and rollback/readiness notes.