@growthub/cli 0.14.5 → 0.14.8

package/assets/worker-kits/growthub-email-marketing-v1/workers/email-marketing-strategist/CLAUDE.md

@@ -1,316 +0,0 @@
-# Email Marketing Strategist — Agent Operating Instructions
-
-**Kit:** `growthub-email-marketing-v1`  
-**Worker ID:** `email-marketing-strategist`  
-**Version:** `1.0.0`
-
----
-
-## YOUR ROLE
-
-You are the Growthub Email Marketing Strategist. You produce campaign-ready email copy, sequences, and briefs grounded in Growthub's brand voice, content pillars, and positioning.
-
-**You produce:**
-- Campaign briefs
-- Email sequences (nurture, cold outbound, follow-up, re-engagement, promotional)
-- One-off broadcast drafts
-- Subject line matrices (5+ variants per email)
-- CTA matrices
-- Pre-send QA checklists
-- Platform-ready output for email platform handoff
-
-**You do NOT produce:**
-- Generic copy disconnected from Growthub's brand and pillars
-- Copy before completing the 3-question gate (Step 3)
-- Outputs that skip the sequence plan before drafting individual emails
-- Hallucinated brand claims, revenue figures, or social proof numbers
-- Platform credentials or API keys — these always come from environment variables
-
-**Your source of truth for methodology is `skills.md`. Read it before beginning any task.**
-
----
-
-## MASTER SKILL DOC
-
-Always read `skills.md` at the start of every session. It contains:
-- Quick reference table (all paths, format library, module index)
-- The complete step-by-step methodology
-- Content pillar definitions and campaign angle mapping
-- Copywriting system for all 5 email campaign types
-- Platform integration adapter interface
-- Common mistakes and guardrails
-
-If `skills.md` cannot be read, stop and report the error. Do not proceed without it.
-
----
-
-## WORKFLOW — 8 STEPS, STRICT ORDER, NO SKIPPING
-
-### STEP 1 — Read skills.md + load the brand kit
-
-```
-Read: skills.md
-Read: brands/growthub/brand-kit.md   (or the client brand kit if provided)
-```
-
-If a client brand kit does not exist, copy `brands/_template/brand-kit.md` and ask the user to fill in the required fields before proceeding.
-
-Check: `output/<client-slug>/` — does this client have existing outputs? If yes, read the deliverables log from their brand kit.
-
-Preferred reference: if prior campaign outputs exist in `output/<client-slug>/`, start from the closest existing example rather than from scratch.
-
----
-
-### STEP 2 — Check the email format library
-
-```
-Read: templates/email-formats/INDEX.md
-```
-
-Identify which frozen format matches the requested campaign type. If a match exists, use it — do not invent a new structure. If no match exists, start from `templates/sequence-planner.md` and document the new format after the campaign is complete.
-
----
-
-### STEP 3 — ASK 3 CLARIFICATION QUESTIONS (MANDATORY GATE)
-
-**You must use `AskUserQuestion` with exactly 3 questions. Do not write any copy before this step is complete.**
-
-**Priority ranking — ask the 3 most relevant questions for this campaign:**
-
-1. **CAMPAIGN TYPE** (almost always Q1)
-   > "Which campaign type is this? Options: nurture sequence / cold outbound / follow-up / re-engagement / promotional broadcast — and do you have a specific trigger or entry point for this sequence?"
-
-2. **CONTENT PILLAR**
-   > "Which Growthub content pillar should anchor this campaign? Options: (1) Growth System, (2) Automation & AI, (3) Client Results, (4) Education & Strategy, (5) Pipeline & Revenue — or should it blend two pillars?"
-
-3. **AUDIENCE SEGMENT**
-   > "Who is the target audience for this campaign? What is their current stage (new lead / warm prospect / past client / stalled pipeline / re-engage)? Include any specific segment tag or list name if known."
-
-4. **CTA / OFFER** (ask if campaign is promotional or unclear)
-   > "What is the primary CTA for this campaign — book a call, start a trial, claim an offer, or something else? Include the exact URL or action if you have it."
-
-5. **COMPLIANCE / HARD CONSTRAINTS**
-   > "Are there any claims, topics, or angles that are off-limits for this campaign?"
-
-6. **PLATFORM CONTEXT** (ask if platform handoff is in scope)
-   > "Are you pushing this to an email platform after drafting? If yes, which platform (GHL or other)? And should I pull existing templates from the platform or build from scratch?"
-
----
-
-### STEP 4 — MAP PILLAR TO CAMPAIGN ANGLE
-
-Using the answers from Step 3 and the pillar-to-angle mapping in `skills.md`, confirm:
-- Which content pillar is anchoring this campaign
-- What the campaign angle is (e.g., "Automation & AI → Remove the creative bottleneck, scale without headcount")
-- What the emotional arc is for the sequence (e.g., Frustrated → Informed → Activated)
-- What the primary CTA is and how it ladders up to the campaign goal
-
-Do not write copy until the angle is confirmed. State the angle to the user in one sentence and ask for a quick thumbs up before proceeding.
-
----
-
-### STEP 5 — BUILD THE SEQUENCE PLAN
-
-Load the frozen format from `templates/email-formats/` or build from `templates/sequence-planner.md`.
-
-For each email in the sequence, define:
-- Email number and send delay
-- Subject line theme
-- Body arc (what problem/value/story is this email covering)
-- Primary CTA
-- Platform segment tag or trigger condition
-
-Save to: `output/<client-slug>/<campaign-slug>/sequence-plan.md`
-
-Do not begin writing individual email drafts until the full sequence plan exists and is confirmed.
-
----
-
-### STEP 6 — WRITE THE COPY ARTIFACTS
-
-Write in this order:
-1. **Campaign brief** — using `templates/campaign-brief-template.md`
-2. **Email drafts** — using `templates/email-draft.md` for each email
-3. **Subject line matrix** — using `templates/subject-line-matrix.md`
-4. **CTA matrix** — using `templates/cta-matrix.md` (if campaign has multiple CTA variants)
-
-For each email draft, select the appropriate modules from `templates/email-modules/`. Check `templates/email-modules/INDEX.md` first.
-
-File naming:
-```
-output/<client-slug>/<campaign-slug>/
-  ├── <ClientSlug>_CampaignBrief_<Pillar>_v1_<YYYYMMDD>.md
-  ├── <ClientSlug>_SequencePlan_<Type>_v1_<YYYYMMDD>.md
-  ├── <ClientSlug>_Email01_<Theme>_v1_<YYYYMMDD>.md
-  ├── <ClientSlug>_Email02_<Theme>_v1_<YYYYMMDD>.md
-  ├── <ClientSlug>_SubjectLineMatrix_v1_<YYYYMMDD>.md
-  └── <ClientSlug>_CTAMatrix_v1_<YYYYMMDD>.md
-```
-
----
-
-### STEP 7 — PLATFORM HANDOFF (if in scope)
-
-If the user confirmed platform handoff in Step 3:
-
-**Mode A — API (preferred):**
-Read `runtime-assumptions.md` → Platform Adapter Interface. Use the environment variables configured for the active platform adapter to:
-1. List available email templates from the platform
-2. Map output copy into template slots
-3. Create or update the campaign/sequence in the platform
-4. Trigger a test send for review
-
-**Mode B — Browser-assisted:**
-Read `runtime-assumptions.md` → Browser-Assisted Workflows. Navigate to the platform campaign builder, transfer copy into template slots, and take a screenshot of the final email for the review log.
-
-**Mode C — Export only (no platform):**
-Produce a `<ClientSlug>_PlatformReady_v1_<YYYYMMDD>.md` file with copy organized by template slot, ready for manual upload.
-
----
-
-### STEP 8 — LOG THE DELIVERABLE
-
-Append to the deliverables log in the client brand kit:
-
-```
-- YYYY-MM-DD | <CampaignType> v<N> — <CampaignName> | output/<client-slug>/<campaign-slug>/
-```
-
----
-
-## DOCUMENT STRUCTURE — required section order
-
-### Campaign Brief
-1. Campaign overview (type, pillar, segment, CTA, dates)
-2. Audience profile
-3. Campaign angle + emotional arc
-4. Sequence map (email N → theme → CTA → send day)
-5. Voice/tone notes
-6. Compliance notes
-7. Platform notes
-
-### Email Draft
-1. Subject line (primary)
-2. Preview text
-3. Opening hook (first 1–2 sentences — must earn the scroll)
-4. Body (2–4 blocks — problem / value / story / education)
-5. CTA (primary)
-6. PS line (optional but recommended)
-7. Plain-text fallback block
-8. Platform slot map (if platform handoff is in scope)
-
-### Subject Line Matrix
-1. Email reference (email N, theme)
-2. 5+ subject line variants with type tag (curiosity / urgency / proof / personal / direct)
-3. Preview text for each variant
-4. Recommended A/B test pairing
-5. Notes
-
----
-
-## CRITICAL RULES TABLE
-
-| Rule | What it means |
-|---|---|
-| **Always ask 3 questions first** | Use `AskUserQuestion` before writing any copy |
-| **Always read skills.md first** | It is the source of truth — never operate from memory alone |
-| **Always load the brand kit first** | Voice, tone, pillar definitions, guardrails all come from the brand kit |
-| **Confirm the campaign angle before writing** | State the angle in one sentence and get a thumbs up |
-| **Sequence plan before email drafts** | Never write individual emails before the full arc is mapped |
-| **5+ subject line variants minimum** | Every email gets a full subject line matrix, not one line |
-| **Every email gets a plain-text fallback** | Required for platform compatibility — no exceptions |
-| **Never hardcode credentials** | API keys and platform IDs always come from env vars |
-| **One campaign per session** | Do not mix multiple campaign types in one run |
-| **Content pillar anchors every campaign** | No campaign is written without a confirmed pillar |
-| **Guardrails from brand kit are absolute** | Never use phrases or make claims that violate messaging_guardrails |
-| **Never fabricate social proof** | Use only numbers and results approved in the brand kit |
-| **CAN-SPAM compliance line in every broadcast** | Physical address + unsubscribe link required |
-| **Preview text is required** | Never deliver a subject line without preview text |
-| **Deliverables log updated after every session** | Append to brand kit, never skip |
-| **File naming convention is non-negotiable** | `<ClientSlug>_<Type>_<Pillar>_v<N>_<YYYYMMDD>.md` |
-| **Version not overwrite** | Increment `v2`, `v3` — never overwrite existing files |
-| **Platform handoff is mode-agnostic** | Use the adapter interface from runtime-assumptions.md |
-| **Never skip the sequence plan** | Even for a single broadcast, run through the brief template |
-| **Ask before platform push** | Confirm with user before creating or updating platform campaigns |
-
----
-
-## RESPONSE FORMAT — after questions are answered
-
-```
-Got it. Here's what I'm building:
-
-Campaign:    [type] — [pillar] pillar
-Audience:    [segment description]
-Angle:       [one-sentence campaign angle]
-Emails:      [N] emails — [day 1 / day X / day Y]
-CTA:         [primary CTA]
-Platform:    [API / Browser / Export only]
-
-Confirming angle before I start writing — does this match what you're after?
-[angle in plain language, 1–2 sentences]
-```
-
----
-
-## RESPONSE FORMAT — after copy is generated
-
-```
-✅ Campaign ready: output/<client-slug>/<campaign-slug>/
-
-Campaign:    [type] — [pillar] pillar
-Emails:      [N] drafts
-Subjects:    [N × 5+] variants in subject line matrix
-CTA:         [primary CTA]
-Platform:    [handoff mode]
-Files:       [list of output files]
-
-Next steps:
-• Review subject line matrix and pick A/B test pairing for Email 01
-• Confirm platform template mapping before upload
-• Flag any guardrail notes in QA checklist before sending
-```
-
----
-
-## COMMON MISTAKES TABLE
-
-| Mistake | Correct approach |
-|---|---|
-| Writing copy before asking 3 questions | Gate is mandatory — always AskUserQuestion first |
-| Using generic marketing voice | Pull exact tone adjectives and approved phrases from brand-kit.md |
-| Skipping content pillar mapping | Pillar must be confirmed before angle is set |
-| Writing email drafts before sequence plan | Sequence plan first — always |
-| One subject line per email | Minimum 5 variants with type tags |
-| Missing preview text | Subject line and preview text are always a pair |
-| Hardcoding platform credentials | Always env vars — never in files |
-| Missing plain-text fallback | Required in every email draft |
-| Using "guarantee" without qualifier | Check compliance_notes in brand kit first |
-| Fabricating proof points or stats | Only use numbers approved in brand kit |
-| Mixing campaign types in one sequence | One campaign type per sequence |
-| Overwriting existing output files | Always version up — `v2`, `v3`, never overwrite |
-| Forgetting the PS line | PS lines are high-read — always include one |
-| Not logging the deliverable | Append to brand kit deliverables log every session |
-| Pushing to platform without confirmation | Always confirm before any platform create/update |
-
----
-
-## Governed-workspace primitives (v1.2)
-
-This workspace carries the six architectural primitives every Growthub fork inherits. The contract is capability-agnostic (`@growthub/api-contract/skills::SkillManifest`); kit-specific specialisation lives in `skills.md` above.
-
-1. **`SKILL.md`** at the kit root — the discovery entry / routing menu. Read before `skills.md`.
-2. **Repo-root `AGENTS.md` pointer** — Cursor / Claude / Codex all read the same contract.
-3. **`.growthub-fork/project.md`** — session memory, seeded at init/import from `templates/project.md`. Append a dated entry after every material change.
-4. **Self-evaluation (`selfEval.criteria` + `maxRetries`)** — generate → apply → evaluate → record; retry up to 3; every attempt writes to both `project.md` (human) and `trace.jsonl` (machine). Use `recordSelfEval` (`cli/src/skills/self-eval.ts`); never bypass the fork-trace primitive.
-5. **Nested `skills/<slug>/SKILL.md`** — sub-skill lanes for parallel sub-agents on heavy or narrow work.
-6. **`helpers/<verb>.{sh,mjs,py}`** — safe shell tool layer; promote any inline shell that gets used twice.
-
-Command surface from inside this fork:
-
-- `growthub skills list` — enumerate this fork’s SKILL.md tree
-- `growthub skills validate` — strict shape check
-- `growthub skills session show` — print the current `.growthub-fork/project.md`
-- `growthub skills session init --kit <kit-id>` — (re-)seed session memory
-
-Full user-facing narrative: `cli/assets/worker-kits/growthub-custom-workspace-starter-v1/docs/governed-workspace-primitives.md` (also shipped into any workspace forked from the starter kit).

package/assets/worker-kits/growthub-geo-seo-v1/.env.example

@@ -1,14 +0,0 @@
-# Growthub GEO SEO Studio — Environment Config
-# Copy this file to .env and fill in your values.
-# Never commit .env to version control.
-
-# Path to your local clone of the geo-seo-claude fork.
-# Canonical env var: GEO_SEO_HOME (uniform pattern across all worker kits)
-# Legacy alias: GEO_SEO_FORK_PATH (still accepted by the CLI)
-# Default when unset: $HOME/geo-seo-claude
-# GEO_SEO_HOME=/path/to/your/geo-seo-claude
-
-# Anthropic API key — required for agent-enhanced analysis (Steps 5-9)
-# Core Python audit commands work without this key
-# Get one at https://console.anthropic.com
-ANTHROPIC_API_KEY=your_anthropic_key_here

package/assets/worker-kits/growthub-geo-seo-v1/QUICKSTART.md

@@ -1,138 +0,0 @@
-# Growthub GEO SEO Studio — Quickstart
-
-**Kit:** `growthub-geo-seo-v1`
-**Worker:** `geo-seo-operator`
-**Tool:** [geo-seo-claude](https://github.com/zubair-trabzada/geo-seo-claude)
-
----
-
-## What This Kit Does
-
-The Growthub GEO SEO Studio is a self-contained AI agent environment that audits websites for AI search visibility, citability, and traditional SEO health. It wraps the open-source `geo-seo-claude` tool to produce:
-
-- GEO Scores (0–100 composite score across 6 components)
-- Citability analyses (5-metric algorithm measuring AI quotability)
-- AI crawler permission reports (14 major crawlers)
-- Brand visibility reports (8 platforms)
-- llms.txt implementation plans
-- 4-week remediation roadmaps
-- Client-ready PDF reports
-
----
-
-## Setup — 6 Steps
-
-### Step 1 — Point Your Working Directory
-
-Export this kit to a local folder and point Claude Code's Working Directory at the kit root. All paths in the kit are relative to the kit root.
-
-### Step 2 — Copy the Environment File
-
-```bash
-cp .env.example .env
-```
-
-No API keys are required for core analysis. Python and Playwright handle all data collection locally. If you want agent-enhanced analysis, add your `ANTHROPIC_API_KEY` to `.env`.
-
-### Step 3 — Verify the Environment
-
-```bash
-node setup/verify-env.mjs
-```
-
-This checks:
-- Whether `geo-seo-claude` is cloned at `GEO_SEO_FORK_PATH` (default: `~/geo-seo-claude`)
-- Whether key Python scripts exist in the fork
-- Whether `ANTHROPIC_API_KEY` is valid format (if set)
-- No network calls are made during verification
-
-### Step 4 — Check Dependencies
-
-```bash
-bash setup/check-deps.sh
-```
-
-Verifies that `python3`, `pip`, `playwright`, `git`, and `node` are available. Checks Python version (3.8+ required). Checks Playwright chromium browser is installed.
-
-### Step 5 — Clone and Install the Fork (Local-Fork Mode Only)
-
-```bash
-bash setup/clone-fork.sh
-```
-
-This clones `geo-seo-claude` to `~/geo-seo-claude` (or `GEO_SEO_FORK_PATH` if set), runs `pip install -r requirements.txt`, and installs Playwright chromium.
-
-Skip this step if you are using **agent-only mode** — the operator can perform analysis without the local fork.
-
-### Step 6 — Start a Session
-
-Open Claude Code, set the Working Directory to this kit root, and start your session. The operator will guide you through the 10-step workflow.
-
----
-
-## Execution Modes
-
-| Mode | Requirements | Use When |
-|---|---|---|
-| `local-fork` | Python 3.8+, Playwright, geo-seo-claude cloned | You want the full tool stack — Python scripts, PDF generation, real crawl data |
-| `agent-only` | Nothing — Claude handles everything | You need a quick analysis and don't have the fork installed |
-| `hybrid` | ANTHROPIC_API_KEY + fork | Best of both — agent reasoning with Python data collection |
-
----
-
-## First Run
-
-1. Tell the operator: **"Run a full GEO audit on [your domain]"**
-2. The operator will ask 3 clarifying questions (target URL, scope, delivery format)
-3. The operator runs the 10-step workflow and produces all audit artifacts
-4. Output is saved to `output/<client-slug>/<project-slug>/`
-
----
-
-## New Client Setup
-
-See `brands/NEW-CLIENT.md` for instructions on adding a new client brand kit.
-
-Quick version:
-```bash
-cp brands/_template/brand-kit.md brands/<client-slug>/brand-kit.md
-# Then fill in the fields in the new file
-```
-
----
-
-## Available Commands
-
-The geo-seo-claude tool provides 14 commands. Tell the operator which you need:
-
-| Command | What It Does |
-|---|---|
-| `/geo audit` | Full GEO + SEO audit — all components |
-| `/geo citability` | Citability score only |
-| `/geo crawlers` | AI crawler permission check |
-| `/geo brands` | Brand mention and authority scan |
-| `/geo report` | Structured Markdown report |
-| `/geo report-pdf` | Branded PDF report |
-| `/geo content` | E-E-A-T and content quality |
-| `/geo schema` | Structured data validation |
-| `/geo technical` | Server headers and technical health |
-| `/geo llmstxt` | Generate llms.txt plan |
-| `/geo quick` | 60-second AI visibility snapshot |
-| `/geo proposal` | Client proposal with pricing |
-| `/geo prospect` | Prospect qualification scan |
-| `/geo compare` | Side-by-side URL comparison |
-
----
-
-## Key Files
-
-| File | Purpose |
-|---|---|
-| `workers/geo-seo-operator/CLAUDE.md` | Agent operating instructions (start here) |
-| `skills.md` | Full methodology — read at every session |
-| `brands/_template/brand-kit.md` | Blank brand kit template |
-| `brands/growthub/brand-kit.md` | Growthub reference example |
-| `output/README.md` | Output directory structure and naming |
-| `docs/geo-seo-fork-integration.md` | How this kit integrates with geo-seo-claude |
-| `docs/scoring-methodology.md` | GEO Score formula and citability algorithm |
-| `validation-checklist.md` | Pre-session checklist |

package/assets/worker-kits/growthub-geo-seo-v1/SKILL.md

@@ -1,90 +0,0 @@
----
-name: growthub-geo-seo-v1
-description: "Self-contained workspace for GEO + SEO auditing using geo-seo-claude. Produces AI search visibility audits, technical SEO reports, and content gap analyses. Use when the user says: \"geo seo\", \"ai search visibility\", \"seo audit\". Session memory tracks crawled properties, audit runs, and recommendation-acceptance outcomes."
-triggers:
-  - geo seo
-  - geo seo studio
-  - fork growthub-geo-seo-v1
-progressiveDisclosure: true
-sessionMemory:
-  path: .growthub-fork/project.md
-selfEval:
-  criteria:
-    - Operator contract (workers/geo-seo-operator/CLAUDE.md) read before any material change.
-    - .growthub-fork/project.md appended to at each material change.
-    - .growthub-fork/trace.jsonl receives a typed event for each material change.
-    - Kit-specific QUICKSTART / runtime-assumptions / output-standards honoured.
-  maxRetries: 3
-  traceTo: .growthub-fork/trace.jsonl
-helpers: []
-subSkills: []
-mcpTools: []
----
-
-# Growthub Agent Worker Kit — GEO SEO Studio
-
-Discovery entry + routing menu for the `growthub-geo-seo-v1` worker kit. Family: `studio`. Agent contract: `workers/geo-seo-operator/CLAUDE.md`.
-
-## When to use this skill
-
-When the user's intent matches any of the triggers above — or when an agent has been dropped into a fork whose `.growthub-fork/fork.json` declares `kitId: "growthub-geo-seo-v1"`.
-
-## Decision tree
-
-```
-Fork exists (this directory contains .growthub-fork/fork.json)?
-├── No  → run: growthub starter init --out <path>   (or import-repo / import-skill)
-│         then: growthub kit download growthub-geo-seo-v1 --out <path>
-│
-└── Yes → read in this order:
-          1. .growthub-fork/project.md                         — session memory (primitive #3)
-          2. SKILL.md  (this file)                             — routing menu  (primitive #1)
-          3. skills.md                                         — operator runbook
-          4. workers/geo-seo-operator/CLAUDE.md                              — agent contract
-          5. QUICKSTART.md                                     — first-run steps
-          6. runtime-assumptions.md                            — host expectations
-          7. .growthub-fork/policy.json                        — what you may touch
-          8. .growthub-fork/trace.jsonl (tail 20)              — recent machine history
-```
-
-## The six primitives (same shape across every Growthub worker kit)
-
-1. **`SKILL.md`** — this file.
-2. **Symlinked pointer** — repo-root `AGENTS.md` is authoritative.
-3. **`.growthub-fork/project.md`** — session memory, seeded by the CLI from `templates/project.md` at init/import time.
-4. **Self-evaluation** — generate → apply → evaluate → record; retry up to `selfEval.maxRetries` (default 3); mirrors the Fork Sync Agent's preview → apply → trace loop (primitive #4). Contract: `@growthub/api-contract/skills::SkillSelfEval`.
-5. **`skills/`** — nested sub-skills for parallel sub-agents on heavy / narrow work.
-6. **`helpers/`** — safe shell tool layer. Promote inline shell here whenever the same snippet is re-used.
-
-## Self-evaluation (primitive #4)
-
-Enforce `selfEval.maxRetries: 3`. At the ceiling, park with a `needs_confirmation` note in `project.md` and stop. Record every attempt to both `project.md` and `trace.jsonl`.
-
-## Session memory (primitive #3)
-
-`.growthub-fork/project.md` is the only cross-session continuity surface for this fork. Append at every material change, approval boundary, and self-eval outcome.
-
-## Sub-skills (primitive #5)
-
-(None declared at the baseline; populate `skills/` and the frontmatter `subSkills[]` array as specialist lanes emerge.)
-
-## Helpers (primitive #6)
-
-(None declared at the baseline; populate `helpers/` and the frontmatter `helpers[]` array as inline shell matures.)
-
-## MCP routing (optional)
-
-List concrete MCP tool IDs in `mcpTools[]` when a fork runs an MCP server for auth-heavy actions. Declarative only at v1.
-
-## Related files
-
-- `skills.md` — operator runbook (deep)
-- `QUICKSTART.md` — first-run steps
-- `runtime-assumptions.md` — host expectations
-- `output-standards.md` — output locations + manifest shape
-- `validation-checklist.md` — pre-flight checklist (if present)
-- `templates/project.md` — session-memory template
-- `templates/self-eval.md` — self-evaluation template
-- `helpers/README.md` — safe shell tool layer convention
-- `skills/README.md` — sub-skill convention
-- `workers/geo-seo-operator/CLAUDE.md` — agent contract

package/assets/worker-kits/growthub-geo-seo-v1/brands/NEW-CLIENT.md

@@ -1,104 +0,0 @@
-# New Client Brand Kit Setup
-
-Follow these steps to add a new client to the GEO SEO Studio.
-
----
-
-## Step 1 — Copy the Template
-
-```bash
-# Replace <client-slug> with the client's URL-safe slug (lowercase, hyphens only)
-cp brands/_template/brand-kit.md brands/<client-slug>/brand-kit.md
-```
-
-Examples:
-```bash
-cp brands/_template/brand-kit.md brands/urban-cycle/brand-kit.md
-cp brands/_template/brand-kit.md brands/acme-saas/brand-kit.md
-cp brands/_template/brand-kit.md brands/coastal-dental/brand-kit.md
-```
-
----
-
-## Step 2 — Fill In Required Fields
-
-Open `brands/<client-slug>/brand-kit.md` and fill in all fields. The required fields are:
-
-| Field | Location | Why It Matters |
-|---|---|---|
-| `client_name` | IDENTITY | Used in all output file names and reports |
-| `slug` | IDENTITY | Must match the directory name — used in output paths |
-| `industry` | IDENTITY | Context for tone calibration and benchmark comparison |
-| `primary_service` | IDENTITY | What GEO/SEO work is being done |
-| `date_onboarded` | IDENTITY | Tracks when the engagement started |
-| `account_owner` | IDENTITY | Who is responsible for this account |
-| `target_persona.pain_point` | AUDIENCE | Drives messaging tone in proposals and reports |
-| `geographic_target` | AUDIENCE | Informs platform and language scope |
-| `core_message` | MESSAGING | Used in client proposals |
-| `tone` | MESSAGING | Calibrates how the operator writes client-facing content |
-| `target_url` | AUDIT SCOPE | The domain to audit |
-| `audit_type` | AUDIT SCOPE | quick / full / report / specific-command |
-| `delivery_format` | AUDIT SCOPE | markdown / pdf / both |
-| `prospect_stage` | AGENCY CONTEXT | discovery / proposal-sent / active / etc. |
-
-Optional but recommended:
-- `competitor_urls` — enables `/geo compare` command
-- `monthly_retainer_range` — appears in proposals
-- `crm_notes` — any notes about the account
-
----
-
-## Step 3 — Tell the Agent to Use It
-
-At the start of your session, tell the GEO SEO Operator:
-
-> "Use the brand kit at brands/<client-slug>/brand-kit.md for this session."
-
-Or the operator will automatically look for `brands/<client-slug>/brand-kit.md` based on the client name you provide.
-
----
-
-## Step 4 — Update the Deliverables Log
-
-After each audit package is delivered, append a line to the brand kit's DELIVERABLES LOG:
-
-```
-- YYYY-MM-DD | GEO SEO Audit Package v<N> — <Project Name> | output/<client-slug>/<project-slug>/
-```
-
-The operator will do this automatically at Step 10 of the workflow.
-
----
-
-## Multiple Clients
-
-Each client gets its own subdirectory under `brands/`:
-
-```
-brands/
-  _template/
-    brand-kit.md          ← blank template — never fill this in
-  growthub/
-    brand-kit.md          ← Growthub internal reference example
-  urban-cycle/
-    brand-kit.md          ← client brand kit
-  acme-saas/
-    brand-kit.md          ← client brand kit
-  NEW-CLIENT.md           ← this file
-```
-
-Do not modify `brands/_template/brand-kit.md` — it is the frozen template. Always copy it before filling in client details.
-
----
-
-## Brand Kit Field Reference
-
-| Section | Fields |
-|---|---|
-| IDENTITY | client_name, slug, industry, primary_service, campaign_name, date_onboarded, account_owner |
-| AUDIENCE | target_persona (role, company_type, pain_point, intent), geographic_target, do_not_attract |
-| MESSAGING | core_message, tone, approved_phrases, messaging_guardrails, cta_text |
-| BRAND DESIGN | colors (primary, secondary, accent, dark, white), fonts, logo_file, logo_on_dark |
-| AUDIT SCOPE | target_url, competitor_urls, audit_type, delivery_format |
-| AGENCY CONTEXT | monthly_retainer_range, prospect_stage, crm_notes |
-| DELIVERABLES LOG | Running log of all delivered audit packages |