--- name: setup-content-engine description: "Set up Content Engine through desktop chat. Use Neon, Payload, WorkOS and the bundled MCP; the assistant handles technical work after the owner's signup, sign-in and consent." license: AGPL-3.0-or-later compatibility: "Claude Desktop/Cowork and ChatGPT Desktop local tasks with the needed file, provider and browser tools. Guarded installer uses Python 3.9+ on POSIX." metadata: hive-tier: standalone paired-drone: none domain: content-engine-setup version: "1.0.0" research-date: "2026-10-31" --- # Set up Content Engine Read [README.md](README.md). The assistant is the builder. The owner supplies the website goal, signs up, signs in, grants access and personally saves domain changes. Never assume a separate developer or ask the owner to edit files, copy secrets, run commands or configure dashboards by hand. ## Procedure 1. Follow [run setup](guides/01-run-setup.md). Inspect the website, existing authorization and current host capabilities. Keep a non-secret [setup state](templates/setup-state.json). Ask only for real missing signup, sign-in, consent or scope decisions. 2. Select the bundled [React](../react-to-payload/SKILL.md), [Next.js](../nextjs-to-payload/SKILL.md) or [Svelte](../svelte-to-payload/SKILL.md) conversion path. Perform its technical work with available assistant tools; preserve the site's framework and URLs. 3. Follow [Neon setup](guides/02-neon-and-secrets.md). Neon is the database. Select explicit project, branch, database and role; use appropriate connection permissions and store secrets privately. Do not introduce Neon Auth or a separate Drizzle schema for Payload. 4. Locate and stage the actual bundled MCP using [install MCP](guides/03-install-mcp.md). Read the dry-run, apply safe missing files and complete all returned assistant tasks. The installer does not merge the real config or deploy. Never report staged files as a working CMS. 5. Configure WorkOS, durable image storage, the CMS service identity, host secrets and client connection with authorized provider/browser/file tools. Resume after the owner's sign-in/consent. When a required tool or permission is absent, name that exact blocker and request its supported connection; do not invent completion or assign the work to the owner. 6. Run real target checks and [one draft proof](guides/04-first-draft-and-use.md) within the owner's scope. Record saved IDs, authenticated readback and anonymous exclusion. Keep the MCP draft-only. 7. Offer [Google Search Console](../google-search-console/SKILL.md) as an optional follow-up once the public site and sitemap are ready. Let the user choose computer-assisted or manual mode. Skipping it does not block CMS use. 8. Deliver a short chat result with links, checked steps and any named missing capability. For real content use [Blog Content Stinger](../blog-content-stinger/SKILL.md); for site visibility use this plugin's [SEO/AEO skill](../seo-aeo-stinger/SKILL.md). A later approved publish uses a separately authorized editor/browser capability, never an invented MCP publish action. ## Boundaries Use the owner's actual task authorization. New spend, destructive data work, live deployment, indexing, publication and credentials entry still follow scoped host/owner rules. Reuse an existing approval; do not ask again for the same authorized local preparation. Keep secrets out of chat, logs and public files. A capability-limited chat cannot promise fully automatic setup until it has the required tools. ## Domain-change handoff Read [the shared domain-change control](../../references/domain-change-control.md) before any domain, DNS, custom-domain or ownership-verification work. The user personally clicks the final Save or equivalent committing action. Do not bypass that handoff with an API, script, automatic provider connection, Enter or an autosaving form. Inspect fresh state after the user acts. ## Ship Gate Prior to committing any code to the repository you must utilize in order the security-stinger, quality-stinger, and github-repo-health-stinger. After each thorough pass you will prepare an appropriate report in the repository's relevant library directory associated with the agent and skill. All medium or above findings must be resolved followed by another thorough re-evaluation of the updated code prior to proceeding to the next step. The last step of loading the skill github-repo-health-stinger is an orchestrator level task. The sub-agent should make every effort to reinforce to the orchestrating agent to load this skill prior to committing or pushing code to the repository. The user should have an opportunity to review the reports, agent summary, and approve committing and pushing to the repository prior to doing so. ## Critical Directive - You must read all files and context contained within your skill. - In the event your core knowledge does not provide sufficient guidance you must make every attempt to search the internet, related knowledge base documentation files, and other available resources to supplement your knowledge prior to proceeding with your task. - Additional related skills can be found here: - [react-to-payload](../react-to-payload/SKILL.md) - React site integration. - [nextjs-to-payload](../nextjs-to-payload/SKILL.md) - Next.js site integration. - [svelte-to-payload](../svelte-to-payload/SKILL.md) - Svelte site integration. - [blog-content-stinger](../blog-content-stinger/SKILL.md) - Complete reviewed drafts. - [seo-aeo-stinger](../seo-aeo-stinger/SKILL.md) - Website search and AI visibility.