> **rp-project-intake** — skill 30 of 67 in [wix/skills](https://skillsdocs.com/wix/skills).
>
> Book (all skills, one file): https://skillsdocs.com/wix/skills.md
> Machine manifest: https://skillsdocs.com/wix/skills/.well-known/agent-skills/index.json
> Install the book: `npx skills add wix/skills`
> Upstream: https://github.com/wix/skills/blob/main/skills/wix-replatform/resources/rp-project-intake/SKILL.md @ `main`
> Raw bytes, no header: https://raw.githubusercontent.com/wix/skills/main/skills/wix-replatform/resources/rp-project-intake/SKILL.md
> Base for relative paths: https://raw.githubusercontent.com/wix/skills/main/skills/wix-replatform/resources/rp-project-intake/
> Licence: MIT — https://spdx.org/licenses/MIT.html
>
> Content © its authors, served unmodified. Takedown: https://github.com/DreambaseAI/skillsdocs/issues/new?labels=takedown&title=Takedown+request

<!-- Verbatim upstream SKILL.md follows, YAML frontmatter included. -->

---
name: rp-project-intake
description: Resolves the active migration project and the minimum intake decisions needed to route it.
---

# rp-project-intake

Use when the router reports unresolved project, delivery mode, destination strategy, or
source mode.

Resolve project precedence: explicit user project, current project context, the sole
project under the migrations root, otherwise ask the user to choose. Never infer from a
sibling project.

Project initialization also creates `EXPECTATIONS.md` at the project root when it is
missing. Mention it as an optional place to record expectations; do not make it an intake
question or replace a user's existing file.

Resolve delivery mode before destination creation: default to `management`; choose
`website` for frontend only; choose `management_and_website` when the user wants both a
backend migration and a customer-facing storefront. Accept `both` as an input alias for
`management_and_website`, then record the canonical value in `orchestration/decisions.json`.

For a new destination site, the site type is an explicit operator choice with no
default: Headless (a website developed in code), Wix Studio, or Wix Harmony. It decides
where the imported data lives and cannot be changed later as a setting. A generic "Editor"
answer is incomplete until Studio or Harmony is named; the classic Wix Editor is not offered.
Ask it together with Harmony's business type as one combined question — store,
bookings/services, another business, or "not sure, start blank" — never as two questions.
Record it with `orchestration-state.js decide --key targetSiteType --value <type>
[--business-type store|bookings|other]`; a Harmony answer that names no business type records
`unknown`. A choice the operator already gave counts; do not ask again. `rp-destination` raises
the durable request when it is still missing. Existing-site adoption needs no type.

For an **existing** destination site, ask whether to mute its notifications before the first
write. The router returns the exact question and choices
(`missing_notification_mute_decision`, `question`); show them in those plain words and do not
pick for the operator. Mute: Wix stops all site notifications, including customers' emails,
until someone unmutes, and the live business may miss real customer notifications during the
import. Don't mute: customers and the owner may get emails for imported records (orders,
bookings, forms, RSVPs, and so on). Record the answer with `orchestration-state.js decide
--key notificationMute --value on|off` (it also writes `WIX_MUTE_NOTIFICATIONS`). A new site is
always muted and is never asked. A supervised `replatform run` raises this question itself as
a durable request; answer it with `replatform answer`. Once setup has written to the site the
answer cannot change.

For delivery modes that include management, also record `managementImportMode`. Default to
`standard`; accept an explicit user choice of `quick` at intake even before the source URL is
probed. The later source-inputs/probe result validates whether a matching quick adapter exists;
never promise quick support merely from the user's choice.

Record `faceliftMode=requested` only when the user explicitly asks for a post-clone UI/UX
facelift. It is optional, defaults to off, and is not a substitute for normal clone fidelity.
In explicit user-requested 1-click mode include this choice in the initial grouped intake so the later, separate
facelift stage is authorized without another routine approval.

In normal mode ask only the current missing decision. In explicit user-requested 1-click mode
record `automationMode=one_click` with `source=user`, collect every still missing intake value
together (including the existing-site mute question), record the answers, and continue. Never infer one-click from an uploaded file or
execution surface. Delegate all destination,
source-file, and credential procedures to their dedicated modules.

## Output

The resolved project, plus `orchestration/decisions.json` entries for whichever of
`deliveryMode`, `managementImportMode`, `targetSiteType` (with `targetSiteBusinessType` for
Harmony), `notificationMute` (existing sites), `faceliftMode`, and `automationMode` this run resolved. This is what a dispatched run must produce.