Your website.
Your guide to what’s next.

01. Project & timing

The project at a glance

Prepared by Joi Whitmore at Glass Fish Design for Kasandra Murray. This guide explains the sequence behind your Astro homepage and component playground, the approximate effort involved, and how you can use an AI coding assistant to make future changes without writing every line yourself.

The result

We created a working homepage concept using your existing content, brand palette, typography, and portfolio artwork. Creative services lead, fractional marketing and operations follow, and reusable dividers and animations give you room to experiment. GitHub stores the source; Cloudflare publishes the preview after a successful build.

Approximate effort

These are planning estimates for the first concept, based on the workflow below, rather than a recorded timesheet. Allow roughly 2–3 hours for the core sequence, plus up to an hour for the playground and about 30 minutes for an AI-assisted SEO audit and update. Account approvals, waiting time, asset preparation, and additional revision rounds can add time.

The scope is a homepage concept and playground, not a complete Squarespace migration. Remaining pages, final copy and logo decisions, form handling, client account handoff, and the production domain launch are separate stages.

Open the project

Joi has added you to the GitHub repository below. The build sequence explains how to fork the files when you’re ready for the handoff.

Homepage preview

Component playground

GitHub repository: https://github.com/GlassFishDesign/unlucky-umbrella

The website uses free tools and hosting plans. AI access depends on the assistant you choose; this guide assumes no new paid AI subscription.

02. The build sequence

The build sequence

Step 1: Set up GitHub and access

Joi created GlassFishDesign/unlucky-umbrella on GitHub and has added you to the repository. Sign in with the invited account and accept the invitation if prompted. When you’re ready, coordinate with Joi to enable forking, then use Fork to copy the files into your personal GitHub account. Forking is currently disabled. Connecting your copy to your Cloudflare account is a separate handoff step.

If using AI, open a local copy of the repository in a coding assistant, or authorize its GitHub connection for this repository. A local assistant can edit files in the project folder; a GitHub-connected assistant needs write or pull-request capability to propose actual changes. Keep private invoices and unrelated client material outside the website repository.

Step 2: Connect Cloudflare to GitHub

Create the preview project on the free plan and allow Cloudflare to access the repository. Connect the main branch and configure the build and deployment commands. Complete sign-in and permission decisions yourself when required. This project started in Joi’s Cloudflare account; moving it to your account will be a later handoff.

Our setup uses Astro with Cloudflare Workers Static Assets. The build command is npm run verify; the deployment command is npx wrangler deploy --config wrangler.json. The preview lives at a workers.dev address, while the current Squarespace domain remains in place.

Step 3: Supply the assets and direct the build

Provide the current site, licensed logos and images, brand colors, fonts, and service priorities. Ask for a discovery brief and component specification, then an original homepage concept. We specified Astro, creative services first, fractional services close behind, reusable shape dividers and animations, and free tools only.

The AI handled the initial page code, image optimization, reusable components, and build checks. The prompts in the next section show the actual direction used in this project.

Regular business pages now use src/layouts/SiteLayout.astro to share the header, navigation, main content area, footer, and motion switch. Edit shared navigation in SiteHeader.astro and footer details in SiteFooter.astro. Place page sections inside SiteLayout without adding another main element. The wrap and section-pad classes in src/styles/site.css supply responsive width and spacing. The README and docs/editing-guide.md contain examples. The playground and this guide keep their own tool layouts.

Step 4: Review and refine

Review the real browser preview on desktop and phone. Check the voice, hierarchy, images, links, motion, and what the visitor should do next. Give one focused change at a time, then compare the updated preview. Our checks covered layout, navigation, existing-site links, copy controls, and motion behavior.

Step 5: Publish and verify

Run the project checks, save the approved changes in a commit, and push to main. Cloudflare then builds and publishes automatically. Check that the build succeeded and open the deployed preview before sharing it. A failed build needs investigation; a push alone is not confirmation that the update is live.

Cloudflare documentation on automatic builds

Add on Create a component playground

We added a page for trying divider shapes, colors, height, mirroring, and animation timing. It generates matching Astro examples to copy. The same components power both the playground and homepage. Playground selections are experiments; they do not automatically edit the homepage.

03. Prompts we used

Selected prompts used in this project

These are Joi’s project messages, quoted directly. The discovery request is a labeled excerpt. The short build request worked because the conversation already contained the branding, discovery work, service priorities, Astro decision, and hosting constraints.

Start with discovery

Exact excerpt from the discovery request

Clarify the framework and budget

Connect the repository

After repository access was granted

Build the creative homepage

Add the playground

Carry the context into a new chat

When starting fresh, give the assistant the repository and current preview, then ask it to read README.md and docs/editing-guide.md. State the desired change and the free-only requirement again. The reusable prompts later in this guide include that context explicitly.

04. Make changes with AI

Make future changes with AI and GitHub

You can describe the result you want in plain language and let an AI coding assistant make the file edits. Your job is to supply the intent, review the result, and decide when it is ready to publish. GitHub keeps the changes reviewable and records their history.

1. Open the right project

Use a coding assistant that can work with repository files. Open or clone GlassFishDesign/unlucky-umbrella, or select it through the assistant’s GitHub connection. Sign in through the tool’s normal flow and authorize the project access you intend. Ask the assistant to read the README and editing guide before changing anything.

2. Describe one concrete change

Name the page or section, what should change, and what should stay the same. Supply the replacement text or approved asset when possible. A request such as “change the selected-work divider to a 56-pixel wave in lavender” is easier to review than “make it more creative.” You can copy settings from the playground into your request.

3. Ask for a reviewable version

For a small solo edit, ask the assistant to make local changes and stop before pushing. For a change you want Joi to review, ask it to create a separate branch and open a draft pull request. A branch holds the proposed version; a pull request gathers the description and changed files for review before merging into main.

GitHub documentation on pull requests

4. Review the preview and the change summary

Ask the assistant to start the local preview, test a phone-sized layout, run npm run verify, and explain the files changed. Review the visual result and confirm the request was followed. You can ask for another adjustment in the same conversation. You do not have to type the implementation yourself.

5. Approve publication when ready

For the local workflow, tell the assistant to commit and push the approved changes to main. For the pull-request workflow, review and merge the branch into main. In this project, updates to main trigger Cloudflare deployment. Optional branch preview builds are disabled, so a pull request alone does not produce a new Cloudflare preview URL.

6. Verify the live result and keep a recovery path

Ask the assistant to confirm the Cloudflare build passed and check the deployed page. If a published change causes a problem, ask it to revert the relevant commit and publish the correction. A revert creates a new change that undoes the earlier one while preserving the project history.

A useful starting request

05. Prompts to reuse

Reusable prompts for future edits

These are new templates for your future use, not quotations from the original build. Replace the bracketed text, then send the prompt to the coding assistant working with your repository.

Change wording or an image

Apply a divider or animation from the playground

Request a design revision

Ask Joi to review a larger change

Publish an approved change

If the work is already in a pull request, replace the first sentence after approval with “Merge the approved pull request into main.”

Fix an issue or undo an update

The editing guide in docs/editing-guide.md explains where content, styles, dividers, and animations live. You can ask the assistant to use that guide instead of locating each file yourself.

06. Page speed & SEO

Page speed and SEO

SEO audit and update — about 30 minutes with AI help

A focused SEO pass checks the homepage title and description, heading structure, image descriptions, links, sharing metadata, structured business information, and indexing settings. This is an estimate for the homepage audit and updates, not a complete migration or an ongoing SEO campaign.

Our mobile PageSpeed result

The October 28, 2026 report at 4:04 PM EDT scored the homepage 100 for Performance, 100 for Accessibility, 100 for Best Practices, and 66 for SEO. Largest Contentful Paint was 1.7 seconds and Total Blocking Time was 0 milliseconds. This is one simulated mobile test of the earlier homepage version, not a guarantee of future scores or real-user results.

Open the original mobile PageSpeed report

Why the preview SEO score is lower

The report’s failed SEO check is “Page is blocked from indexing.” That is intentional for this unfinished preview. We retain noindex in the page and response headers. Crawlers can now read those rules through robots.txt. The preview remains excluded from search; it is still publicly accessible to people with the link.

What we improved

We clarified the homepage title around branding, graphic design, and Ohio; refined its search description while keeping fractional services visible; added social sharing titles, descriptions, and a portfolio image; and added Organization structured data using the public business details already on the page. These changes use static HTML and add no paid SEO plugin or extra browser JavaScript.

What happens at production launch

Once the replacement site and domain launch are approved, set the final canonical URLs and sharing URLs, create a sitemap for the finished public pages, map old Squarespace URLs to their replacements with redirects where needed, and remove noindex only from the production pages intended for search. Keep the guide, playground, and preview excluded. Verify the final site in Google Search Console, submit its sitemap, and rerun PageSpeed and structured-data checks. Search rankings and rich results are not guaranteed by an audit score.

Google guidance on noindex

Google guidance on Organization structured data

Copy a prompt for the next SEO review