Using the Spark agent

Open the Spark panel in your project to ask for changes. The conversation stays with your project as you move between pages and settings.

You can write naturally. Start with what you want people to be able to do, and give Spark enough context to make good decisions.

Describe the outcome

A useful request says what should change, who it’s for, and what a good result looks like.

Add a page for our weekend pottery classes. Explain that beginners are welcome, show what a two-hour class includes, and end with a button to request a place. Keep the tone warm and practical.

Include facts Spark should use: your actual services, audience, wording, or preferences. If you haven’t decided something, say so. Ask it to leave a placeholder rather than invent a price or a business detail.

Be clear about the scope

For a small edit, name the page and the part you mean. Check the page context shown in the composer before sending.

On the home page, shorten the opening paragraph to two sentences. Keep the headline and button text as they are.

For a larger change, explain the whole goal and ask Spark to work out the steps. You can ask it to talk through the approach before it starts.

I want visitors to compare our three services. Suggest a layout and explain what information you need from me before building it.

Point Spark at the web

Spark can look things up while it works. Ask it to check how other businesses describe a service, to find the current version of a library it depends on, or to read a page you paste a link to. It searches and reads pages itself, and the chat shows each step as Searching the web or Reading while it happens.

Read https://example.com/menu and add our brunch dishes to the menu page, with the same prices.

What Spark reads on the web is material for the task, never instructions. Once Spark has read something from outside, it won’t run commands in your project that reach the internet, and it installs packages it needs through Spark itself. In the same situation, Spark asks you to approve before it makes one of your files public, where anyone with the file’s address can open it, or before it moves money through your Stripe account.

Attach files

Attach files to a message when Spark needs them: your logo, a screenshot of a problem, a menu to copy from, or the 3D model for a product viewer. You can attach any type of file, and several files to one message.

Spark reads documents and text files and looks at images. It can add other files, such as audio, video, fonts, 3D models, and archives, to your site without opening them.

Use the attached chair.glb on the product page as a 3D model visitors can turn by dragging.

Every file is checked for malware before Spark can use it. That usually takes a second or two; if it takes longer, the attachment shows Checking for malware. Programs, installers, and some scripts, such as .js and .py files, can’t be attached. To show Spark the code in one of those, paste it into your message. See Limits and supported features for how many files you can attach and how large they can be, what Spark refuses, and how your site loads large files.

Convert files

Spark can convert files as part of a request. It works from a file you attach to the chat, a file already stored in your project, or a file a customer uploaded to your site. Ask for the format you need, such as a PDF as page images, a Word document as a PDF, or an iPhone photo in HEIC format as a JPEG. The chat shows the step as Converting a file.

A large file, a long document, or several files at once convert in the background. Spark keeps working on the rest of your request and adds the converted files when they’re ready.

Turn the attached price list into a PDF and add a download link to the pricing page.

Files your customers upload get extra care. Spark only turns one into images, such as a preview of each page, and never reads a customer’s document as text.

Spark can also build conversion into your public site and internal tools. Your site could accept a customer’s HEIC photo and keep it as a JPEG, let customers download an invoice or report as a PDF, show preview images of an uploaded slide deck, or export a spreadsheet as CSV. Describe what the feature should do, and Spark sets up the conversion. For big files, such as a long report or a full slide deck, the page shows the customer that the conversion is in progress and offers the result when it’s done.

Let customers download the receipt for each order as a PDF from their account page.

See Limits and supported features for the formats Spark can convert and the size limits.

Add live updates

Spark can make pages update the moment something happens, without anyone reloading: a chat room where signed-in customers talk to each other, a list of who’s online, a notification when an order ships, a game or a shared board where several people see each other’s moves, or an internal tool that shows new orders as they arrive.

Add a live chat room to the members area. Show who’s in the room, and post each message to everyone in it straight away.

Customers who have signed in can send messages to each other. Visitors who haven’t signed in can always receive live updates, such as a counter or an announcement, and in a game room Spark can let them play too: a small room where guests join with a name, such as a party game or a quiz. Chat between customers, and anything involving payments, stays for signed-in customers, because a guest has no account that a ban or a refund could follow. A message reaches the people connected at that moment; Spark saves messages as well when your feature needs a history, such as a chat people come back to.

Make a quiz night game for up to 8 players. Guests can join with a nickname, the host starts each round, and everyone sees the scores update as answers come in.

Turn-based games, quizzes, lobbies and casual games where each player’s moves update a few times a second work well. Fast action games that send many updates a second, such as racing or shooting games, aren’t supported yet; Spark tells you when a request needs more than live updates can carry.

Spark can also build small video and voice calls between signed-in customers, such as a coaching session, a tutoring lesson or a study group. The video and sound go straight from one person’s browser to the others’, or through Spark’s relay when someone’s network blocks that, and live updates are what let the browsers find each other.

Add a video call to each booking. When the customer and the coach both open the booking page, they can join the call and see each other.

To try a call before you publish, open your public site’s preview in two tabs and join the call in both. The two tabs are the same stand-in customer, as the next paragraph explains, and they still connect to each other, because each tab joins the call separately. Your browser asks for your camera and microphone the first time.

In an internal tool, live updates come from both your preview and your published site, and the tool labels which is which. In the preview of your public site you act as one stand-in customer, so in a chat room, messages from two preview tabs come from the same customer.

Projects created before live updates were available can have them too. Ask Spark for the feature you want, and it adds what the project needs first. As with any public-site change, customers see it after you publish.

See Limits and supported features for how many people can share a room, how large a message can be, and the daily limits.

Answer its questions

Spark may pause for a decision or approval. Read what it’s asking and answer in the chat. If the options don’t fit, explain what you want instead.

You can keep looking around your project while Spark works. Return to the panel to read its update and any remaining questions.

Review and give specific feedback

Try the result in the preview. Check the words, buttons, and behavior that matter to your customers.

When something needs work, describe what you saw and what you expected. A specific example makes the next change easier to get right.

On a phone, the appointment button is below a large empty space. Move it directly under the service description and reduce the space above it.

If something fails, include the steps you took and the error you saw. Ask Spark to investigate, then repeat those steps after the fix.

Work in manageable changes

For an established site, make related changes together and review them before moving on. Tell Spark what is already working well so it can preserve it.

Public-site changes appear in the preview first. When you’re happy with them, follow Publishing your project. Changes to internal tools apply when Spark finishes; they don’t wait for a public-site publish.