---
name: ditto-site-cloner
description: Clone an authorized website into componentized Next.js or Vite source with Ditto through the hosted REST API or the official Ditto MCP routed by the central mm-skills MCP. Use when an agent needs a deterministic starting point from an existing public design, must submit a clone job, inspect available Ditto MCP tools, or integrate website cloning into an app-builder workflow. Defaults to a single-page Next.js project with Tailwind styling.
compatibility: Requires either access to the hosted mm-skills Streamable HTTP MCP or curl with a DITTO_API_KEY environment variable. The central router requires Node.js 20 or newer. Never place API keys in prompts, shell history, repository files, generated source, or logs.
license: Apache-2.0
---

# Ditto site cloner

Use Ditto to create a deterministic, componentized codebase from a website the user owns or is explicitly authorized to reproduce.

Do not use this skill to impersonate a person or organization, reproduce credential-entry or payment flows for deception, bypass access controls, or copy protected private content. Treat visual similarity as a technical capability, not permission.

## Preferred mm-skills MCP workflow

The deployed `mm-skills` application exposes one central MCP endpoint:

```text
https://<mm-skills-domain>/mcp
```

Authenticate to that endpoint with the independent `MCP_ACCESS_TOKEN`. The Ditto API key remains configured only on the server as `DITTO_API_KEY`.

1. Call `mcp_router_status`.
2. Confirm Ditto is enabled and `apiKeyConfigured` is true.
3. For the documented REST operation, call `ditto_create_clone` with the source URL and optional Ditto options.
4. For capabilities exposed by Ditto's official MCP, list tools and use names beginning with `ditto__`.
5. Record the returned job ID and status.
6. Follow progress through a Ditto MCP progress tool when available, or use the documented events endpoint outside MCP.
7. Inspect generated code before installing dependencies or running it. Remove copied analytics IDs, third-party keys, tracking snippets, and environment-specific URLs.

The router preserves existing Coolify tool names. Only official upstream Ditto tools receive the `ditto__` prefix, preventing collisions in the shared tool catalog.

## Direct REST request

Keep the key in an environment variable:

```bash
export DITTO_API_KEY='replace-with-your-key'
```

Create the same clone job represented by the `ditto_create_clone` MCP tool:

```bash
curl --fail-with-body --silent --show-error \
  -X POST 'https://api.ditto.site/v1/clones' \
  -H "Authorization: Bearer ${DITTO_API_KEY}" \
  -H 'content-type: application/json' \
  -d '{
    "url": "https://example.com/",
    "options": {
      "mode": "single",
      "framework": "next",
      "styling": "tailwind"
    }
  }'
```

A successful submission currently returns HTTP `202` with queued job metadata, including a job ID.

Follow the live event stream after replacing the placeholder:

```bash
JOB_ID='replace-with-job-id'

curl --fail-with-body --no-buffer --silent --show-error \
  "https://api.ditto.site/v1/clones/${JOB_ID}/events?after=0" \
  -H "Authorization: Bearer ${DITTO_API_KEY}"
```

Do not print shell tracing with `set -x` while the authorization header is present.

## Clone request defaults

Unless the user specifies otherwise, use:

```json
{
  "mode": "single",
  "framework": "next",
  "styling": "tailwind"
}
```

Pass additional supported Ditto options through the `options` object rather than inventing fields. Verify current provider documentation when a requested mode, framework, or styling target is not already known to be supported.

## Official Ditto MCP through the router

The router connects server-to-server to:

```text
https://api.ditto.site/mcp
```

It initializes the upstream MCP, forwards the server-side bearer token, preserves the upstream MCP session ID, handles JSON and SSE responses, caches the remote tool list, and exposes every discovered tool as:

```text
ditto__<upstream-tool-name>
```

Never send `DITTO_API_KEY` as a tool argument. A missing key is a deployment configuration problem, not information to request in chat.

## Generated-code review

Before treating the clone as production-ready:

1. Compare responsive behavior at representative mobile, tablet, and desktop widths.
2. Verify navigation, menus, accordions, forms, hover/focus states, motion, metadata, fonts, and asset paths.
3. Replace copied text, trademarks, images, and brand elements unless the user has rights to retain them.
4. Remove source-site analytics, ad tags, consent identifiers, API endpoints, and embedded secrets.
5. Run dependency install, type checking, linting, tests, and a production build in an isolated workspace.
6. Add accessibility names, keyboard behavior, reduced-motion handling, and semantic landmarks where extraction is incomplete.
7. Report fidelity gaps rather than concealing them with hard-coded screenshots or inaccessible overlays.

Read [references/security.md](references/security.md) before deploying the router or processing sensitive source URLs.

## Reporting

Return:

1. source URL and authorization assumption;
2. request mode, framework, and styling;
3. job ID and current status;
4. whether REST or a namespaced official MCP tool was used;
5. generated project location or retrieval result when available;
6. validation performed on the generated code;
7. remaining fidelity, licensing, privacy, or security issues.