operate git:20260609.02fc9ebA

Immutable. This exact content is served forever at /api/v1/blob/b41d5002c1c4ebfc.

---
name: operate
description: Operate a client's WordPress site brand-first and governed — the core loop every marketing/website agent runs on connect. Onboard, read the brand book, then build/edit on-brand with approval-first safety. Use the moment you connect to any mumcp site to do real work.
user-invocable: true
---

# Operate a WordPress Site (brand-first, governed)

This is the **operating loop** — the agent-half of a deployable site. Reference skills tell you
*what tools exist* (`/mumcp:tools`, `/mumcp:elementor`, `/mumcp:design`). This skill tells you *how to
behave* when you take over a live client site: read the brand before you touch anything, conform to it,
and never mutate production without a gate. Proven on real client sites (digid.ca, crophelp.ai).

> The brand book is the constraint that turns AI from a slop-generator into an on-brand operator.
> Read it first, every time. Everything you produce conforms to it or it does not ship.

## The loop (run in order, every session)

### 1. Onboard — know the site before you act
Call **`wp_onboard`** first, always. One call returns: site identity, content inventory, active
integrations, the full tool surface by category, the embedded site context, and recommended first
actions. Never start work from assumptions — start from the briefing.

If anything is unclear after onboard, call `wp_site_info`, `wp_detect_plugins`, `wp_get_site_state`.

### 2. Read the brand book — the central context
Call **`wp_get_site_context`**. This is the site's master style guide / system context — the
**brand crystal**. It defines: brand identity (name, tagline, mission, voice), color palette (CSS vars +
hex, dark/light themes), typography scale, spacing rhythm, navigation, page structure, and design rules.

- **Everything you generate conforms to this.** Colors, type sizes, spacing, section patterns, voice.
  Off-brand output does not ship — that is the whole product.
- The response includes `effective_context` and an `inheritance` block (`scope`, `archetype_class`,
  `style`, `matched`). When a site inherits from a base context (a snapshot/blueprint), `effective_context`
  is what actually applies — honor it.
- **New client with no context yet?** Establish it first with **`wp_set_site_context`** (markdown:
  identity → palette → type → spacing → nav → page structure → design rules), get it approved by the
  human, *then* build. A site with no brand book is the first thing to fix, not skip.

### 3. Read state + pick the governed path
- **`wp_get_site_state`** — content, graph, SEO, approvals, events, capabilities, recommended actions.
- **`wp_get_agent_playbook`** (no arg) lists deterministic contracts; call with a name for the full
  contract (required reads, tool order, validation gates, approval gates, rollback path, stop conditions).
  Current playbooks: `build_gutenberg_page`, `update_gutenberg_section`, `seo_audit_triage`,
  `internal_link_improvement`, `rollback_change`. **Follow the matching playbook** rather than improvising.

### 4. Do the work — brand-first
- Build/edit pages, posts, menus, media, SEO — each conforming to the brand book from step 2.
- Elementor work: read `/mumcp:elementor` first; always `wp_get_elementor_summary` before editing;
  prefer surgical tools (`wp_edit_section`, `wp_edit_widget`, `wp_patch_elementor`) over full-page rewrites.
- Use the brand palette/type/spacing values literally — do not invent new colors or sizes.
- Generate on-brand copy in the brand voice; use `wp_keyword_research` to ground content in real search demand.

### 5. Govern every mutation
- **Approval-first.** Production-facing changes go through the approval lifecycle
  (`wp_list_approvals` → `wp_approve_request` → `wp_apply_approval`), never a silent direct write,
  unless a playbook is explicitly marked read-only or the human pre-authorized the specific change.
- **Validate before publish:** `wp_validate_seo_readiness`, `wp_validate_blocks` / Elementor warnings.
- **Rollback on regret:** every applied change stores a rollback payload — `wp_rollback_approval`.
- **Coherence check:** `wp_get_content_coherence_report` / `wp_get_signals` to confirm the brand crystal
  still holds after a batch of work.

## Hard rules (never)
- Never push raw HTML/JS as a shortcut into Gutenberg or as page content. Use native blocks / Elementor data.
- Never invent facts, citations, products, prices, or SEO claims. Ground everything in real site data.
- Never introduce a color, font, or spacing value that is not in the brand book.
- Never mutate production without an approval gate (unless read-only playbook or explicit human OK).
- Customer-facing sends (email, social, publish-live) go through the human gate — propose, don't broadcast.

## Stop conditions
Stop and ask the human when: the brand book is missing or contradicts the request; a change is
destructive with no rollback; an approval is required but absent; the task needs a fact you cannot verify
on the site; or a playbook's stop condition triggers.

## Why this is the snapshot's agent-half
A deployable site snapshot = **this operating skill (the agent's behavior) + the site's brand book +
blueprint (the WordPress structure)**. Author a client's brand book into `wp_set_site_context`, capture
their structure as a blueprint, and this skill is the squad's reusable playbook for running it. One skill,
every client site. That is how one proven build (digid.ca) becomes a repeatable product.

## Reference skills (load as needed)
`/mumcp:tools` (discover tools) · `/mumcp:elementor` (page building) · `/mumcp:design` (design
principles) · `/mumcp:status` (site/plugin health) · `/mumcp:connect` (wiring a client).