Skills, harnesses and hooks

# Change copy or layout
Type: Skill
Purpose: Turns a plain-English request into a reviewed, previewed change that waits for approval.
When: Someone asks for a change to a page, in their own words.
Inputs: The request, the site's content rules and its component library.

Steps:
1. Find every place the change shows up.
2. Ask first if the request is ambiguous or touches a fact, client, figure or design decision.
3. Draft it to the content rules, reusing existing components and tokens.
4. Show the current and proposed wording side by side.
5. Make the change on its own branch and render phone and desktop previews.
6. Open a review page, then stop and wait.

Outputs: A review page with a wording table and previews. Nothing live.

Guardrails:
- Never publishes.
- Never invents a new style when a component already exists.

# Publish-ready blog post from a draft
Type: Skill
Purpose: Turns a draft into one post file, its artwork and a review page.
When: A new draft is ready to go on the blog.
Inputs: The draft, the voice and content rules, the artwork rules.

Steps:
1. Gather the title, short title, address, date, summary, topics and read time, asking for anything missing.
2. Review the copy for voice, spelling, accuracy and banned characters before building anything.
3. Create the post file from the template.
4. Draw the post's artwork around its actual idea, using only words and figures from the post.
5. Preview the post, the blog page and the homepage list, and run the page check.
6. Open a review page, then stop and wait.

Outputs: One post file, its artwork, previews and a review page. Nothing live.

Guardrails:
- Never publishes.
- Flags any newly named client, figure or outcome for confirmation first.

# Preview at phone and desktop size
Type: Skill
Purpose: Shows exactly how a page or section looks, before or after it goes live.
When: Anyone asks to see how something looks.
Inputs: The page, an optional section, and whether to show the draft or the live site.

Steps:
1. Work out the page and section from plain words.
2. Run the site preview harness at 390px and 1280px.
3. Send the screenshots, phone first, saying whether they show the draft or the live site.
4. Explain any warning in plain language.

Outputs: Phone and desktop screenshots.

Guardrails:
- Changes nothing.

# Publish with a human gate
Type: Skill
Purpose: Puts one approved change live, then proves it on the live site.
When: Only when the owner has explicitly approved this exact change.
Inputs: The approved review page.

Steps:
1. Confirm the approval was for this exact change, after seeing its wording and previews.
2. Check what is about to ship: only the approved change, protected files untouched, no banned characters.
3. Merge it as one change, so it can be undone in one step.
4. Wait for the deployment to finish.
5. Run the live health check and preview the changed page on the live site.
6. Report what went live and how to undo it.

Outputs: The change live, verified, with a one-tap way to undo it.

Guardrails:
- Never runs on assumed approval. Only a person can start it.
- Stops if anything unrelated is mixed in.

# Site health report
Type: Skill
Purpose: Runs the live health check and explains the result in plain language.
When: After every publish, or whenever someone asks if the site is OK.
Inputs: The live site.

Steps:
1. Run the live health check harness.
2. Lead with the outcome: all good, or how many problems.
3. Explain each problem in one sentence: what it means for visitors and what to do.

Outputs: A plain-language health report.

Guardrails:
- Changes nothing without approval.

# Site preview harness
Type: Harness
Purpose: Builds the site exactly as the host does, then screenshots it at phone and desktop size.
When: Every draft, before a review page opens.
Inputs: The working copy, or the live site.

Steps:
1. Build the site with the host's own builder and settings.
2. Serve it locally with the same clean addresses as the live site.
3. Open each page at 390px and 1280px with motion reduced and the real font.
4. Warn if the font is missing or the wrong page is showing.

Outputs: Screenshots, plus warnings.

Guardrails:
- The build matches what the host publishes, byte for byte.

# Page check
Type: Harness
Purpose: Follows every link on the site and checks each page works.
When: Before any structural change ships, and inside the live health check.
Inputs: The working copy or the live site.

Steps:
1. Start at the homepage and follow every internal link.
2. On each page, check the right page shows, every image loads and no script errors.
3. Check the link preview tags are present and point at the page's own address.
4. Check every in-page link has a target, old addresses redirect, and missing pages show the not-found page.
5. Fail on any banned character.

Outputs: A pass or fail line for every page and link.

Guardrails:
- Read-only.

# Navigation map
Type: Harness
Purpose: Maps every page of the site and its design system as one space, checks how people find their way, and spots pages growing too long.
When: The first step of every navigation sweep, and on any change to menus, footers or page structure.
Inputs: Both sites: working copies or the live sites.

Steps:
1. Crawl both sites from both front doors and the sitemap, at 390px and 1280px.
2. On each page, record every link: where it sits (menu, trail, page, footer), its words, where it goes, whether it shows and how big it is to tap.
3. Ask three questions of every page: where am I, where can I go, how do I get back.
4. Fail on broken links, in-page links with no target, and pages with no way home.
5. Warn on missing current-page markers, dead ends, orphan pages, address mismatches, vague labels and small tap targets.
6. Count the links between the two sites, and the taps from each page to the main pages.
7. Measure each page's length in phone screens and sections, count menu links that jump within it, and read its history to forecast its growth.
8. Flag a long reference page, or one growing towards that, to become sub-pages with a menu.

Outputs: A pass, warn or fail line for every check, a page-by-page map with each page's length and growth forecast, and screenshots of every page's top and end.

Guardrails:
- Read-only.
- Warnings are evidence for a review, not changes to make.

# Live health check
Type: Harness
Purpose: Proves the live site is up, safe and exactly what was approved.
When: After every publish.
Inputs: The live site and the approved code.

Steps:
1. Check the domain, the www redirect and HTTPS.
2. Check the link preview tags and image.
3. Check private project files are not public.
4. Rebuild the approved code and compare every published file with the live site, byte for byte.
5. Check the domain file is intact, and that the site is still in step with its design system.
6. Run the page check.

Outputs: Pass, fail and warning lines, with a summary.

Guardrails:
- Read-only. A difference is reported, never fixed silently.

# Before-and-after proof
Type: Harness
Purpose: Proves a change didn't move a single pixel it wasn't meant to.
When: Any change meant to leave the look unchanged, such as a restructure.
Inputs: The live version and the draft.

Steps:
1. Build both versions.
2. Screenshot every page of each, full length, at phone and desktop size.
3. Compare them pixel by pixel.
4. Save a red difference image for anything that changed.

Outputs: Same or different for every page, with difference images.

Guardrails:
- The result is quoted on the review page.

# Drift check
Type: Harness
Purpose: Says when the design system and the site it describes part ways, from either side.
When: At the end of every design system preview, after every site publish, and on any change before it merges.
Inputs: The site's stylesheet, the design system's published tokens, and the site's artwork files.

Steps:
1. Read what the other side publishes: the site's live stylesheet, or the design system's tokens file.
2. Compare every colour, card art and layout token on both sides.
3. Report Drift for any token that differs or exists on only one side.
4. Report Info for colours used but not yet tokens.
5. Say what to do: ask the owner which side is right, then update the other side through its own review page.

Outputs: Drift and Info lines, in step or not, and the next step.

Guardrails:
- Drift blocks publishing until the owner decides which side is right.
- Info is a to-do list, not a blocker.
- Each side changes only its own repo.

# Playground
Type: Harness
Purpose: A live, hands-on harness for the design system's theming.
When: Whenever someone wants to see what the system can do, or test a theme.
Inputs: Accent and partner colours, light or dark, roundness and glass blur.

Steps:
1. Show every component, rendered by the kit alone, in a frame.
2. Send each setting to the frame as it changes.
3. Write out the chosen settings, ready to paste into another page.

Outputs: A themed preview and a copyable theme.

Guardrails:
- Changes nothing outside the frame.

# End-of-turn save check
Type: Hook
Purpose: Stops an agent finishing with work left unsaved.
When: Every time an agent is about to end its turn.
Inputs: The agent's working copy.

Steps:
1. Look for changes not yet saved, or saved but not yet sent to the shared repo.
2. If any are found, tell the agent to send them before finishing.

Outputs: Nothing when all is saved. A prompt to push when it isn't.

Guardrails:
- It steps aside if it has already prompted once, so it can't loop.

# Agent launch gate
Type: Hook
Purpose: Holds every agent run until the owner approves it.
When: Any time an agent is about to start.
Inputs: The agent that is about to run, and what it was asked to do.

Steps:
1. Stop before the agent starts.
2. Show the owner which agent is about to run.
3. Start it only if the owner approves. Otherwise nothing runs.

Outputs: An agent run the owner chose, or no run at all.

Guardrails:
- Agents never start by themselves, on a schedule, or because another agent suggested it.
- Suggesting a run is fine. Starting one is the owner's call.

# One-line plug-in
Type: Hook
Purpose: The point where any page hooks into the design system.
When: A new page or prototype needs the look.
Inputs: Any page that takes HTML.

Steps:
1. Add one stylesheet line for the look.
2. Optionally add one script line for interactive controls.
3. Optionally paste a theme from the playground.

Outputs: The page picks up the tokens and components, and follows future non-breaking updates.

Guardrails:
- Use the versioned address, so a breaking change never arrives unannounced.

# Control change event
Type: Hook
Purpose: Lets any page react when someone picks an option.
When: Someone taps an option in a segmented control.
Inputs: A segmented control on a page using the kit's script.

Steps:
1. Press the chosen option and slide the glass highlight under it.
2. Announce the choice as an event any script on the page can listen for.

Outputs: A gc:change event carrying the chosen value.

Guardrails:
- Only fires on a person's choice.

# Human-gated change
Type: Workflow
Purpose: Every change to either site, from request to verified live.
When: Any change, big or small.
Inputs: A request in plain English.

Steps:
1. Draft it with a skill, on its own branch.
2. Prove it with harnesses: previews, the page check, and the before-and-after proof where the look shouldn't change.
3. Open a review page with the wording side by side.
4. Wait for a person to approve that exact change.
5. Publish it, then run the live health check.

Outputs: One reviewed, verified change that can be undone in one step.

Guardrails:
- Approval for one change never carries over to the next.
- One change per review page.

# Site-to-system sync
Type: Workflow
Purpose: Keeps the design system following the site, before changes ship.
When: A change to the site touches colour, components or artwork.
Inputs: The site's open review page.

Steps:
1. Run the drift check on the site's change before it merges. Either side can run it.
2. Pass any findings to the session that owns the site change.
3. That session fixes them, shows the person, and publishes once approved.
4. The design system takes the final values and rules, and publishes once approved.
5. After each publish, the drift check runs again from that side to confirm everything is in step.

Outputs: Both sites in step, each with its own approved change.

Guardrails:
- Each session changes only its own repo.

# Parallel agent sessions
Type: Workflow
Purpose: Two agents on two repos, coordinating without stepping on each other.
When: Work spans more than one repo, or runs at the same time.
Inputs: One agent session per repo, each with its own task.

Steps:
1. Give each session one repo and one change at a time.
2. Pass decisions and findings between sessions as messages.
3. Have the receiving session treat a message as information to act on through its own review page.
4. Have each session publish only with the person's approval.

Outputs: Coordinated changes across repos, each reviewed on its own.

Guardrails:
- A message from another session is never an approval.
- No session writes to a repo it doesn't own.

# Navigation sweep
Type: Workflow
Purpose: Strengthens how people move through the site and its design system, within each and between them.
When: Only when the owner asks. After a new page or section ships, an agent may suggest a run, but never starts one.
Inputs: Both sites, the navigation standard and the decision log.

Steps:
1. Map both sites with the navigation map.
2. Walk the key journeys at phone size first, including looking one thing up, and score each finding against usability heuristics, with a severity.
3. Look ahead as well as at today: a page that is long and growing gets a proposed structure of sub-pages before it becomes hard to use.
4. List the small clean-up fixes, each with the repo it belongs to.
5. Check the decision log, then draft proposals such as breadcrumbs, footer site maps and cross-site links in a throwaway copy.
6. Show each proposal as current and proposed, at phone and desktop size, with the decisions needed.
7. Stop. Each approved item becomes its own human-gated change, and new components then follow into the design system.

Outputs: A map, a prioritised review, previews of each proposal, and a list of decisions for the owner.

Guardrails:
- Changes nothing on either site by itself.
- Runs only when the owner starts it, and every launch waits for their approval.
- A proposal that reverses a logged decision is a question for the owner, not a draft.
- One change per review page.