@mr.dj2u/cli 0.1.12 → 0.1.14

package/bundles/vscode-copilot/.github/prompts/project-research-plan.prompt.md

@@ -1,34 +1,34 @@
----
-mode: "agent"
-description: "Run the MDS Project Research Plan workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /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 `mds` 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 <client> --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.
+---
+mode: "agent"
+description: "Run the MDS Project Research Plan workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /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 `mds` 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 <client> --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/vscode-copilot/.github/prompts/push-merge-loop.prompt.md

@@ -1,30 +1,30 @@
----
-mode: "agent"
-description: "Run the MDS Push Merge Loop workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /push-merge-loop
-
-Execute the short PR iteration loop for the test branch with strict quality gates.
-
-## Goal
-
-Push intentional changes with a meaningful commit message, open/update a PR to `test`, poll for feedback and failed checks, fix issues, and merge to `test` once all checks are green.
-
-## Loop Rules
-
-1. Run `mds doctor --ci` before any git mutation.
-2. Stage only intentional files and create a meaningful commit message.
-3. Push branch and open or update a PR targeting `test`.
-4. Wait about 2 minutes, then poll PR comments, review threads, and failed checks.
-5. Fix issues locally, rerun Doctor, push updates, and poll again.
-6. Repeat polling/fix cycles up to 5 total iterations.
-7. Merge to `test` only when all required checks are green and no unresolved blocking feedback remains.
-
-## Guardrails
-
-- Do not merge when required checks are failing.
-- Do not skip Doctor between fix cycles.
-- Keep a concise changelog per iteration: what failed, what was changed, what passed.
-- If still failing after 5 cycles, stop and summarize remaining blockers with concrete next actions.
-
+---
+mode: "agent"
+description: "Run the MDS Push Merge Loop workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /push-merge-loop
+
+Execute the short PR iteration loop for the test branch with strict quality gates.
+
+## Goal
+
+Push intentional changes with a meaningful commit message, open/update a PR to `test`, poll for feedback and failed checks, fix issues, and merge to `test` once all checks are green.
+
+## Loop Rules
+
+1. Run `mds doctor --ci` before any git mutation.
+2. Stage only intentional files and create a meaningful commit message.
+3. Push branch and open or update a PR targeting `test`.
+4. Wait about 2 minutes, then poll PR comments, review threads, and failed checks.
+5. Fix issues locally, rerun Doctor, push updates, and poll again.
+6. Repeat polling/fix cycles up to 5 total iterations.
+7. Merge to `test` only when all required checks are green and no unresolved blocking feedback remains.
+
+## Guardrails
+
+- Do not merge when required checks are failing.
+- Do not skip Doctor between fix cycles.
+- Keep a concise changelog per iteration: what failed, what was changed, what passed.
+- If still failing after 5 cycles, stop and summarize remaining blockers with concrete next actions.
+

package/bundles/vscode-copilot/.github/prompts/review-expo-project.prompt.md

@@ -1,34 +1,34 @@
----
-mode: "agent"
-description: "Run the MDS Review Expo Project workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /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 `mds` 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. 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 <client> --scope project`
-2. If MCP still cannot run, use direct CLI flows:
-   - `mds continue <projectPath>`
-   - `mds doctor <projectPath> --ci`
-
-## Verification And Output
-
-- Re-run `doctor_scan_project` (or `mds doctor --ci`) after fixes.
-- Output: blocker summary, failing checks, recommended next task, and concrete follow-up commands.
+---
+mode: "agent"
+description: "Run the MDS Review Expo Project workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /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 `mds` 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. 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 <client> --scope project`
+2. If MCP still cannot run, use direct CLI flows:
+   - `mds continue <projectPath>`
+   - `mds doctor <projectPath> --ci`
+
+## Verification And Output
+
+- Re-run `doctor_scan_project` (or `mds doctor --ci`) after fixes.
+- Output: blocker summary, failing checks, recommended next task, and concrete follow-up commands.

package/bundles/vscode-copilot/.github/prompts/run-doctor.prompt.md

@@ -1,43 +1,43 @@
----
-mode: "agent"
-description: "Run the MDS Run Doctor workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /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 `mds` 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.
+---
+mode: "agent"
+description: "Run the MDS Run Doctor workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /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 `mds` 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/vscode-copilot/.github/prompts/wrap-up.prompt.md

@@ -1,72 +1,72 @@
----
-mode: "agent"
-description: "Run the MDS Wrap Up workflow with callable MDS MCP diagnostics and explicit fallback rules."
----
-
-# /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.
+---
+mode: "agent"
+description: "Run the MDS Wrap Up workflow with callable MDS MCP diagnostics and explicit fallback rules."
+---
+
+# /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/skills/super-stack-startup/SKILL.md

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

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

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

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