mdcms-setup

MDCMS Setup (Master Orchestrator)

Walk the user end-to-end through adding MDCMS to their project. Your job is to detect which phase they are in, delegate to the focused skill that owns that phase, and return here for the next decision.

When to use this skill

Any user intent to add, install, configure, or integrate MDCMS. You are the entry point to the MDCMS skill pack. Do not implement phase work yourself — delegate.

Phases

Work through these sequentially. For each phase, decide whether the user is done already, then either skip or invoke the focused skill. Always say what you're doing and why before you do it.

Phase 1 — Is an MDCMS backend reachable?

Ask the user where their MDCMS server lives.

1. If they have a hosted or self-hosted URL they know works: continue.
2. If they plan to self-host: invoke mdcms-self-host-setup.
3. If they have no server and don't want to self-host: stop. MDCMS needs a backend for the rest of the flow to do anything meaningful.

Verify reachability before continuing:

curl -sf "$MDCMS_SERVER_URL/healthz" && echo ok

If this fails, fix it before moving on.

Phase 2 — Greenfield or brownfield?

Check whether the user's repo already has Markdown or MDX content that MDCMS should manage. Exclude the places where markdown commonly appears but is not user content — repo-level docs, skill packs (including this one), issue/PR templates, and dependency directories:

find . -type f \( -name '*.md' -o -name '*.mdx' \) \
  -not -path '*/node_modules/*' \
  -not -path '*/.*' \
  -not -path './skills/*' \
  -not -path './docs/*' \
  -not -path './apps/docs/*' \
  -not -path './.github/*' \
  -not -name 'README*' \
  -not -name 'CHANGELOG*' \
  -not -name 'LICENSE*' \
  -not -name 'SKILL.md' \
  | head

If this surfaces files, ask the user which of the top-level directories (content/, pages/, posts/, or a project-specific path) are actually editorial content vs. product docs. Only editorial content belongs in MDCMS.