@friedbotstudio/create-baseline 0.1.0

package/obj/template/.claude/skills/code-structure/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: code-structure
+owner: baseline
+description: MANDATORY skill for ALL code generation. Enforces top-down composition, consistent abstraction layers, and proper module hierarchy. Apply every time you write or modify code — in any language — no exceptions.
+---
+
+# Code Structure Rules
+
+Apply these rules every time you write or modify code, in any language. This is not optional.
+
+## Abstraction Layer Model
+
+All modules belong to one of three layers. Each layer has strict rules about what it can contain and what it may reach for.
+
+| Layer | Purpose | Composes From | Must Not Contain |
+|-------|---------|---------------|------------------|
+| **Orchestration** | Assembles the top-level flow. The entry point a reader hits first. | Domain modules, Foundation modules (rarely, and only for obviously-cross-cutting utilities) | Raw primitives (inline HTTP calls, SQL strings, regex, file I/O, math); implementation details of any domain module |
+| **Domain** | Business logic for one responsibility. Named after the capability, not the technology. | Foundation modules; other Domain modules when a genuine dependency exists | Raw primitives that would make the module bound to infrastructure (wrap them in Foundation instead) |
+| **Foundation** | Primitives, adapters, utilities. The bedrock everything else is made of. | Language stdlib, third-party libs, other Foundation modules | Nothing restricted here — this is where the raw stuff lives |
+
+### Layer mappings per language family
+
+The layer names are universal; the concrete file types differ per stack:
+
+| Stack | Orchestration | Domain | Foundation |
+|---|---|---|---|
+| React/TSX | `pages/` / `app/` routes | `features/<domain>/` | `components/ui/`, `components/layout/`, `lib/` |
+| Node/Express | `routes/`, `server.ts` entry | `services/<domain>/` | `lib/`, `utils/`, `db/` |
+| Python/FastAPI | `main.py`, `api/routes/` | `<domain>/service.py` | `<domain>/repo.py`, `common/`, `adapters/` |
+| Python CLI | `cli.py` command entry | `<command>/logic.py` | `<command>/io.py`, `common/` |
+| Go service | `cmd/<app>/main.go`, handlers | `internal/<domain>/` | `pkg/` utilities, `internal/store/` |
+| Rust CLI | `main.rs`, subcommand entry | `src/<domain>/` | `src/util/`, `src/io/` |
+
+Not in this table? Map by the same principle: **Orchestration files are the table-of-contents; Domain files carry the business logic; Foundation files provide primitives and adapters**.
+
+### Layer Rules
+
+1. **Orchestration** — pure composition. Reads like a table of contents. If a section needs logic beyond assembly, extract it to Domain. No inline business logic, no raw primitives, no fixed strings that belong elsewhere.
+2. **Domain** — composed from Foundation. Express business rules in names. Do not reach for raw infrastructure (HTTP, SQL, filesystem, time, randomness) directly — wrap through Foundation.
+3. **Foundation** — the layer where the stack shows through. SQL, HTTP clients, Tailwind classes, regex, datetime handling — all legitimately here.
+
+## Core Principles
+
+1. **Write top-down, but reuse first.** Start with how you want the entry point to read. Before creating a new module, check the registry (see below). If a similar one exists, open it and extend it with backward-compatible changes rather than creating a duplicate. Only create new modules when nothing fits.
+2. **One abstraction level per composition site.** Every sibling at a given call site (siblings in a JSX tree, statements in a function, items in a pipeline, methods chained together) should be at the same abstraction level. If a named call sits next to a raw primitive, the abstraction is broken — extract the primitive.
+3. **Step-over / step-into.** Reading a file should work like a debugger. At the current level, you "step over" each named call (understand what it does from its name). To see how it works, you "step into" its definition. Each step-into reveals exactly one level deeper.
+4. **Compose, don't inline.** Instead of writing code directly, identify patterns first, build them as units, then assemble. For pattern identification, refer to https://refactoring.guru/design-patterns for established solutions. This is composition — not premature abstraction.
+5. **DRY emerges from structure.** Do not force DRY. If you follow the layer model and compose correctly, reuse happens naturally.
+6. **Comments become unnecessary.** If the code needs a comment to explain *what* it does, the abstraction is wrong. Names and composition should convey meaning. Comments for *why* — non-obvious constraints, workarounds, hidden invariants — are still valid.
+7. **Refactoring is a separate concern.** If a module grows too large or complex, apply design patterns (see https://refactoring.guru/design-patterns) to restructure it during the `/simplify` review stage — not during initial composition.
+
+## Module Registry
+
+Before creating any new module, scan the codebase for reusable matches:
+
+1. **Search** — Glob for existing modules in the correct layer (e.g., `src/**/*.tsx`, `internal/**/*.go`, `<pkg>/**/*.py`). The filesystem is the registry.
+2. **Match** — Check if any existing module serves a similar purpose (same layer, similar inputs/outputs, overlapping responsibility).
+3. **Extend or create**:
+   - **Match found** — Open it. Add backward-compatible options/variants to support the new use case. Do not fork or duplicate.
+   - **No match** — Create a new module in the correct layer directory.
+4. **Register** — After creating a new module, it is automatically part of the registry (the filesystem is the registry). No separate manifest needed.
+
+## Detection Rules
+
+Apply these checks when writing or reviewing code — regardless of language:
+
+| Signal | Problem | Fix |
+|--------|---------|-----|
+| Orchestration file contains raw primitives (inline HTML attributes, SQL strings, HTTP requests, formatting logic) | Orchestration layer is leaking into Foundation | Extract the primitive into a Foundation module; the orchestration should call a name, not a raw primitive |
+| Orchestration file defines local inner functions/classes | Domain logic hiding in the orchestration file | Move to a Domain module |
+| A loop/map/pipeline body contains more than one level of JSX / logic / formatting | Mixed abstraction — the per-item shape is inline | Extract the body into a named Domain/Foundation call |
+| Siblings in a call site mix named calls with raw primitives | Broken abstraction level | Wrap the primitives into a named call at the same layer as the others |
+| A module file is longer than ~80 lines of substantive code | Too many concerns in one module | Split into composed sub-modules following the layer model |
+| Domain module directly uses `<section>`, `<div>`, raw SQL, raw HTTP, `os.path`, `time.now()`, etc. | Domain should compose from Foundation, not raw infrastructure | Introduce or use a Foundation module that wraps it |
+| A name describes *how* (`formatWithRegex`, `httpClient`, `SQLBuilder`) at the Orchestration layer | Implementation leaked into the name | Rename to describe *what* (`format<Thing>`, `<domain>Client`, `<domain>Query`) — the Foundation wrapper owns the how |
+
+## Examples
+
+### Example A — TSX: inline list details (BAD)
+
+```tsx
+<Section>
+  {items.map((entry) => (
+    <div key={entry.id}>
+      <div>
+        <h1>{entry.title}</h1>
+        <p>{entry.subtitle}</p>
+      </div>
+      <div>
+        {entry.tags.map((tag) => (
+          <span key={tag.id}>{tag.label}</span>
+        ))}
+      </div>
+    </div>
+  ))}
+</Section>
+```
+
+**Problem:** the `.map()` body contains two abstraction levels — iteration *and* item rendering.
+
+### Example A — Extracted (GOOD)
+
+```tsx
+<Section>
+  {items.map((entry) => (
+    <ProductCard key={entry.id} item={entry} />
+  ))}
+</Section>
+```
+
+`ProductCard` is a Domain module; its internals use Foundation (UI/layout) modules. The Orchestration site reads as a blueprint.
+
+---
+
+### Example B — Python service: inline raw primitives (BAD)
+
+```python
+# orders/service.py — Domain module, but reaching for raw primitives
+def create_order(user_id: str, sku: str, qty: int) -> str:
+    conn = psycopg2.connect(os.environ["DB_URL"])
+    cur = conn.cursor()
+    cur.execute(
+        "INSERT INTO orders (user_id, sku, qty, created_at) "
+        "VALUES (%s, %s, %s, now()) RETURNING id",
+        (user_id, sku, qty),
+    )
+    order_id = cur.fetchone()[0]
+    conn.commit()
+    requests.post(os.environ["WEBHOOK_URL"], json={"order_id": order_id})
+    return order_id
+```
+
+**Problem:** a Domain function directly handles a DB connection, SQL, and HTTP — three Foundation concerns inlined. Siblings in the function body are at wildly different abstraction levels.
+
+### Example B — Extracted (GOOD)
+
+```python
+# orders/service.py — Domain module
+def create_order(user_id: str, sku: str, qty: int) -> str:
+    order_id = orders_repo.insert(user_id=user_id, sku=sku, qty=qty)
+    webhooks.notify_order_created(order_id)
+    return order_id
+```
+
+`orders_repo` and `webhooks` are Foundation modules. The Domain reads as three intent-level statements; the raw primitives live one layer down and are tested there.
+
+---
+
+### Example C — Go HTTP handler: broken abstraction in Orchestration (BAD)
+
+```go
+// cmd/api/main.go — Orchestration
+func createOrder(w http.ResponseWriter, r *http.Request) {
+    var body struct { SKU string; Qty int }
+    if err := json.NewDecoder(r.Body).Decode(&body); err != nil {
+        http.Error(w, "bad json", 400); return
+    }
+    rows, _ := db.Query("INSERT INTO orders (sku, qty) VALUES ($1, $2) RETURNING id",
+        body.SKU, body.Qty)
+    // ... more raw SQL, HTTP, JSON wiring ...
+}
+```
+
+**Problem:** the Orchestration handler mixes JSON decoding, SQL, error formatting — every layer is inlined at the top.
+
+### Example C — Extracted (GOOD)
+
+```go
+func createOrder(w http.ResponseWriter, r *http.Request) {
+    cmd, err := orders.DecodeCreate(r)
+    if err != nil { http.Error(w, err.Error(), 400); return }
+    id, err := orders.Create(cmd)
+    if err != nil { http.Error(w, err.Error(), 500); return }
+    json.NewEncoder(w).Encode(map[string]string{"id": id})
+}
+```
+
+The handler is a 4-line table-of-contents: decode, create, respond. `orders` is the Domain module; its internals use Foundation (DB adapter, JSON codec) modules.
+
+## Directory Structure
+
+Place modules according to their layer. The names of directories depend on your stack's conventions, but the three layers are universal:
+
+```
+<project>/
+├── <orchestration>/     # pages, routes, main entries, CLI commands
+├── <domain>/            # features / services / use-cases — business logic
+│   └── <capability>/    # one directory per domain capability
+└── <foundation>/        # primitives, adapters, utilities
+```
+
+Create directories as needed — do not create empty directories in advance. When a module is created, place it in the layer it belongs to. If a directory doesn't exist yet, create it at that point.
+
+### Placement Rules
+
+- Uses only primitives (HTML+CSS, stdlib, raw SQL, raw HTTP clients, math) → **Foundation**
+- Composes Foundation modules to express one domain capability → **Domain**
+- Composes Domain modules to express an end-to-end flow or entry point → **Orchestration**
+- Shared across domains without domain logic of its own → **Foundation**
+- **Domain and Foundation modules do not live inside Orchestration files.** Every module gets its own file in the correct directory.
+
+## Applies to
+
+Every language, every stack, every file type you may write or modify. The detection rules are phrased for JSX because of the original UI context, but the signals translate: a Python function with inline SQL, a Go handler with inline JSON decoding, a Rust `main` with inline regex — all the same category of violation. Use the principles; adapt the vocabulary.

package/obj/template/.claude/skills/commit/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: commit
+owner: baseline
+description: Workflow Phase 11 — Commit Preparation and Execution. Stages and commits the work. Requires `/grant-commit` first (Git Commit Guard enforces a 5-min consent window).
+argument-hint: "[optional commit message; otherwise drafted from the spec/intake]"
+---
+
+Prereq: `archive` in `completed` (i.e., Phase 10.5 has moved all slug artifacts to `docs/archive/<date>/<slug>/`) AND a valid consent token at `.claude/state/commit_consent` (the Git Commit Guard hook enforces this independently).
+
+**Applicability.** This skill applies only when the project is a git repository. Non-git projects auto-except `commit` at `/triage` time (CLAUDE.md Article IV); the workflow ends after `/archive`.
+
+Steps:
+
+0. **Git-repo precheck.** Run `git rev-parse --is-inside-work-tree 2>/dev/null`. If exit non-zero, exit cleanly with: "Not a git repository — `/commit` is inapplicable. Per CLAUDE.md Article IV, `commit` is auto-excepted on non-git projects; the workflow ended at `/archive`. Persistence outside git is your responsibility." Do not run any subsequent step.
+1. **Archive `workflow.json` itself.** This is the final piece of the archival bundle, held back until now so phase-ordering checks worked up through this point. Read `.claude/state/workflow.json` to get the slug, then move the file into the already-existing archive bundle: `docs/archive/<date>/<slug>/workflow.json`. Use the bundle's `<date>` directory (the one `/archive` created — inspect `docs/archive/` to find the most recent bundle matching the slug).
+2. Verify workflow prereq: `archive` is the final non-commit entry in `completed`; no open consent gates remain.
+3. `git status` + `git diff --stat` to confirm the change set. The diff now includes: production code changes + archive bundle additions + the workflow.json move. Stage named paths explicitly (never `git add -A` / `git add .` — seed.md forbids it).
+4. Draft the commit message from the spec + diff. Conventional-style prefix (`feat:` / `fix:` / `refactor:` / `docs:` / `test:`) followed by a 1-line summary and a short body explaining the WHY. The subject line is a fixed-register one-liner — leave it alone. The body is reviewer-facing prose — pass it through `Skill(humanizer)` before step 5 so AI-writing tells (em-dash overuse, rule of three, inflated verbs, vague attributions) get scrubbed. Keep the brief tight: tell humanizer the register is "factual reviewer-facing commit body — describe the diff faithfully, do not invent rationale, preserve any spec quotes verbatim".
+5. Run `git commit` with the message via HEREDOC. The Git Commit Guard hook will verify consent. If consent is missing/expired, stop and ask the user to run `/grant-commit`.
+6. Do NOT run `git push`, `git commit --amend`, or pass `--no-verify`/`--no-gpg-sign` unless the user explicitly named the operation in their current request.
+7. Append `"commit"` to `completed` — but note this only matters for logs; the workflow.json is now in the archive and the live `.claude/state/workflow.json` no longer exists. Report the commit SHA to the user.

package/obj/template/.claude/skills/copywriting/SKILL.md

@@ -0,0 +1,252 @@
+---
+name: copywriting
+owner: baseline
+description: When the user wants to write, rewrite, or improve marketing copy for any page — including homepage, landing pages, pricing pages, feature pages, about pages, or product pages. Also use when the user says "write copy for," "improve this copy," "rewrite this page," "marketing copy," "headline help," "CTA copy," "value proposition," "tagline," "subheadline," "hero section copy," "above the fold," "this copy is weak," "make this more compelling," or "help me describe my product." Use this whenever someone is working on website text that needs to persuade or convert. For email copy, see email-sequence. For popup copy, see popup-cro. For editing existing copy, see copy-editing.
+metadata:
+  version: 1.1.0
+---
+
+# Copywriting
+
+You are an expert conversion copywriter. Your goal is to write marketing copy that is clear, compelling, and drives action.
+
+## Before Writing
+
+Gather this context (ask if not provided):
+
+### 1. Page Purpose
+- What type of page? (homepage, landing page, pricing, feature, about)
+- What is the ONE primary action you want visitors to take?
+
+### 2. Audience
+- Who is the ideal customer?
+- What problem are they trying to solve?
+- What objections or hesitations do they have?
+- What language do they use to describe their problem?
+
+### 3. Product/Offer
+- What are you selling or offering?
+- What makes it different from alternatives?
+- What's the key transformation or outcome?
+- Any proof points (numbers, testimonials, case studies)?
+
+### 4. Context
+- Where is traffic coming from? (ads, organic, email)
+- What do visitors already know before arriving?
+
+---
+
+## Copywriting Principles
+
+### Clarity Over Cleverness
+If you have to choose between clear and creative, choose clear.
+
+### Benefits Over Features
+Features: What it does. Benefits: What that means for the customer.
+
+### Specificity Over Vagueness
+- Vague: "Save time on your workflow"
+- Specific: "Cut your weekly reporting from 4 hours to 15 minutes"
+
+### Customer Language Over Company Language
+Use words your customers use. Mirror voice-of-customer from reviews, interviews, support tickets.
+
+### One Idea Per Section
+Each section should advance one argument. Build a logical flow down the page.
+
+---
+
+## Writing Style Rules
+
+### Core Principles
+
+1. **Simple over complex** — "Use" not "utilize," "help" not "facilitate"
+2. **Specific over vague** — Avoid "streamline," "optimize," "innovative"
+3. **Active over passive** — "We generate reports" not "Reports are generated"
+4. **Confident over qualified** — Remove "almost," "very," "really"
+5. **Show over tell** — Describe the outcome instead of using adverbs
+6. **Honest over sensational** — Fabricated statistics or testimonials erode trust and create legal liability
+
+### Quick Quality Check
+
+- Jargon that could confuse outsiders?
+- Sentences trying to do too much?
+- Passive voice constructions?
+- Exclamation points? (remove them)
+- Marketing buzzwords without substance?
+
+For thorough line-by-line review, use the **copy-editing** skill after your draft (upstream — not in this baseline; do the line-by-line review inline if needed).
+
+---
+
+## Best Practices
+
+### Be Direct
+Get to the point. Don't bury the value in qualifications.
+
+❌ Slack lets you share files instantly, from documents to images, directly in your conversations
+
+✅ Need to share a screenshot? Send as many documents, images, and audio files as your heart desires.
+
+### Use Rhetorical Questions
+Questions engage readers and make them think about their own situation.
+- "Hate returning stuff to Amazon?"
+- "Tired of chasing approvals?"
+
+### Use Analogies When Helpful
+Analogies make abstract concepts concrete and memorable.
+
+### Pepper in Humor (When Appropriate)
+Puns and wit make copy memorable—but only if it fits the brand and doesn't undermine clarity.
+
+---
+
+## Page Structure Framework
+
+### Above the Fold
+
+**Headline**
+- Your single most important message
+- Communicate core value proposition
+- Specific > generic
+
+**Example formulas:**
+- "{Achieve outcome} without {pain point}"
+- "The {category} for {audience}"
+- "Never {unpleasant event} again"
+- "{Question highlighting main pain point}"
+
+**For comprehensive headline formulas**: See [references/copy-frameworks.md](references/copy-frameworks.md)
+
+**For natural transition phrases**: See [references/natural-transitions.md](references/natural-transitions.md)
+
+**Subheadline**
+- Expands on headline
+- Adds specificity
+- 1-2 sentences max
+
+**Primary CTA**
+- Action-oriented button text
+- Communicate what they get: "Start Free Trial" > "Sign Up"
+
+### Core Sections
+
+| Section | Purpose |
+|---------|---------|
+| Social Proof | Build credibility (logos, stats, testimonials) |
+| Problem/Pain | Show you understand their situation |
+| Solution/Benefits | Connect to outcomes (3-5 key benefits) |
+| How It Works | Reduce perceived complexity (3-4 steps) |
+| Objection Handling | FAQ, comparisons, guarantees |
+| Final CTA | Recap value, repeat CTA, risk reversal |
+
+**For detailed section types and page templates**: See [references/copy-frameworks.md](references/copy-frameworks.md)
+
+---
+
+## CTA Copy Guidelines
+
+**Weak CTAs (avoid):**
+- Submit, Sign Up, Learn More, Click Here, Get Started
+
+**Strong CTAs (use):**
+- Start Free Trial
+- Get [Specific Thing]
+- See [Product] in Action
+- Create Your First [Thing]
+- Download the Guide
+
+**Formula:** [Action Verb] + [What They Get] + [Qualifier if needed]
+
+Examples:
+- "Start My Free Trial"
+- "Get the Complete Checklist"
+- "See Pricing for My Team"
+
+---
+
+## Page-Specific Guidance
+
+### Homepage
+- Serve multiple audiences without being generic
+- Lead with broadest value proposition
+- Provide clear paths for different visitor intents
+
+### Landing Page
+- Single message, single CTA
+- Match headline to ad/traffic source
+- Complete argument on one page
+
+### Pricing Page
+- Help visitors choose the right plan
+- Address "which is right for me?" anxiety
+- Make recommended plan obvious
+
+### Feature Page
+- Connect feature → benefit → outcome
+- Show use cases and examples
+- Clear path to try or buy
+
+### About Page
+- Tell the story of why you exist
+- Connect mission to customer benefit
+- Still include a CTA
+
+---
+
+## Voice and Tone
+
+Before writing, establish:
+
+**Formality level:**
+- Casual/conversational
+- Professional but friendly
+- Formal/enterprise
+
+**Brand personality:**
+- Playful or serious?
+- Bold or understated?
+- Technical or accessible?
+
+Maintain consistency, but adjust intensity:
+- Headlines can be bolder
+- Body copy should be clearer
+- CTAs should be action-oriented
+
+---
+
+## Output Format
+
+When writing copy, provide:
+
+### Page Copy
+Organized by section:
+- Headline, Subheadline, CTA
+- Section headers and body copy
+- Secondary CTAs
+
+### Annotations
+For key elements, explain:
+- Why you made this choice
+- What principle it applies
+
+### Alternatives
+For headlines and CTAs, provide 2-3 options:
+- Option A: [copy] — [rationale]
+- Option B: [copy] — [rationale]
+
+### Meta Content (if relevant)
+- Page title (for SEO)
+- Meta description
+
+---
+
+## Related Skills
+
+These five are upstream companion skills (from the `claude-code-setup` plugin family) and **do not ship with this baseline**. Listed for reference only — for the capabilities they describe, ask the user inline or install the plugin separately.
+
+- **copy-editing**: For polishing existing copy (use after your draft)
+- **page-cro**: If page structure/strategy needs work, not just copy
+- **email-sequence**: For email copywriting
+- **popup-cro**: For popup and modal copy
+- **ab-test-setup**: To test copy variations

package/obj/template/.claude/skills/copywriting/evals/evals.json

@@ -0,0 +1,111 @@
+{
+  "skill_name": "copywriting",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write homepage copy for a SaaS tool that automates employee onboarding. Target audience is HR directors at mid-size companies (200-2000 employees). Main differentiator is that it integrates with all major HRIS systems and cuts onboarding time from 2 weeks to 2 days.",
+      "expected_output": "Should check for product-marketing-context.md first. Should write full page copy organized by section: Headline, Subheadline, CTA (above the fold), then Social Proof, Problem/Pain, Solution/Benefits, How It Works, Objection Handling, and Final CTA. Should follow copywriting principles: clarity over cleverness, benefits over features, specificity (use the '2 weeks to 2 days' stat), customer language. Headline should communicate core value proposition. CTAs should be action-oriented ('Start Free Trial' not 'Submit'). Should provide 2-3 headline alternatives with rationale. Should include annotations explaining key copy choices. Should include meta content (SEO page title and meta description).",
+      "assertions": [
+        "Checks for product-marketing-context.md",
+        "Writes full page copy organized by section",
+        "Includes Headline, Subheadline, and CTA above the fold",
+        "Includes Social Proof, Problem/Pain, Solution/Benefits, How It Works sections",
+        "Uses the '2 weeks to 2 days' specificity in copy",
+        "CTAs are action-oriented, not generic",
+        "Provides 2-3 headline alternatives with rationale",
+        "Includes annotations explaining copy choices",
+        "Includes meta content (SEO title and meta description)"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Rewrite this headline: 'An Innovative AI-Powered Platform for Streamlined Business Operations' — it's for a B2B SaaS tool that helps small businesses manage invoicing and payments.",
+      "expected_output": "Should identify problems: jargon ('innovative,' 'AI-powered,' 'streamlined,' 'business operations'), too vague, company language not customer language. Should apply copywriting principles — specificity over vagueness, benefits over features, customer language over company language. Should provide 2-3 alternative headlines using formulas like '{Achieve outcome} without {pain point}' or 'The {category} for {audience}'. Each alternative should include rationale. Should also suggest a subheadline that adds specificity.",
+      "assertions": [
+        "Identifies jargon in original headline",
+        "Identifies vagueness as a problem",
+        "Identifies company language vs customer language issue",
+        "Provides 2-3 alternative headlines",
+        "Alternatives use headline formulas from the skill",
+        "Each alternative includes rationale",
+        "Suggests a subheadline"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "i need copy for my pricing page. we have three plans: starter ($29/mo), pro ($79/mo), business ($199/mo). it's a social media scheduling tool for marketers",
+      "expected_output": "Should trigger on the casual phrasing. Should ask or infer audience context. Should apply Pricing Page guidance: help visitors choose the right plan, address 'which is right for me?' anxiety, make recommended plan obvious. Should write plan names, descriptions, feature lists with benefit-oriented copy (not just feature names). Should include a page headline that addresses the pricing decision. CTAs should be specific per plan. Should handle objection handling (FAQ copy). Should provide alternatives for key elements.",
+      "assertions": [
+        "Triggers on casual phrasing",
+        "Applies Pricing Page guidance",
+        "Addresses 'which plan is right for me' anxiety",
+        "Makes recommended plan obvious",
+        "Writes benefit-oriented feature copy, not just feature names",
+        "Includes page headline",
+        "CTAs are specific per plan",
+        "Includes FAQ or objection handling copy",
+        "Provides alternatives for key elements"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "Write copy for our About page. We're a 3-person startup that built a developer tool for database migrations. Founded because we kept losing data during migrations at our last jobs. Tone should be professional but human.",
+      "expected_output": "Should apply About Page guidance: tell the story of why you exist, connect mission to customer benefit, still include a CTA. Should adapt voice and tone to 'professional but human' as specified. Should tell the founder origin story authentically. Should connect the personal pain to the customer's pain. Should include a CTA even on the About page. Copy should follow style rules: active voice, confident, specific. Should NOT be overly corporate or generic.",
+      "assertions": [
+        "Applies About Page guidance",
+        "Tells the story of why the company exists",
+        "Connects mission to customer benefit",
+        "Includes a CTA",
+        "Adapts tone to professional but human",
+        "Uses the founder origin story",
+        "Connects personal pain to customer pain",
+        "Uses active voice",
+        "Avoids corporate jargon"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "Can you improve this CTA? We currently have 'Learn More' on our feature page for our analytics dashboard product.",
+      "expected_output": "Should immediately identify 'Learn More' as a weak CTA per the guidelines. Should apply the CTA formula: [Action Verb] + [What They Get] + [Qualifier]. Should provide 2-3 strong alternatives like 'See the Dashboard in Action,' 'Start Your Free Trial,' or 'Explore Analytics Features.' Each alternative should include rationale and context for when it works best. Should also consider CTA hierarchy — whether this is a primary or secondary CTA, and suggest complementary CTAs if relevant.",
+      "assertions": [
+        "Identifies 'Learn More' as a weak CTA",
+        "Applies the CTA formula from the skill",
+        "Provides 2-3 strong alternatives",
+        "Each alternative includes rationale",
+        "Considers CTA hierarchy (primary vs secondary)",
+        "Suggests complementary CTAs"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "Write me a 5-email welcome sequence for new trial users of our project management tool.",
+      "expected_output": "Should recognize this is an email copywriting task, not page copywriting. Should defer to or cross-reference the email-sequence skill, which specifically handles email sequences, drip campaigns, and lifecycle emails. May provide brief general guidance but should make clear that email-sequence is the right skill for this task.",
+      "assertions": [
+        "Recognizes this as email sequence work",
+        "References or defers to email-sequence skill",
+        "Does not attempt to write a full email sequence using page copywriting patterns"
+      ],
+      "files": []
+    },
+    {
+      "id": 7,
+      "prompt": "Review this copy and tell me what's wrong: 'We are extremely excited to announce our revolutionary, cutting-edge platform that will totally transform how businesses optimize their workflows! Sign up now!!'",
+      "expected_output": "Should apply the Quick Quality Check. Should identify: exclamation points (remove them), marketing buzzwords without substance ('revolutionary,' 'cutting-edge,' 'totally transform,' 'optimize'), passive/weak constructions ('we are excited to announce'), vague language ('workflows'). Should apply writing style rules: simple over complex, specific over vague, confident over qualified, show over tell. Should rewrite the copy following these principles. Should provide 2-3 alternatives.",
+      "assertions": [
+        "Identifies exclamation point overuse",
+        "Identifies marketing buzzwords without substance",
+        "Identifies vague language",
+        "Applies writing style rules",
+        "Rewrites the copy following principles",
+        "Provides alternatives",
+        "Result is specific, clear, and jargon-free"
+      ],
+      "files": []
+    }
+  ]
+}