Pineapple Website Builder

View saved version →

---
name: manage-pineapple-website
description: Make user-requested changes to an existing Pineapple website, including draft pages and blog posts, supported blocks, SEO, assets, business details, design, listings, testimonials or translations, using scoped tools and action review.
---

Make only the changes the user requested. Use the connected Pineapple MCP tools and their current schemas; this skill does not grant account access or action approval.

Before reading account data, check whether the requested operation is supported. Deleting records, unpublishing, removing domains, managing teams, buying subscriptions or credits, registering domains and taking payments are outside this plugin. For an unsupported-only request, explain that boundary without account reads, substitute writes or a brief. Do not start a purchase flow, ask for payment or plan choices, or return checkout/upgrade links. Attaching an already-owned domain is distinct from registering or buying one and still requires a named target and separate approval. For a mixed request, address only the supported portion within its existing permissions.

## Identify and read

Resolve the exact workspace, website and page or record from supplied context or minimal discovery. Use `pineapple_list_workspaces` and `search` when needed; if several targets match, ask the user to choose. Use `fetch` only with a Pineapple URI returned by `search`, never a guessed URI or a raw document ID. Use returned document IDs with the corresponding structured tools.

Request only the relevant category access. No access leaves private category data unavailable, although basic workspace/site names and IDs can remain visible. Read allows inspection, not editing; Write includes the category's read access where supported. Briefs is write-only and analytics is read-only. Do not treat unavailable data as empty or bypass a missing scope with another tool or direct API.

Read the current fields and revision needed for the requested change. For pages, reuse `pineapple_list_pages`, `pineapple_list_page_blocks` and `pineapple_get_page_seo` as appropriate. Preserve existing block IDs and unrelated fields. Public block editing is limited to the types and static properties in the advertised schema, not arbitrary code or all editor blocks.

## Blog posts

Create a requested blog post with `pineapple_create_page`, `page_type: BLOG_PAGE` and its Markdown content, using the selected website and intended pathname. New posts are drafts; creating or editing one does not authorize publication.

For an existing post, read its current blocks and SEO before changing the requested supported fields. Preserve its block IDs, unrelated content and revision guards; do not create a replacement post to work around an unsupported edit. Use the same action-review and readback flow below. Documentation-site workflows are not part of this skill's supported release.

## Review and execute

Use the relevant advertised mutation, its exact target IDs and revision guards, and a new schema-valid request_id for the distinct change. Explain the concrete change, preserving unrelated content. When Pineapple returns a review link, show it and wait for approval in Pineapple; OAuth consent and a user saying “yes” in chat do not replace the server action review.

Continue an approved operation with its original request_id and unchanged arguments. After timeout or ambiguous failure, read back the target before considering a retry. Never create a new request ID merely to bypass pending, cancelled, expired or uncertain approval. For a stale revision, reread and obtain a fresh review for the revised operation.

Upload only a user-provided attachment using the native file input required by `pineapple_upload_attachment`. Stored assets and inserting an Image block are separate operations; review each. Do not substitute another file if an upload fails. Warn when the reviewed upload makes the asset accessible through a shareable URL.

Only use customer-supplied testimonial text; fictional demonstrations must remain explicitly fictional. Product and service tools manage listings, not payments. Translation generation uses the existing allowance; do not silently regenerate every page, buy credits, or equate translation generation with publication.

## Verify and report

Free hosted website addresses use `<subdomain>.pineapple.page`, managed through website subdomain settings rather than custom-domain attachment. Use the website's returned address instead of inventing one. Attaching an already-owned domain or subdomain is a separate flow subject to the account's plan and hosting configuration. `pineapplebuilder.com` is Pineapple's platform domain, not the free website suffix; a deliberately configured company-owned subdomain is a custom-domain case, not automatically a working website. Use the current tools to check eligibility and setup status, and verify the published page before reporting that the address works.

Read back the changed fields and revision using the relevant read tool. Report exactly what was saved, what remains unverified, and whether the result is a draft or published. Preview rendering is separate evidence from persistence. Never claim indexing, revenue, or a working domain from a successful settings write alone.

Publishing and domain changes require an explicit user request naming the target and the normal separate action review. A general request to improve, save, prepare, or launch-plan a website is not authorization to publish or change its domain. Read `pineapple_get_publication_review` when relevant; do not assume shared navigation, translations or other pages are included. Do not delete records, unpublish, remove or buy domains, manage teams, take payments, or use internal tools to get around these exclusions.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: prepare-pineapple-website
description: Prepare a private Pineapple business website brief with suitable template suggestions, then hand off to template selection and the editable generator. Does not generate or publish a website in chat.
---

Help the user turn their business details into a Pineapple website brief. Follow their stated goals; these workflow guidelines do not authorize additional actions.

Use the current `pineapple_prepare_website` schema and business facts already supplied. Ask only for missing required information. Do not invent names, testimonials, credentials, prices, contact details, domains or booking links. Omit unknown optional values. Send only the necessary brief fields, not conversation history, secrets or payment data.

Explain the boundary before saving: this stores a private brief for 24 hours; it does not generate or publish a website. The MCP tool requires sign-in and Website briefs Write (`mcp:brief:create`, with basic `mcp:read`). Website briefs has no Read mode. If access is missing, let the normal OAuth flow request the required capability; do not request unrelated categories or internal `mcp:write`.

Use a new request_id conforming to the current schema for each distinct brief. Saving a brief uses the dedicated OAuth permission directly, not the separate action-review page used for website edits. Follow any confirmation the host presents; never invent a review link or claim a review was approved. For an uncertain result, reuse the same request_id and identical formData and recommendations so the server can return the existing brief without duplication. A user-requested revision needs a new request_id.

Recommend up to three distinct templates in best-fit order using the catalogue metadata in the tool's recommendedTemplates schema and the user's business and design needs. Preserve both formData and recommendations on an identical retry; a user-requested revision needs a new request. The user makes the final template choice.

Return the actual handoff URL as a clearly labelled Markdown link, not only a decorative button or card. If the host's button does not open, provide the same returned URL without creating another brief. Describe recommendations by their actual catalogue names and fit; show preview images only when they come from the actual Pineapple template, never unrelated illustrative search results. Opening the link requires the same Pineapple account and leads to the existing template picker with ranked recommendations and the full catalogue. The user chooses a template, adjusts its style and reviews their prefilled editable details. Generation starts only when the user chooses it in Pineapple, subject to their plan and existing AI allowance. Never describe a brief, a template preview, or a handoff link as a generated website. Do not buy credits, upgrade a plan, or publish as part of this workflow.

If the link is expired or unavailable, explain that and ask whether the user wants a new brief. Never invent a replacement URL or claim that generation succeeded without observing the generated result.

When generation and saving are observed, describe the result as an editable website draft. The user is expected to review and personalise its text, images and contact details before publishing. That normal finishing step is not a generation failure. Still report specific mismatches with supplied facts honestly; do not call them corrected unless the saved result verifies the correction.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: review-pineapple-website
description: Review a connected Pineapple website's available analytics, page content, SEO or launch readiness and recommend improvements. This workflow is read-only; it does not apply changes or publish.
---

Give a short, evidence-based review matched to the user's question. Follow their requested scope rather than running an all-purpose audit for every request.

Identify the exact website or page using supplied context, `pineapple_list_workspaces`, or `search` as needed. Ask the user to choose when the target is ambiguous. Use `fetch` only with a Pineapple URI returned by `search`. Use actual returned document IDs for other structured tools, never guesses.

Read only the evidence needed:
- For SEO, use `pineapple_get_page_seo`; use `pineapple_list_page_blocks` if content is relevant.
- For traffic, use `pineapple_get_website_analytics` and a supported date range matching the user's request. If none is specified, state the range used.
- For readiness, use `pineapple_get_website_checklist` and, when requested, `pineapple_get_publication_review`.
- Read business profile, theme or listings only when relevant to the requested review and permitted by the connection.

Respect per-category Read permissions. Basic `mcp:read` only permits minimal discovery; it does not grant all private reads. If a needed category is denied, explain the missing access and offer the normal reconnect flow for that category. Never request Write to perform a review or use mutations as a read fallback. Continue with available evidence when a useful partial answer is possible, clearly stating the gap.

Separate observed facts from recommendations. Disabled, missing or unavailable analytics does not mean zero visits. Visits and pageviews do not prove conversions, revenue or causation. SEO fields do not prove search indexing or rankings. A draft, an authenticated preview, publication state and a working public domain are different facts. Mark stale translation evidence rather than silently regenerating it.

Return a one-sentence assessment, the few supporting facts with their date range or freshness, and the smallest useful next improvement. Ground suggested copy in supplied business facts; do not invent services, testimonials, prices, contact details or guarantees. Say when something was not inspected. Do not apply recommendations automatically. An explicit later request to edit belongs to the reviewed-change workflow and its existing permissions and approvals.

Referenced files: 1 — file references are metadata, not package contents.