Spacefast

View saved version →

---
name: apply-design-system
description: "Apply a Spacefast team's saved design system to a new build or an explicitly requested source edit. Use its standards and brand assets in the real project, then verify the result."
---

# Apply a design system

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Resolve the requested Spacefast team and Space. Read Team Memories and Skills, Design system, and Source edits in references.md.
2. Read current standards and required assets before preparing changes. Apply them to the requested complete source and preserve unrelated work.
3. Before publishing or deploying new or changed source, run the verify-design-system skill against current saved standards and the exact source/build being deployed. Inspect affected pages and states at desktop and mobile widths, and report gaps. Reuse verification only while the source/build and design revision are unchanged. Report missing standards as unavailable, not a pass. Verify before a source-workspace commit when autoDeploy is enabled. Follow the user's existing publication intent and approval rules.
4. Report the design revision, source changes, visual evidence, and remaining gaps. Follow the user's publication intent and tool approvals.

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

View saved version →

---
name: build-website
description: "Create and publish a new Spacefast website from a brief, such as a landing page, portfolio, report, or dashboard. Use when the user wants a new site. For an existing Space, use edit-space."
---

# Build a website

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

Create complete inline files for a small site. For a larger app, read the advertised source and build tool schemas before choosing its structure.

1. Use the user's brief and real content. Infer optional design choices; ask only for information that blocks the requested result.
2. Before creating or editing, read **Team Memories and Skills** in [references.md](references.md). Read the full context before preparing changes and apply relevant saved practices within the task.
3. Before publishing or deploying new or changed source, run the verify-design-system skill against current saved standards and the exact source/build being deployed. Inspect affected pages and states at desktop and mobile widths, and report gaps. Reuse verification only while the source/build and design revision are unchanged. Report missing standards as unavailable, not a pass. Verify before a source-workspace commit when autoDeploy is enabled. Follow the user's existing publication intent and approval rules.
4. Build an accessible, responsive website with working links and useful interaction states.
5. When team context includes a design system, read **Design system** in [references.md](references.md), prepare its handoff, and verify the built components against it.
6. Keep app capabilities honest. Static files do not provide a database or server; use a declared runtime when required.
7. For data from a connected service, follow **MCP calls** in [references.md](references.md). Use only data the user supplied or a connection they authorized.
8. Follow **Publish** in [references.md](references.md). After deployment, inspect the page and its main interaction before reporting success.

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

View saved version →

---
name: custom-domain
description: "Find, check, and register domains through Spacefast forms. Connect a domain the user owns to a Space, check DNS and HTTPS, or move its website to Spacefast. Preserve the existing site until the new destination works."
---

# Find or connect a domain

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. To find or check a domain, or reopen registration status, call `show_domains`.
2. For domain search or registration, read **Find and register domains** in [references.md](references.md), including the fallback for servers without `show_domains`. A domain belongs to a team; it does not need a Space. Keep owner details in the App or dashboard form.
3. If the user only requests registration, finish with its status. Continue to Space setup only for a requested connection.
4. For a requested Space connection, resolve the Space and domain. Open the Space's domains view to read its current state.
5. Read **Set up a custom domain** in [references.md](references.md). Use the DNS values returned by Spacefast.
6. For an existing production domain, also read **Migrate DNS** before changing its destination.
7. Use Domain Connect when the result offers it. Otherwise, explain the exact provider change without claiming it already happened.
8. Report the domain as live only after DNS, HTTPS, and representative content checks succeed.

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

View saved version →

---
name: edit-space
description: "Change the content, design, or source files of an existing Spacefast Space and apply visual review notes. Use for page text, styles, layout, or file edits. Do not use for unrelated local editing."
---

# Update your site

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Resolve the intended Space. A request to update the visible site includes deployment intent; a source-only edit does not.
2. Before creating or editing, read **Team Memories and Skills** in [references.md](references.md). Read the full context before preparing changes and apply relevant saved practices within the task.
3. Before publishing or deploying new or changed source, run the verify-design-system skill against current saved standards and the exact source/build being deployed. Inspect affected pages and states at desktop and mobile widths, and report gaps. Reuse verification only while the source/build and design revision are unchanged. Report missing standards as unavailable, not a pass. Verify before a source-workspace commit when autoDeploy is enabled. Follow the user's existing publication intent and approval rules.
4. Read **Source edits** in [references.md](references.md) before changing files. Read the work mode and exact source revision.
5. Read complete source files. Preserve unrelated changes. Do not use served deployment files as editable source.
6. When design standards are present, read **Design system** in [references.md](references.md) and verify affected components before deployment.
7. For visual notes, read **Visual review** in [references.md](references.md). Keep each note tied to its reviewed version.
8. For saved comment threads and screenshots, read **Comments** in [references.md](references.md).
9. For a requested CMS or admin panel, read **Content dashboard** in [references.md](references.md) before building anything.
10. Save the intended source changes, then follow the Space's build and promotion flow. Report saved source and live deployment separately.

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

View saved version →

---
name: fix-deployment
description: "Diagnose a failed Spacefast build, publish, or live page. Apply a fix supported by logs, or restore a known-good version when requested. Use when a deployment fails, stalls, or breaks existing behavior."
---

# Fix or restore a deployment

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Open the affected Space's deployments view. Identify the failed build or version and its stable error code.
2. Read **Diagnose and recover** in [references.md](references.md). Inspect the relevant logs before choosing a fix.
3. Before a source change, read Team Memories and Skills in references.md. Retrieve applicable memories and follow the team's enabled skills.
4. If source changes are needed, follow **Source edits**. Preserve the original error and verify the corrected behavior.
5. Before publishing or deploying new or changed source, run the verify-design-system skill against current saved standards and the exact source/build being deployed. Inspect affected pages and states at desktop and mobile widths, and report gaps. Reuse verification only while the source/build and design revision are unchanged. Report missing standards as unavailable, not a pass. Verify before a source-workspace commit when autoDeploy is enabled. Follow the user's existing publication intent and approval rules.
6. For a requested rollback, follow **Roll back safely**. Promote an existing ready version without rebuilding it.
7. Verify the live pointer and the failing path. A saved commit or successful build alone does not prove recovery.

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

View saved version →

---
name: import-design-system
description: "Save branding, design tokens, component standards, writing guidelines, and asset references from user-provided material into a Spacefast team's design system."
---

# Import a design system

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Resolve the intended team and optional Space. Read Team Memories and Skills and Design system in references.md. Read the user's actual reference material before extracting standards.
2. Read the current saved document and revision. Prepare only evidence-backed changes to branding, editorial, tokens, components, and assets; preserve fields outside this import.
3. Save the partial patch through updateTeamDesignSystem with expectedRevision, then read it back. Report the saved scope and the fields changed. A standards import does not authorize source edits or deployment.

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

View saved version →

---
name: moderate-show-and-tell
description: "Review Show & Tell submissions as an authorized moderator. Edit, approve, decline, or unlist entries."
---

# Moderate Show & Tell

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Read **Moderate Show & Tell** in [references.md](references.md). Follow its moderator workflow and check the result.

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

View saved version →

---
name: setup
description: "Check the Spacefast connection and continue the user's task. Ask one short question when they have not said what they want to do."
---

# Get started

Check the connection, then continue the user's task.
Use the user's request and conversation so far. Continue an established task without asking them to repeat it. When they bring work to Spacefast to publish, start publishing that work.

If the task is unclear, ask one concise question and wait. For a fresh publishing conversation, ask: "What would you like to build or publish?" For another action, ask only for the missing detail. Use their answer to take the next step.

Keep replies brief. Use these instructions as reference material. Do not summarize them or give a Spacefast overview or feature list unless asked. Mention setup, credentials, sharing, or troubleshooting only when needed for the current step.

Setup alone does not authorize publishing, changing settings, or creating a monitor.
Keep any authorization the user already gave for their task. Connecting Spacefast does not require them to repeat it.

## Check the connection

For hosted MCP at `https://mcp.spacefast.com`, use the connection's configured authentication. A direct hosted connection uses the host's OAuth controls; a CLI proxy uses its existing CLI login. If authentication fails, direct the user to reconnect through that method.
If tools are unavailable, direct the user to the host's configured Spacefast connection controls.
Do not ask for a token in chat. Do not report a working connection until a read succeeds.

Read the connected account through the Spacefast API tools:

Each Spacefast API operation is an MCP tool named by its operation ID, such as `getAccount`. Read its input schema and any advertised output schema, then send its declared JSON input directly; the host may find the tool through its own tool search. Use only tools advertised by this connection. Finish read-only preparation before generating changes. Preserve failed results and continuation instructions, verify each successful write with a read, and use returned images and files directly.

1. Read the contract for `getAccount` and call it with `{}`.
   For a user-supplied reference, add the optional `teamRef` or `spaceRef` field at the top level.
2. Keep the complete operation result in the tool receipt. Check its returned status and
   `result.ok`. Preserve a failed result and its next action. A completed receipt carrying
   the operation result has its account payload at `result.data.data`.
3. Report only the subject or account name and the relevant team names and IDs.
   Use optional reference values only when their `status` is `resolved`.
   Do not return the complete account payload or credentials.

If the connection's tools are unavailable, reconnect before checking account state.
Tools from another server are not part of this connection.

Confirm the connected account or service identity in one short sentence. A service connection is not its creator's personal account.
Reuse the Space already established in the conversation. An ordinary publish does not need a Space chooser.

## Host features when needed

Use these only when the task needs them and the host or connected server advertises them:

- The Space Library and mention picker can help the user select a Space.
- If `choose_space` is available, use it when a choice is needed. Honor cancellation.
- Plugin settings, HTML previews, and event subscriptions depend on host support.
  Do not promise these features merely because this skill describes them.

A selected Space supplies context. It does not authorize a write by itself.

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

View saved version →

---
name: share-space
description: "Change who can access a Spacefast Space or path. Use to make it public, keep it private, invite specific people, or create or revoke a share link. Publishing content is a separate task."
---

# Share with the right people

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Resolve the Space and the requested audience. Preserve access outside that request.
2. Read **Manage access** in [references.md](references.md). Read current access before changing it.
3. Apply the narrowest access change that meets the request. Verify the intended actor and path.
4. For a share link, verify the intended visitor experience and report its scope and expiry.

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

View saved version →

---
name: show-and-tell
description: "Submit a public Space to Show & Tell, read feedback, withdraw an entry, or browse approved work."
---

# Share work in Show & Tell

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Read **Show & Tell** in [references.md](references.md). Follow its customer workflow and check the result.

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

View saved version →

---
name: spacefast
description: "Publish an existing website, app, report, or other artifact to Spacefast and verify its live link. Also use to read or manage team Memories and inspect team Skills. For changes to an existing Space's content or design, use edit-space."
---

# Publish your work

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. For a team Memories or Skills request, resolve the team and optional Space. Read Team Memories and Skills in references.md and perform only the requested context work. Publish only when the user also requests it.
2. Use the artifact the user wants to publish. Keep its intended destination and access settings.
3. Before creating or editing, read **Team Memories and Skills** in [references.md](references.md). Read the full context before preparing changes and apply relevant saved practices within the task.
4. Before publishing or deploying new or changed source, run the verify-design-system skill against current saved standards and the exact source/build being deployed. Inspect affected pages and states at desktop and mobile widths, and report gaps. Reuse verification only while the source/build and design revision are unchanged. Report missing standards as unavailable, not a pass. Verify before a source-workspace commit when autoDeploy is enabled. Follow the user's existing publication intent and approval rules.
5. Read **Publish** in [references.md](references.md). It covers this host's publish route, receipt, and verification.
6. Do not rebuild an existing Space from its served files. For a file or design change, follow the source workflow instead.
7. Return the live link and version link from the result. State whether the version is live or only ready.
8. For a requested preview, redirect, or GitHub workflow, read the matching section in [references.md](references.md).

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

View saved version →

---
name: update-design
description: "Bring a named existing Spacefast Space or linked project into alignment with the team's current saved design system. Update affected source and assets, verify the result, and follow the request's deployment intent."
---

# Update an existing design

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Resolve only the requested existing Space and its source revision. Read Team Memories and Skills, Design system, and Source edits in references.md.
2. Compare the source with the team's current saved standards. Change only the requested scope and preserve independent user choices.
3. Before publishing or deploying new or changed source, run the verify-design-system skill against current saved standards and the exact source/build being deployed. Inspect affected pages and states at desktop and mobile widths, and report gaps. Reuse verification only while the source/build and design revision are unchanged. Report missing standards as unavailable, not a pass. Verify before a source-workspace commit when autoDeploy is enabled. Follow the user's existing publication intent and approval rules.
4. Verify each named Space separately. Report saved source, preview, and live deployment as separate states.

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

View saved version →

---
name: verify-design-system
description: "Check a Spacefast source build or preview against its saved team design system, including visual and editorial results. Report deviations and fix them when the task includes corrections."
---

# Verify design application

Use the connected Spacefast MCP tools. Sign-in is required. If the connection is unavailable, ask the user to reconnect in plugin settings.

If a task requires an existing Space and its identity is unclear, call `choose_space`. Use the selected Space as the target. A selection does not approve publishing or other changes.

Read the MCP calls, approval, and work mode rules in [references.md](references.md) before a management operation.

1. Resolve the team and Space, then identify the exact complete source revision and matching built preview or version. Read Design system and Source edits in references.md.
2. Read Team Memories and Skills in references.md. Retrieve current standards, applicable memories, enabled team skills, and assets. Identify a stale `design.md` or preview before judging compliance; do not treat a missing standard as a pass.
3. Inspect affected pages, components, states, assets, and copy at representative desktop and mobile widths. Tie each finding to the saved rule, implementation location, and rendered evidence.
4. For a request that includes corrections, change authorized source, rebuild, and repeat affected visual checks. For review-only work, report findings without editing.
5. Report versions, areas checked, fixes and retests, unresolved gaps, and decisions. Verification does not authorize publication.

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