@mr.dj2u/knowledge 0.1.7 → 0.1.9

package/dist/content/skills/deployment.md

@@ -1,32 +1,32 @@
-# Skill: Deployment Readiness
-
-Use before merging or releasing an Expo project to shared environments.
-
-## Main rule
-
-Treat deployment as a repeatable checklist: pass local quality gates, verify runtime configuration, and document rollback expectations before ship.
-
-## Checks
-
-- Run lint, type-check, tests, Expo Doctor, and production build/profile checks when scripts exist.
-- Verify env vars are documented and separated by client/server exposure level.
-- Confirm output mode and hosting assumptions match the selected platform strategy.
-- Confirm metadata/indexing basics are defined for web exports.
-- Record release and rollback notes for the current change batch.
-
-## Preferred structure
-
-- Keep release checks in scripts that CI and agents can run consistently.
-- Gate merge/publish flows on the same Doctor and package validation criteria.
-- Keep deployment conventions in `project/guidelines.md` and release tasks in `project/todo.md`.
-
-## Example fix
-
-- Problem: Release pipeline runs tests but skips Expo Doctor and build profile checks.
-- Fix: Add missing scripts, wire them into pre-merge checks, and document the required sequence in project memory.
-
-## Agent behavior
-
-- Run project-defined checks first; do not invent alternate release criteria.
-- Delegate framework deployment primitives to official Expo guidance, then apply MDS workflow rules for docs, Doctor parity, and rollback readiness.
-
+# Skill: Deployment Readiness
+
+Use before merging or releasing an Expo project to shared environments.
+
+## Main rule
+
+Treat deployment as a repeatable checklist: pass local quality gates, verify runtime configuration, and document rollback expectations before ship.
+
+## Checks
+
+- Run lint, type-check, tests, Expo Doctor, and production build/profile checks when scripts exist.
+- Verify env vars are documented and separated by client/server exposure level.
+- Confirm output mode and hosting assumptions match the selected platform strategy.
+- Confirm metadata/indexing basics are defined for web exports.
+- Record release and rollback notes for the current change batch.
+
+## Preferred structure
+
+- Keep release checks in scripts that CI and agents can run consistently.
+- Gate merge/publish flows on the same Doctor and package validation criteria.
+- Keep deployment conventions in `project/guidelines.md` and release tasks in `project/todo.md`.
+
+## Example fix
+
+- Problem: Release pipeline runs tests but skips Expo Doctor and build profile checks.
+- Fix: Add missing scripts, wire them into pre-merge checks, and document the required sequence in project memory.
+
+## Agent behavior
+
+- Run project-defined checks first; do not invent alternate release criteria.
+- Delegate framework deployment primitives to official Expo guidance, then apply MDS workflow rules for docs, Doctor parity, and rollback readiness.
+

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

@@ -1,32 +1,32 @@
-# Skill: Dev Server Management
-
-Use when Expo or Metro local development servers fail to boot cleanly, hang, or bind to conflicting ports.
-
-## Main rule
-
-Use a deterministic reset path first; do not work around unstable server state with ad-hoc port fallbacks.
-
-## Checks
-
-- Run `mds clear-expo-start`  before manual troubleshooting.
-- If a conflict remains, run `mds free-port <port...>` for blocked ports.
-- Confirm Expo/Metro caches are cleared before retrying startup.
-- Treat fallback to port `8082` as an unresolved state that requires full reset.
-- Confirm the same recovery scripts are available to teammates and automation.
-
-## Preferred structure
-
-- Keep project scripts for clear-expo-start and targeted port cleanup.
-- Standardize a single restart path in project memory (`project/guidelines.md`).
-- Use explicit “fresh” commands when booting local or production-like flows.
-
-## Example fix
-
-- Problem: `expo start` repeatedly falls back to `8082` after a partial crash.
-- Fix: Run `mds clear-expo-start`, free remaining blocked ports, clear cache, and restart via the project's clear-expo-start script.
-
-## Agent behavior
-
-- Prefer established MDS cleanup commands over custom shell sequences.
-- Avoid introducing alternate fallback port workflows that hide root-cause server state issues.
-- Delegate Expo or Metro mechanics to official Expo guidance, then apply MDS reset commands, script consistency, and onboarding defaults.
+# Skill: Dev Server Management
+
+Use when Expo or Metro local development servers fail to boot cleanly, hang, or bind to conflicting ports.
+
+## Main rule
+
+Use a deterministic reset path first; do not work around unstable server state with ad-hoc port fallbacks.
+
+## Checks
+
+- Run `mds clear-expo-start`  before manual troubleshooting.
+- If a conflict remains, run `mds free-port <port...>` for blocked ports.
+- Confirm Expo/Metro caches are cleared before retrying startup.
+- Treat fallback to port `8082` as an unresolved state that requires full reset.
+- Confirm the same recovery scripts are available to teammates and automation.
+
+## Preferred structure
+
+- Keep project scripts for clear-expo-start and targeted port cleanup.
+- Standardize a single restart path in project memory (`project/guidelines.md`).
+- Use explicit “fresh” commands when booting local or production-like flows.
+
+## Example fix
+
+- Problem: `expo start` repeatedly falls back to `8082` after a partial crash.
+- Fix: Run `mds clear-expo-start`, free remaining blocked ports, clear cache, and restart via the project's clear-expo-start script.
+
+## Agent behavior
+
+- Prefer established MDS cleanup commands over custom shell sequences.
+- Avoid introducing alternate fallback port workflows that hide root-cause server state issues.
+- Delegate Expo or Metro mechanics to official Expo guidance, then apply MDS reset commands, script consistency, and onboarding defaults.

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

@@ -1,32 +1,32 @@
-# Skill: Environment Variables
-
-Use when adding, reviewing, or debugging app configuration and secrets handling.
-
-## Main rule
-
-Keep a hard boundary between public client config and private server secrets; anything sensitive must never cross into `EXPO_PUBLIC_*` variables.
-
-## Checks
-
-- Confirm secrets (service-role keys, private tokens, payment secrets, passwords) are server-only.
-- Confirm `EXPO_PUBLIC_*` values are safe to expose in client bundles.
-- Validate required env keys exist for each runtime mode used by the project.
-- Ensure Supabase anon key usage is scoped to client-safe flows and service-role usage is server-only.
-- Verify env naming/docs are consistent across `.env` files, scripts, and project memory.
-
-## Preferred structure
-
-- Keep env access centralized through small typed config helpers.
-- Separate client-safe config and server-only config modules.
-- Document required keys and local setup in project memory and onboarding outputs.
-
-## Example fix
-
-- Problem: A route imports `EXPO_PUBLIC_SUPABASE_SERVICE_ROLE_KEY` from client config.
-- Fix: Move service-role key to server-only env access, switch client flow to anon key, and update docs/checks.
-
-## Agent behavior
-
-- Prioritize removing exposure risk before refactoring for style.
-- Delegate framework/env-loading primitives to official Expo guidance, then enforce MDS-specific security boundaries and Doctor alignment.
-
+# Skill: Environment Variables
+
+Use when adding, reviewing, or debugging app configuration and secrets handling.
+
+## Main rule
+
+Keep a hard boundary between public client config and private server secrets; anything sensitive must never cross into `EXPO_PUBLIC_*` variables.
+
+## Checks
+
+- Confirm secrets (service-role keys, private tokens, payment secrets, passwords) are server-only.
+- Confirm `EXPO_PUBLIC_*` values are safe to expose in client bundles.
+- Validate required env keys exist for each runtime mode used by the project.
+- Ensure Supabase anon key usage is scoped to client-safe flows and service-role usage is server-only.
+- Verify env naming/docs are consistent across `.env` files, scripts, and project memory.
+
+## Preferred structure
+
+- Keep env access centralized through small typed config helpers.
+- Separate client-safe config and server-only config modules.
+- Document required keys and local setup in project memory and onboarding outputs.
+
+## Example fix
+
+- Problem: A route imports `EXPO_PUBLIC_SUPABASE_SERVICE_ROLE_KEY` from client config.
+- Fix: Move service-role key to server-only env access, switch client flow to anon key, and update docs/checks.
+
+## Agent behavior
+
+- Prioritize removing exposure risk before refactoring for style.
+- Delegate framework/env-loading primitives to official Expo guidance, then enforce MDS-specific security boundaries and Doctor alignment.
+

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

@@ -1,33 +1,34 @@
-# 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.
-
+# 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.
+- Doctor flags confusing groups, missing layouts, string-assembled hrefs, and mixed route concerns via the `router safety` check (`mds explain "router safety"`).
+
+## Preferred structure
+
+- Keep `app/` files focused on params, navigation, and screen composition.
+- Place business workflows in `src/features`.
+- Place side effects/integrations in `src/services` or `src/data`.
+- Keep reusable UI in `src/components` and cross-cutting helpers in hooks/utilities.
+
+## Example fix
+
+- Problem: A route file performs data fetching, mutation, and form business rules inline.
+- Fix: Move fetch/mutation logic to service modules, move workflow rules to a feature module, and keep the route as a thin screen wrapper.
+
+## Agent behavior
+
+- Prefer small, incremental extractions over broad rewrites.
+- Delegate framework routing primitives to official Expo Router guidance, then apply MDS rules for maintainable app-folder boundaries and Doctor-compatible architecture.
+

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

@@ -1,32 +1,32 @@
-# Skill: Expo SSR Safety
-
-Use when preparing or debugging Expo Router web/server output paths.
-
-## Main rule
-
-Assume server runtime first: guard browser-only APIs, isolate native-only code, and keep shared modules safe in both client and server contexts.
-
-## Checks
-
-- Guard `window`, `document`, `navigator`, `localStorage`, and `sessionStorage` access.
-- Confirm client-only packages are not imported by server/API execution paths.
-- Confirm storage/session access happens in client-safe lifecycle points.
-- Verify API routes and server modules do not rely on browser globals.
-- Validate dynamic imports or adapters for platform-specific behavior.
-
-## Preferred structure
-
-- Use small environment-check helpers for browser-global access.
-- Split client-only logic behind platform/runtime-specific modules.
-- Keep server-safe defaults and explicit fallbacks in shared utilities.
-
-## Example fix
-
-- Problem: Shared auth helper reads `localStorage` at module load and crashes SSR.
-- Fix: Move storage access into guarded runtime functions and provide a server-safe fallback.
-
-## Agent behavior
-
-- Fix crash-risk paths first, then clean up architecture.
-- Delegate framework SSR primitives to official Expo docs, then apply MDS-specific guard patterns and Doctor rule compatibility.
-
+# Skill: Expo SSR Safety
+
+Use when preparing or debugging Expo Router web/server output paths.
+
+## Main rule
+
+Assume server runtime first: guard browser-only APIs, isolate native-only code, and keep shared modules safe in both client and server contexts.
+
+## Checks
+
+- Guard `window`, `document`, `navigator`, `localStorage`, and `sessionStorage` access.
+- Confirm client-only packages are not imported by server/API execution paths.
+- Confirm storage/session access happens in client-safe lifecycle points.
+- Verify API routes and server modules do not rely on browser globals.
+- Validate dynamic imports or adapters for platform-specific behavior.
+
+## Preferred structure
+
+- Use small environment-check helpers for browser-global access.
+- Split client-only logic behind platform/runtime-specific modules.
+- Keep server-safe defaults and explicit fallbacks in shared utilities.
+
+## Example fix
+
+- Problem: Shared auth helper reads `localStorage` at module load and crashes SSR.
+- Fix: Move storage access into guarded runtime functions and provide a server-safe fallback.
+
+## Agent behavior
+
+- Fix crash-risk paths first, then clean up architecture.
+- Delegate framework SSR primitives to official Expo docs, then apply MDS-specific guard patterns and Doctor rule compatibility.
+

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

@@ -1,41 +1,41 @@
-# Skill: MDS Plugin Creation
-
-Use when building or extending an MDS plugin bundle for any agent client (Claude Code, Codex, Cursor, etc.).
-
-## Main rule
-
-Plugins are thin bundles. `packages/knowledge` is the source of truth for skills, command prompts, checklists, and examples. Do not hand-author plugin skill/command copies in plugin folders.
-
-## Structure conventions
-
-Every MDS plugin lives in `plugins/<client-name>/`:
-
-```
-plugins/<client-name>/
-  README.md
-  CLAUDE.md            # Claude-specific merge instructions (if relevant)
-  .mcp.json
-  commands/            # generated command markdown from canonical prompt specs
-  skills/              # generated skill files
-```
-
-## Checks
-
-- Skill markdown lives only in `packages/knowledge/src/content/skills/`.
-- Prompt/command markdown lives only in `packages/knowledge/src/content/prompts/`.
-- `plugins/<client>/skills/` remains generated output and is not manually edited.
-- Commands reference real MCP tool names from `packages/mcp-server`.
-- MCP config uses the `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.
+# 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/dist/content/skills/production-server-patterns.md

@@ -1,31 +1,31 @@
-# Skill: Production Server Patterns
-
-Use when setting up or debugging how an Expo project serves production traffic.
-
-## Main rule
-
-Pick one explicit production serving mode per environment and codify it in scripts; avoid mixed runtime assumptions.
-
-## Checks
-
-- Confirm selected mode is documented: managed Expo/EAS, Express adapter, or dual-server.
-- Confirm serving scripts match the selected runtime (`npx expo serve`, `node server.js`, or dual process scripts).
-- Confirm routing boundaries are clear when app and API are separate services.
-- Confirm env var ownership differs correctly across app server and API server in dual-server mode.
-- Confirm “fresh” start scripts exist where server state/caches can cause drift.
-
-## Preferred structure
-
-- Define `serve:prod` and `serve:prod:fresh` scripts for the chosen mode.
-- Keep server bootstrap and adapter code in dedicated files/modules.
-- Keep deployment notes aligned with runtime mode in project memory.
-
-## Example fix
-
-- Problem: Team mixes Expo serve and custom Express commands, causing inconsistent behavior.
-- Fix: Select one primary mode per environment, standardize scripts, and document routing/env boundaries.
-
-## Agent behavior
-
-- Use the project’s declared serving mode unless a migration is explicitly requested.
-- Delegate framework runtime primitives to official Expo docs, then enforce MDS conventions for script consistency, environment boundaries, and operational clarity.
+# Skill: Production Server Patterns
+
+Use when setting up or debugging how an Expo project serves production traffic.
+
+## Main rule
+
+Pick one explicit production serving mode per environment and codify it in scripts; avoid mixed runtime assumptions.
+
+## Checks
+
+- Confirm selected mode is documented: managed Expo/EAS, Express adapter, or dual-server.
+- Confirm serving scripts match the selected runtime (`npx expo serve`, `node server.js`, or dual process scripts).
+- Confirm routing boundaries are clear when app and API are separate services.
+- Confirm env var ownership differs correctly across app server and API server in dual-server mode.
+- Confirm “fresh” start scripts exist where server state/caches can cause drift.
+
+## Preferred structure
+
+- Define `serve:prod` and `serve:prod:fresh` scripts for the chosen mode.
+- Keep server bootstrap and adapter code in dedicated files/modules.
+- Keep deployment notes aligned with runtime mode in project memory.
+
+## Example fix
+
+- Problem: Team mixes Expo serve and custom Express commands, causing inconsistent behavior.
+- Fix: Select one primary mode per environment, standardize scripts, and document routing/env boundaries.
+
+## Agent behavior
+
+- Use the project’s declared serving mode unless a migration is explicitly requested.
+- Delegate framework runtime primitives to official Expo docs, then enforce MDS conventions for script consistency, environment boundaries, and operational clarity.

package/dist/content/skills/project-onboarding.md

@@ -1,31 +1,35 @@
-# 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.
+# 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.
+- Confirm `mds onboard` installed newly declared packages, or that
+  `--no-install` was explicit and the printed install command is still
+  pending. Do not treat onboarding as complete while those modules are
+  missing.
+
+## Preferred structure
+
+- Use conversational intake to capture audience, flows, data needs, platform targets, and deployment intent.
+- Keep visual guidance in `project/style.md`; keep technical/agent rules in `project/guidelines.md`.
+- Keep onboarding outputs phase-based so follow-up work can continue from `project/todo.md`.
+
+## Example fix
+
+- Problem: Team starts coding before onboarding, causing missing docs and conflicting architecture assumptions.
+- Fix: Run onboarding flow, generate canonical project memory, reconcile open context markers, then resume implementation using phase order.
+
+## Agent behavior
+
+- Ask one focused onboarding question at a time when required by the flow.
+- Delegate framework primitive setup guidance to official Expo resources, then layer MDS project-memory and workflow automation rules.

package/dist/content/skills/research-plan-intake.md

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