@mr.dj2u/knowledge 0.1.0 → 0.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/content/checklists/{ship-test-loop.md → push-merge-loop.md} +2 -1
- package/dist/content/checklists/unified-agent-bundle-validation.md +3 -2
- package/dist/content/examples/{ship-test-loop.md → push-merge-loop.md} +3 -2
- package/dist/content/guides/post-create-onboarding.md +63 -21
- package/dist/content/patterns/project/configuration-patterns.md +4 -4
- package/dist/content/patterns/project/documentation-org.md +15 -15
- package/dist/content/patterns/project/monorepo-structure.md +3 -3
- package/dist/content/prompts/continue-development.md +11 -3
- package/dist/content/prompts/create-expo-super-stack.md +31 -29
- package/dist/content/prompts/fix-seo.md +3 -3
- package/dist/content/prompts/prepare-deploy.md +3 -3
- package/dist/content/prompts/project-research-plan.md +3 -3
- package/dist/content/prompts/{ship-test-loop.md → push-merge-loop.md} +2 -1
- package/dist/content/prompts/review-expo-project.md +3 -3
- package/dist/content/prompts/run-doctor.md +11 -3
- package/dist/content/prompts/wrap-up.md +67 -0
- package/dist/content/reference/create-expo-stack-uniwind.md +29 -29
- package/dist/content/reference/mcp-sdk-transport.md +30 -30
- package/dist/content/reference/reference-repo-evacuation.md +31 -31
- package/dist/content/resource-index.json +4 -3
- package/dist/content/skills/continue-development.md +1 -0
- package/dist/content/skills/debugging.md +1 -0
- package/dist/content/skills/dev-server-management.md +2 -1
- package/dist/content/skills/plugin-creation.md +3 -3
- package/dist/content/skills/research-plan-intake.md +1 -0
- package/dist/content/skills/super-stack-startup.md +4 -1
- package/dist/index.js +14 -14
- package/dist/index.js.map +1 -1
- package/dist/patterns/index.js +1 -1
- package/dist/patterns/index.js.map +1 -1
- package/dist/prompts/index.d.ts.map +1 -1
- package/dist/prompts/index.js +36 -10
- package/dist/prompts/index.js.map +1 -1
- package/package.json +55 -50
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# Push-Merge Loop Checklist
|
|
2
2
|
|
|
3
3
|
Use this checklist when running the PR loop into `test`.
|
|
4
4
|
|
|
@@ -14,3 +14,4 @@ Use this checklist when running the PR loop into `test`.
|
|
|
14
14
|
10. Push and poll again.
|
|
15
15
|
11. Repeat up to 5 cycles.
|
|
16
16
|
12. Merge only when checks are green and blockers are cleared.
|
|
17
|
+
|
|
@@ -1,8 +1,9 @@
|
|
|
1
|
-
|
|
1
|
+
# Unified Agent Bundle Validation Checklist
|
|
2
2
|
|
|
3
3
|
Phase 9 validation artifact intent:
|
|
4
4
|
|
|
5
5
|
1. Run Doctor (`--ci`) through the agent.
|
|
6
6
|
2. Fetch one guide via MCP resource (`animation-performance`).
|
|
7
|
-
3. Execute one CLI workflow (`mds continue` or `/
|
|
7
|
+
3. Execute one CLI workflow (`mds continue` or `/push-merge-loop`).
|
|
8
8
|
4. Confirm tools/resources are visible in the target client.
|
|
9
|
+
|
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
|
|
1
|
+
# Push-Merge Loop Example
|
|
2
2
|
|
|
3
|
-
Example iteration log for `/
|
|
3
|
+
Example iteration log for `/push-merge-loop`:
|
|
4
4
|
|
|
5
5
|
- Iteration 1:
|
|
6
6
|
- Failed: `lint` and one requested review change.
|
|
@@ -11,3 +11,4 @@ Example iteration log for `/ship-test-loop`:
|
|
|
11
11
|
- Fixes: update stale skill ID expectation.
|
|
12
12
|
- Result: all checks green.
|
|
13
13
|
- Merge: PR merged into `test`.
|
|
14
|
+
|
|
@@ -19,14 +19,14 @@ onboarding pass.
|
|
|
19
19
|
Uniwind repair for existing apps, Software Mansion core examples, Supabase or
|
|
20
20
|
local data guidance, MCP/Codex/Claude instructions, and CI/release safeguards.
|
|
21
21
|
6. Scaffold only selected pieces.
|
|
22
|
-
7. Add generated cleanup scripts such as `clear-expo-start` and `free-port
|
|
22
|
+
7. Add generated cleanup scripts such as `clear-expo-start` and `free-port`.
|
|
23
23
|
8. Install added dependencies, run `expo install --fix`, install known missing
|
|
24
24
|
Expo peers such as `expo-font` for `@expo/vector-icons`, then run Doctor.
|
|
25
25
|
|
|
26
26
|
## Agentic Onboarding (MCP)
|
|
27
27
|
|
|
28
28
|
The terminal `mds onboard` command writes the project memory files. The
|
|
29
|
-
agentic version is a conversation with Claude Code, Codex, or Cursor that
|
|
29
|
+
agentic version is a conversation with Copilot, Claude Code, Codex, or Cursor that
|
|
30
30
|
fills those files in collaboratively.
|
|
31
31
|
|
|
32
32
|
Install **once, globally** (user scope, default) so every workspace gets
|
|
@@ -42,16 +42,17 @@ mds mcp install --dry-run # preview merge before writing
|
|
|
42
42
|
Restart the host (or run `claude mcp reload`) and the MDS prompts are
|
|
43
43
|
available from any workspace.
|
|
44
44
|
|
|
45
|
-
Two prompts ship with the server:
|
|
46
|
-
|
|
47
|
-
- `create_expo_super_stack` — invoke from a **parent folder** (e.g.
|
|
48
|
-
`F:\ReactNativeApps`) when the app folder does not exist yet.
|
|
49
|
-
|
|
50
|
-
`
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
45
|
+
Two prompts and several callable MDS MCP tools ship with the server:
|
|
46
|
+
|
|
47
|
+
- `create_expo_super_stack` — invoke from a **parent folder** (e.g.
|
|
48
|
+
`F:\ReactNativeApps`) when the app folder does not exist yet. This is
|
|
49
|
+
now a thin orchestration prompt: the real guided intake happens
|
|
50
|
+
through `create_expo_super_stack_intake_step`, generation happens
|
|
51
|
+
through `create_expo_super_stack_generate`, and diagnostics come from
|
|
52
|
+
`mds_runtime_versions`.
|
|
53
|
+
- `onboard_new_expo_app` — invoke from **inside an existing Expo app
|
|
54
|
+
folder** (a freshly generated one or a year-old project). Runs the
|
|
55
|
+
intake → normalize → plan → scaffold flow.
|
|
55
56
|
|
|
56
57
|
After generation, the user-dev should open the generated app folder
|
|
57
58
|
directly in a new agent session and run `mds continue`. That fresh
|
|
@@ -68,7 +69,7 @@ delete the marker line.
|
|
|
68
69
|
error so the same blocker stops CI and editor surfaces until the user
|
|
69
70
|
fills the section or deletes the marker line.
|
|
70
71
|
|
|
71
|
-
### What's new in the agentic prompts
|
|
72
|
+
### What's new in the agentic prompts and tools
|
|
72
73
|
|
|
73
74
|
- **PHASE 0 file intake.** The agent offers to digest an existing
|
|
74
75
|
`project/info.md` and `project/style.md` if the user has them already.
|
|
@@ -81,16 +82,23 @@ fills the section or deletes the marker line.
|
|
|
81
82
|
with leanback config in `app.json`; Apple TV is a separate tvOS build
|
|
82
83
|
target via `react-native-tvos`. Selecting either records the intent
|
|
83
84
|
in project memory.
|
|
84
|
-
- **
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
- **
|
|
89
|
-
|
|
90
|
-
|
|
85
|
+
- **Shared CLI-backed intake contract.** The agentic CESS flow now uses
|
|
86
|
+
callable MCP tools backed by the shared `@mr.dj2u/cli` intake
|
|
87
|
+
contract. That keeps the questionnaire, defaults, dependency rules,
|
|
88
|
+
and flag mapping aligned with the published CLI behavior.
|
|
89
|
+
- **No silent defaults.** Guided intake must explicitly collect answers
|
|
90
|
+
or explicitly present visible defaults. If the CESS intake tools are
|
|
91
|
+
unavailable, the agent should stop and tell the user to refresh the
|
|
92
|
+
plugin or MCP install instead of inventing `--mds-yes` defaults.
|
|
93
|
+
- **Runtime version diagnostics.** `mds_runtime_versions` reports the
|
|
94
|
+
active MCP server version, CLI version, and the published
|
|
95
|
+
`create-expo-super-stack@latest` generation path in use.
|
|
96
|
+
- **Credits while waiting.** When generation kicks off, the agent
|
|
97
|
+
prints a recognition note for the upstream teams and individuals
|
|
98
|
+
whose work fills the MDS knowledge base.
|
|
91
99
|
- **Success message surfaced.** After a successful run, the agent
|
|
92
100
|
quotes the generator's `MDS onboarding complete` tail block back
|
|
93
|
-
verbatim so the Mr. DJ thank-you text appears in chat the same way
|
|
101
|
+
verbatim so the Mr. DJ personal thank-you text appears in chat the same way
|
|
94
102
|
it does in a terminal CLI run.
|
|
95
103
|
- **MDS Continue handoff.** The agent runs `mds continue` from the
|
|
96
104
|
generated app folder, then tells the user-dev to open that app folder
|
|
@@ -111,3 +119,37 @@ fills the section or deletes the marker line.
|
|
|
111
119
|
`project/guidelines.md`.
|
|
112
120
|
- Treat monorepo-aware scaffolding as a future step after the single-app MVP is
|
|
113
121
|
stable.
|
|
122
|
+
|
|
123
|
+
## VS Code & GitHub Copilot Integration
|
|
124
|
+
|
|
125
|
+
This guide is authored as canonical knowledge consumed by agent bundles; it is not the agent itself. To enable the generated Copilot/VS Code surface and the custom MDS agent in a workspace, regenerate the VS Code bundle and install the generated prompts/settings into the target repository or your user profile.
|
|
126
|
+
|
|
127
|
+
- Regenerate VS Code assets (from repository root):
|
|
128
|
+
|
|
129
|
+
```powershell
|
|
130
|
+
pnpm --filter @mr.dj2u/knowledge build:vscode
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
- Copy the generated workspace assets into your project (PowerShell):
|
|
134
|
+
|
|
135
|
+
```powershell
|
|
136
|
+
Copy-Item -Path .\plugins\vscode-copilot\.github\* -Destination . -Recurse -Force
|
|
137
|
+
Copy-Item -Path .\plugins\vscode-copilot\.vscode\* -Destination .\.vscode -Recurse -Force
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
- Then restart VS Code. Ensure the `GitHub Copilot Chat` extension is installed and enabled. The generated `.vscode/settings.json` enables agent skill locations and prompt file lookup under `.github/prompts`.
|
|
141
|
+
|
|
142
|
+
- If you prefer user-scope installs, copy the `user/.copilot` content into your user profile per the extension docs, or run `mds agent install --client codex --scope user` (if available) to automate the merge.
|
|
143
|
+
|
|
144
|
+
## Install Path & What This MD Is For
|
|
145
|
+
|
|
146
|
+
- This markdown is a human- and agent-facing guide. It documents the onboarding flow and explains what the agent prompts do. It is used as input to the `packages/knowledge` build which generates plugin/agent bundles for Codex, Claude Code, and VS Code Copilot.
|
|
147
|
+
- The agent itself is not this file — it is a runtime that loads generated prompts/skills from the plugin bundles or the MCP server. To activate the agent surfaces you must either:
|
|
148
|
+
- Install the MCP prompts via `mds mcp install --client <client>` (user or project scope), or
|
|
149
|
+
- Copy the generated plugin files from `plugins/vscode-copilot` / `plugins/codex` / `plugins/claude-code` into the target workspace or user profile and restart the corresponding client.
|
|
150
|
+
- If a host keeps using stale prompt or plugin behavior after republish,
|
|
151
|
+
refresh the local plugin cache, reinstall the MDS MCP server, and run
|
|
152
|
+
`mds_runtime_versions` from the host surface to confirm which version
|
|
153
|
+
is actually active.
|
|
154
|
+
|
|
155
|
+
If you want, I can: regenerate the VS Code bundle now, copy the assets into the current workspace, and verify Copilot sees the prompts. Say "Do it" and I'll run the build and copy steps for you.
|
|
@@ -51,8 +51,8 @@ Configuration patterns establish consistent strategies for managing app configur
|
|
|
51
51
|
|
|
52
52
|
"platforms": ["ios", "android", "web"],
|
|
53
53
|
|
|
54
|
-
"sdkVersion": "
|
|
55
|
-
"runtimeVersion": "
|
|
54
|
+
"sdkVersion": "56.0.0",
|
|
55
|
+
"runtimeVersion": "56.0.0",
|
|
56
56
|
|
|
57
57
|
"web": {
|
|
58
58
|
"output": "static",
|
|
@@ -178,7 +178,7 @@ export default ({ config }) => {
|
|
|
178
178
|
"dependencies": {
|
|
179
179
|
"react": "^19.0.0",
|
|
180
180
|
"react-native": "^0.83.0",
|
|
181
|
-
"expo": "^
|
|
181
|
+
"expo": "^56.0.0",
|
|
182
182
|
"expo-router": "^3.0.0",
|
|
183
183
|
"zustand": "^4.4.0",
|
|
184
184
|
"drizzle-orm": "^0.30.0",
|
|
@@ -456,4 +456,4 @@ export function useConfig() {
|
|
|
456
456
|
---
|
|
457
457
|
|
|
458
458
|
*Pattern extracted from production repositories: DJsPortfolio, time2pay, not-hot-dog*
|
|
459
|
-
*Examples: app.json, app.config.js, metro.config.js, babel.config.js, tsconfig.json*
|
|
459
|
+
*Examples: app.json, app.config.js, metro.config.js, babel.config.js, tsconfig.json*
|
|
@@ -2,19 +2,19 @@
|
|
|
2
2
|
|
|
3
3
|
## Description
|
|
4
4
|
|
|
5
|
-
Documentation organization establishes consistent structure for project metadata, guides, and architectural decisions. This pattern uses structured markdown files in dedicated `project/` directories alongside inline code documentation to keep knowledge accessible and maintainable.
|
|
6
|
-
|
|
7
|
-
## MDS Project Memory Update
|
|
8
|
-
|
|
9
|
-
New MDS onboarding uses four project memory files:
|
|
10
|
-
|
|
11
|
-
- `project/info.md` for product intent and context.
|
|
12
|
-
- `project/todo.md` for roadmap and next work.
|
|
13
|
-
- `project/style.md` for visual/design direction only.
|
|
14
|
-
- `project/guidelines.md` for technical rules, agent behavior, workflow, and architecture.
|
|
15
|
-
|
|
16
|
-
Generated agent instructions should treat the `project/` folder as the source of
|
|
17
|
-
truth and should not make changes that conflict with those files.
|
|
5
|
+
Documentation organization establishes consistent structure for project metadata, guides, and architectural decisions. This pattern uses structured markdown files in dedicated `project/` directories alongside inline code documentation to keep knowledge accessible and maintainable.
|
|
6
|
+
|
|
7
|
+
## MDS Project Memory Update
|
|
8
|
+
|
|
9
|
+
New MDS onboarding uses four project memory files:
|
|
10
|
+
|
|
11
|
+
- `project/info.md` for product intent and context.
|
|
12
|
+
- `project/todo.md` for roadmap and next work.
|
|
13
|
+
- `project/style.md` for visual/design direction only.
|
|
14
|
+
- `project/guidelines.md` for technical rules, agent behavior, workflow, and architecture.
|
|
15
|
+
|
|
16
|
+
Generated agent instructions should treat the `project/` folder as the source of
|
|
17
|
+
truth and should not make changes that conflict with those files.
|
|
18
18
|
|
|
19
19
|
## When to Use
|
|
20
20
|
|
|
@@ -66,7 +66,7 @@ truth and should not make changes that conflict with those files.
|
|
|
66
66
|
Personal portfolio and project showcase for David J Grimsley.
|
|
67
67
|
|
|
68
68
|
## Core Stack
|
|
69
|
-
- **Framework**: Expo SDK
|
|
69
|
+
- **Framework**: Expo SDK 56 + React Native 0.85
|
|
70
70
|
- **Routing**: Expo Router (file-based)
|
|
71
71
|
- **Styling**: Uniwind v1.2.6 + Tailwind v4
|
|
72
72
|
- **State**: Zustand (atomic stores)
|
|
@@ -503,4 +503,4 @@ pnpm typecheck # Check types
|
|
|
503
503
|
---
|
|
504
504
|
|
|
505
505
|
*Pattern extracted from production repositories: DJsPortfolio, not-hot-dog*
|
|
506
|
-
*Examples: project/info.md, project/style.md, copilot-instructions.md*
|
|
506
|
+
*Examples: project/info.md, project/style.md, copilot-instructions.md*
|
|
@@ -179,7 +179,7 @@ ignore:
|
|
|
179
179
|
|
|
180
180
|
"react": "^19.0.0",
|
|
181
181
|
"react-native": "^0.83.0",
|
|
182
|
-
"expo": "^
|
|
182
|
+
"expo": "^56.0.0",
|
|
183
183
|
"expo-router": "^3.0.0",
|
|
184
184
|
"zustand": "^4.4.0"
|
|
185
185
|
},
|
|
@@ -496,5 +496,5 @@ core-monorepo/
|
|
|
496
496
|
|
|
497
497
|
---
|
|
498
498
|
|
|
499
|
-
*Pattern extracted from production monorepos: core-monorepo (3 apps, 6 packages),
|
|
500
|
-
*Examples: pnpm-workspace.yaml, turbo.json, tsconfig.base.json, workspace:* references*
|
|
499
|
+
*Pattern extracted from production monorepos: core-monorepo (3 apps, 6 packages), Mr. DJ's Dev Suite*
|
|
500
|
+
*Examples: pnpm-workspace.yaml, turbo.json, tsconfig.base.json, workspace:* references*
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# /continue-development
|
|
2
2
|
|
|
3
3
|
Resume work on an onboarded project by following MDS phase order from `project/todo.md`.
|
|
4
4
|
|
|
@@ -8,18 +8,26 @@ Resume work on an onboarded project by following MDS phase order from `project/t
|
|
|
8
8
|
|
|
9
9
|
## MCP-First Workflow
|
|
10
10
|
|
|
11
|
-
1. Confirm the `
|
|
11
|
+
1. Confirm the `mr-djs-dev-suite` MCP server is available.
|
|
12
12
|
2. Call `continue_project` first to get the active-phase brief.
|
|
13
13
|
3. Pull `get_skill` for `continue-development` to enforce phase-first sequencing.
|
|
14
14
|
4. If blockers appear, use `doctor_scan_project` and `doctor_explain_result` for targeted remediation before feature work.
|
|
15
15
|
|
|
16
|
+
## MDS Routing Guardrails
|
|
17
|
+
|
|
18
|
+
- Treat a request to continue development with MDS as a request for the MDS MCP tool and phase rules first.
|
|
19
|
+
- Do not jump directly into app edits until `continue_project` or the CLI fallback has identified the active phase and blockers.
|
|
20
|
+
- Never invoke `@mrdj/cli`; that package name is wrong. The published CLI package is `@mr.dj2u/cli` and its executable is `mds`.
|
|
21
|
+
|
|
16
22
|
## CLI / Manual Fallback
|
|
17
23
|
|
|
18
24
|
1. If MCP is not configured, install it manually:
|
|
19
|
-
- `mds mcp install --client
|
|
25
|
+
- `mds mcp install --client <client> --scope project`
|
|
20
26
|
2. Direct CLI flow:
|
|
21
27
|
- `mds continue <projectPath>`
|
|
22
28
|
- `mds doctor <projectPath>` when blockers are unclear.
|
|
29
|
+
3. If `mds` is not on PATH, invoke the published CLI by binary name:
|
|
30
|
+
- `npx -y -p @mr.dj2u/cli@latest mds continue <projectPath>`
|
|
23
31
|
|
|
24
32
|
## Verification And Output
|
|
25
33
|
|
|
@@ -1,29 +1,31 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
Create a new Expo app with the MDS Super Stack flow,
|
|
4
|
-
|
|
5
|
-
## Arguments
|
|
6
|
-
|
|
7
|
-
- `parentDir`: folder where the new app directory should be created.
|
|
8
|
-
- `appName`: app folder name.
|
|
9
|
-
|
|
10
|
-
## MCP
|
|
11
|
-
|
|
12
|
-
1. Confirm the `
|
|
13
|
-
2.
|
|
14
|
-
3.
|
|
15
|
-
4.
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
1
|
+
# /create-expo-super-stack
|
|
2
|
+
|
|
3
|
+
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.
|
|
4
|
+
|
|
5
|
+
## Arguments
|
|
6
|
+
|
|
7
|
+
- `parentDir`: folder where the new app directory should be created.
|
|
8
|
+
- `appName`: app folder name.
|
|
9
|
+
|
|
10
|
+
## Required MDS MCP Tool Flow
|
|
11
|
+
|
|
12
|
+
1. Confirm the `mr-djs-dev-suite` MCP server is available.
|
|
13
|
+
2. Drive intake with `create_expo_super_stack_intake_step`.
|
|
14
|
+
3. Ask exactly one question per turn.
|
|
15
|
+
4. Always show the returned default and options.
|
|
16
|
+
5. Never invent or silently accept defaults on the user's behalf.
|
|
17
|
+
6. When the intake tool returns `confirm`, summarize the returned `summaryLines` and ask the user to confirm.
|
|
18
|
+
7. After explicit confirmation, set `answers.confirmed=true`, call the intake tool again, and proceed only when it returns `ready`.
|
|
19
|
+
8. Then call `create_expo_super_stack_generate` with `confirmed: true`.
|
|
20
|
+
|
|
21
|
+
## Failure Behavior
|
|
22
|
+
|
|
23
|
+
1. If the guided intake or generate tools are unavailable, stop.
|
|
24
|
+
2. Call `mds_runtime_versions` to diagnose stale plugin or MCP installs.
|
|
25
|
+
3. Tell the user to refresh or reinstall the MDS plugin/MCP server.
|
|
26
|
+
4. Do not fall back to `--mds-yes` or direct CLI shortcuts unless the user explicitly asked for a fast non-interactive run.
|
|
27
|
+
|
|
28
|
+
## Verification And Output
|
|
29
|
+
|
|
30
|
+
- Confirm generated app has `project/info.md`, `project/todo.md`, `project/style.md`, and `project/guidelines.md`.
|
|
31
|
+
- Output: generated app path, onboarding status, and the handoff to open a fresh agent session inside the new app folder and run `mds continue`.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# /fix-seo
|
|
2
2
|
|
|
3
3
|
Apply SEO metadata fixes for Expo web routes with MCP guidance and post-fix verification.
|
|
4
4
|
|
|
@@ -9,7 +9,7 @@ Apply SEO metadata fixes for Expo web routes with MCP guidance and post-fix veri
|
|
|
9
9
|
|
|
10
10
|
## MCP-First Workflow
|
|
11
11
|
|
|
12
|
-
1. Confirm the `
|
|
12
|
+
1. Confirm the `mr-djs-dev-suite` MCP server is available.
|
|
13
13
|
2. Pull `get_skill` for `seo-metadata`.
|
|
14
14
|
3. Optionally run `doctor_scan_file` for focused route files, then `doctor_scan_project` for full checks.
|
|
15
15
|
4. Use `knowledge_list_resources` (`kind: "rule"`) to ensure canonical/indexing strategy is complete.
|
|
@@ -18,7 +18,7 @@ Apply SEO metadata fixes for Expo web routes with MCP guidance and post-fix veri
|
|
|
18
18
|
## CLI / Manual Fallback
|
|
19
19
|
|
|
20
20
|
1. If MCP is not configured, install it manually:
|
|
21
|
-
- `mds mcp install --client
|
|
21
|
+
- `mds mcp install --client <client> --scope project`
|
|
22
22
|
2. Direct CLI checks:
|
|
23
23
|
- `mds doctor <projectPath> --ci`
|
|
24
24
|
- Run project-specific web build/preview commands to verify metadata output.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# /prepare-deploy
|
|
2
2
|
|
|
3
3
|
Prepare an Expo project for release using deployment-focused skills plus Doctor parity checks.
|
|
4
4
|
|
|
@@ -9,7 +9,7 @@ Prepare an Expo project for release using deployment-focused skills plus Doctor
|
|
|
9
9
|
|
|
10
10
|
## MCP-First Workflow
|
|
11
11
|
|
|
12
|
-
1. Confirm the `
|
|
12
|
+
1. Confirm the `mr-djs-dev-suite` MCP server is available.
|
|
13
13
|
2. Run `doctor_scan_project` in `ci` mode for release parity.
|
|
14
14
|
3. Pull `get_skill` for `deployment`; if web is involved also pull `seo-metadata`.
|
|
15
15
|
4. Use `knowledge_list_resources` (`kind: "rule"`) to confirm env hygiene, SSR safety, and metadata requirements.
|
|
@@ -18,7 +18,7 @@ Prepare an Expo project for release using deployment-focused skills plus Doctor
|
|
|
18
18
|
## CLI / Manual Fallback
|
|
19
19
|
|
|
20
20
|
1. If MCP is not configured, install it manually:
|
|
21
|
-
- `mds mcp install --client
|
|
21
|
+
- `mds mcp install --client <client> --scope project`
|
|
22
22
|
2. Direct CLI path:
|
|
23
23
|
- `mds doctor <projectPath> --ci`
|
|
24
24
|
- Run project scripts: `lint`, `type-check`, `test`, and production build/profile scripts.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# /project-research-plan
|
|
2
2
|
|
|
3
3
|
Turn rough product notes/research into actionable MDS project memory and next-phase plan.
|
|
4
4
|
|
|
@@ -9,7 +9,7 @@ Turn rough product notes/research into actionable MDS project memory and next-ph
|
|
|
9
9
|
|
|
10
10
|
## MCP-First Workflow
|
|
11
11
|
|
|
12
|
-
1. Confirm the `
|
|
12
|
+
1. Confirm the `mr-djs-dev-suite` MCP server is available.
|
|
13
13
|
2. Pull `get_skill` for `research-plan-intake` (and `project-onboarding` when onboarding context is mixed in).
|
|
14
14
|
3. Call `knowledge_list_resources` for `guide` and `reference` resources as needed for structure and validation.
|
|
15
15
|
4. Normalize clear context directly; ask focused follow-up only where ambiguity changes implementation direction.
|
|
@@ -18,7 +18,7 @@ Turn rough product notes/research into actionable MDS project memory and next-ph
|
|
|
18
18
|
## CLI / Manual Fallback
|
|
19
19
|
|
|
20
20
|
1. If MCP is not configured, install it manually:
|
|
21
|
-
- `mds mcp install --client
|
|
21
|
+
- `mds mcp install --client <client> --scope project`
|
|
22
22
|
2. Direct CLI fallback:
|
|
23
23
|
- Use `mds onboard <projectPath>` for structured intake when memory files are missing.
|
|
24
24
|
- Use `mds continue <projectPath>` after memory normalization to select the next task.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# /push-merge-loop
|
|
2
2
|
|
|
3
3
|
Execute the short PR iteration loop for the test branch with strict quality gates.
|
|
4
4
|
|
|
@@ -22,3 +22,4 @@ Push intentional changes with a meaningful commit message, open/update a PR to `
|
|
|
22
22
|
- Do not skip Doctor between fix cycles.
|
|
23
23
|
- Keep a concise changelog per iteration: what failed, what was changed, what passed.
|
|
24
24
|
- If still failing after 5 cycles, stop and summarize remaining blockers with concrete next actions.
|
|
25
|
+
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# /review-expo-project
|
|
2
2
|
|
|
3
3
|
Review an Expo project with MCP-first diagnostics and skill-guided remediation.
|
|
4
4
|
|
|
@@ -9,7 +9,7 @@ Review an Expo project with MCP-first diagnostics and skill-guided remediation.
|
|
|
9
9
|
|
|
10
10
|
## MCP-First Workflow
|
|
11
11
|
|
|
12
|
-
1. Confirm the `
|
|
12
|
+
1. Confirm the `mr-djs-dev-suite` MCP server is available.
|
|
13
13
|
2. Call `continue_project` to summarize current project state and blockers.
|
|
14
14
|
3. Call `doctor_scan_project` with `projectPath` and `mode`.
|
|
15
15
|
4. For each warning/error, call `doctor_explain_result`, then pull targeted guidance with `get_skill` (for example: `project-onboarding`, `debugging`, `deployment`).
|
|
@@ -18,7 +18,7 @@ Review an Expo project with MCP-first diagnostics and skill-guided remediation.
|
|
|
18
18
|
## CLI / Manual Fallback
|
|
19
19
|
|
|
20
20
|
1. If MCP is not configured, install it manually:
|
|
21
|
-
- `mds mcp install --client
|
|
21
|
+
- `mds mcp install --client <client> --scope project`
|
|
22
22
|
2. If MCP still cannot run, use direct CLI flows:
|
|
23
23
|
- `mds continue <projectPath>`
|
|
24
24
|
- `mds doctor <projectPath> --ci`
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
# /run-doctor
|
|
2
2
|
|
|
3
3
|
Run MDS Doctor as the primary health check for an Expo project.
|
|
4
4
|
|
|
@@ -10,19 +10,27 @@ Run MDS Doctor as the primary health check for an Expo project.
|
|
|
10
10
|
|
|
11
11
|
## MCP-First Workflow
|
|
12
12
|
|
|
13
|
-
1. Confirm the `
|
|
13
|
+
1. Confirm the `mr-djs-dev-suite` MCP server is available.
|
|
14
14
|
2. Call `doctor_scan_project` with selected arguments.
|
|
15
15
|
3. For each non-pass result, call `doctor_explain_result`.
|
|
16
16
|
4. Pull targeted implementation guidance with `get_skill` (typically `deployment`, `debugging`, or `dev-server-management`).
|
|
17
17
|
|
|
18
|
+
## MDS Routing Guardrails
|
|
19
|
+
|
|
20
|
+
- 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.
|
|
21
|
+
- 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.
|
|
22
|
+
- Never invoke `@mrdj/cli`; that package name is wrong. The published CLI package is `@mr.dj2u/cli` and its executable is `mds`.
|
|
23
|
+
|
|
18
24
|
## CLI / Manual Fallback
|
|
19
25
|
|
|
20
26
|
1. If MCP is not configured, install it manually:
|
|
21
|
-
- `mds mcp install --client
|
|
27
|
+
- `mds mcp install --client <client> --scope project`
|
|
22
28
|
2. Direct CLI alternatives:
|
|
23
29
|
- `mds doctor <projectPath>`
|
|
24
30
|
- `mds doctor <projectPath> --ci`
|
|
25
31
|
- `mds doctor <projectPath> --json`
|
|
32
|
+
3. If `mds` is not on PATH, invoke the published CLI by binary name:
|
|
33
|
+
- `npx -y -p @mr.dj2u/cli@latest mds doctor <projectPath> --ci`
|
|
26
34
|
|
|
27
35
|
## Verification And Output
|
|
28
36
|
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
# /wrap-up
|
|
2
|
+
|
|
3
|
+
Run the post-testing release wrap-up flow: final local checks, git inclusion confirmation, PR loop, and merge handling.
|
|
4
|
+
|
|
5
|
+
## Goal
|
|
6
|
+
|
|
7
|
+
When the developer says testing is complete, finish the handoff safely by:
|
|
8
|
+
|
|
9
|
+
1. Marking completed todo items.
|
|
10
|
+
2. Running `mds doctor --ci`.
|
|
11
|
+
3. Reviewing `git status` and confirming intentionally excluded files.
|
|
12
|
+
4. Running the publish/PR/check loop.
|
|
13
|
+
5. Handling merge according to policy defaults and repo overrides.
|
|
14
|
+
|
|
15
|
+
## Required Flow Order
|
|
16
|
+
|
|
17
|
+
1. Update `project/todo.md` only for tasks clearly completed in this session.
|
|
18
|
+
2. Run `mds doctor --ci` before any git mutation.
|
|
19
|
+
3. Review `git status --short` and list changed files.
|
|
20
|
+
4. Confirm any intentionally omitted files with the developer before staging.
|
|
21
|
+
5. Publish through GitHub flow (branch push + PR).
|
|
22
|
+
6. Poll checks and unresolved feedback.
|
|
23
|
+
7. Fix failures locally, rerun Doctor, push updates, and poll again.
|
|
24
|
+
8. Repeat up to 5 cycles total.
|
|
25
|
+
|
|
26
|
+
## GitHub Skill Routing
|
|
27
|
+
|
|
28
|
+
Use GitHub workflows in this order when available:
|
|
29
|
+
|
|
30
|
+
1. `github` for repo/PR context and routing.
|
|
31
|
+
2. `yeet` for commit/push/open-or-update PR flow.
|
|
32
|
+
3. `gh-fix-ci` for failed checks/log inspection and CI-driven fix loops.
|
|
33
|
+
4. `gh-address-comments` when unresolved review threads are blocking merge.
|
|
34
|
+
|
|
35
|
+
## Merge Policy
|
|
36
|
+
|
|
37
|
+
Evaluate policy in this order:
|
|
38
|
+
|
|
39
|
+
1. Explicit user instruction in the current session.
|
|
40
|
+
2. Optional repo config at `project/release-policy.json`.
|
|
41
|
+
3. Defaults if config is absent.
|
|
42
|
+
|
|
43
|
+
Supported repo config shape:
|
|
44
|
+
|
|
45
|
+
```json
|
|
46
|
+
{
|
|
47
|
+
"wrapUp": {
|
|
48
|
+
"autoMergeTest": true,
|
|
49
|
+
"autoMergeMain": false
|
|
50
|
+
}
|
|
51
|
+
}
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
Default behavior:
|
|
55
|
+
|
|
56
|
+
- Auto-merge to `test`: enabled.
|
|
57
|
+
- Per-repo override: allowed.
|
|
58
|
+
- Auto-merge to `main`: never allowed.
|
|
59
|
+
|
|
60
|
+
If the workflow targets `main` directly (no `test` branch flow), stop before merge and tell the developer to merge manually.
|
|
61
|
+
|
|
62
|
+
## Guardrails
|
|
63
|
+
|
|
64
|
+
- Never auto-merge to `main`.
|
|
65
|
+
- Do not skip `mds doctor --ci` between fix cycles.
|
|
66
|
+
- Do not assume omitted files are intentional; confirm them.
|
|
67
|
+
- If checks or blocking threads still fail after 5 cycles, stop and request human help with a concise blocker summary.
|
|
@@ -1,29 +1,29 @@
|
|
|
1
|
-
# create-expo-stack Uniwind Exploration
|
|
2
|
-
|
|
3
|
-
Source: https://github.com/roninoss/create-expo-stack
|
|
4
|
-
|
|
5
|
-
## Findings
|
|
6
|
-
|
|
7
|
-
- The project describes itself as an interactive CLI for `rn-new`.
|
|
8
|
-
- It already supports multiple styling choices, including NativeWind,
|
|
9
|
-
Unistyles, StyleSheets, and Tamagui.
|
|
10
|
-
- The README describes a per-file template model: base files live in a base
|
|
11
|
-
template folder, while optional package features live in package template
|
|
12
|
-
folders and use EJS to patch shared files.
|
|
13
|
-
|
|
14
|
-
## Phase 1 Decision
|
|
15
|
-
|
|
16
|
-
A friendly upstream Uniwind contribution should stay small:
|
|
17
|
-
|
|
18
|
-
- add Uniwind as another styling option,
|
|
19
|
-
- follow the existing package-slice template convention,
|
|
20
|
-
- include `web` in Expo Router generated `app.json` platforms when web config
|
|
21
|
-
and dependencies are generated,
|
|
22
|
-
- add focused Software Mansion core package options where they are not already
|
|
23
|
-
covered,
|
|
24
|
-
- avoid MDS project memory files, MCP config, agent prompts, or richer
|
|
25
|
-
boilerplate,
|
|
26
|
-
- keep the deeper post-create setup in `mds onboard` and
|
|
27
|
-
`create-expo-super-stack`.
|
|
28
|
-
|
|
29
|
-
No local Phase 1 code should depend on the upstream fork or PR existing.
|
|
1
|
+
# create-expo-stack Uniwind Exploration
|
|
2
|
+
|
|
3
|
+
Source: https://github.com/roninoss/create-expo-stack
|
|
4
|
+
|
|
5
|
+
## Findings
|
|
6
|
+
|
|
7
|
+
- The project describes itself as an interactive CLI for `rn-new`.
|
|
8
|
+
- It already supports multiple styling choices, including NativeWind,
|
|
9
|
+
Unistyles, StyleSheets, and Tamagui.
|
|
10
|
+
- The README describes a per-file template model: base files live in a base
|
|
11
|
+
template folder, while optional package features live in package template
|
|
12
|
+
folders and use EJS to patch shared files.
|
|
13
|
+
|
|
14
|
+
## Phase 1 Decision
|
|
15
|
+
|
|
16
|
+
A friendly upstream Uniwind contribution should stay small:
|
|
17
|
+
|
|
18
|
+
- add Uniwind as another styling option,
|
|
19
|
+
- follow the existing package-slice template convention,
|
|
20
|
+
- include `web` in Expo Router generated `app.json` platforms when web config
|
|
21
|
+
and dependencies are generated,
|
|
22
|
+
- add focused Software Mansion core package options where they are not already
|
|
23
|
+
covered,
|
|
24
|
+
- avoid MDS project memory files, MCP config, agent prompts, or richer
|
|
25
|
+
boilerplate,
|
|
26
|
+
- keep the deeper post-create setup in `mds onboard` and
|
|
27
|
+
`create-expo-super-stack`.
|
|
28
|
+
|
|
29
|
+
No local Phase 1 code should depend on the upstream fork or PR existing.
|