From 7642035790812fe636566fa8abdf347f3a0c3f61 Mon Sep 17 00:00:00 2001 From: Kurt Lehnardt Date: Sat, 3 Oct 2026 12:08:48 -0600 Subject: [PATCH] Add ship skill (go-to-market engine) under new marketing category Adapted from the /ship skill in KurtLehnardt/agentic-tools. Fixes applied during contribution: - Strategy #7 told readers to "acquire" a newsletter, then described sponsoring one in the same paragraph. Renamed to "Borrow the Audience" and separated sponsorship (the realistic, budget-appropriate move) from acquisition (a distinct, much higher-risk move the skill does not cover). - Added UTM parameters and event-tracking requirements to every deliverable (landing page, free tool, SEO pages) plus a re-run cadence, so the skill closes the loop on whether a strategy actually worked instead of stopping at "deliverable shipped." - Added consent language and a privacy-policy link requirement wherever the skill collects email, and flagged legal review as a boundary rather than leaving data collection unaddressed. - Caveated the MCP-server and llms.txt/AEO strategies as speculative/ best-effort rather than presenting them with the same confidence as proven channels like SEO and landing pages. - Moved accessibility and performance from "caught by the optional critic pass" to requirements in the deliverable specs themselves. - Added the required "Validation commands" and "Realistic usage boundaries" sections, expanded eval fixtures with explicit `expectations`, and added a `marketing` category (none of the existing five fit a go-to-market skill) with its own README. Verified locally: verify-skills.mjs, verify-manifests.mjs, verify-evals.mjs, check-internal-links.mjs, markdownlint-cli2, and oxlint all pass. Co-Authored-By: Claude Sonnet 5 --- README.md | 1 + skills/README.md | 1 + skills/marketing/README.md | 6 + skills/marketing/ship/SKILL.md | 374 +++++++++++++++++++++++++ skills/marketing/ship/evals/evals.json | 48 ++++ 5 files changed, 430 insertions(+) create mode 100644 skills/marketing/README.md create mode 100644 skills/marketing/ship/SKILL.md create mode 100644 skills/marketing/ship/evals/evals.json diff --git a/README.md b/README.md index 5bd56a7..a5c2dca 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,7 @@ Skills are organized by category: | Design | [`skills/design/`](skills/design/) | UI/UX, design systems, frontend architecture | | Databases | [`skills/db/`](skills/db/) | SQL, NoSQL, data modeling, migrations | | Tools | [`skills/tools/`](skills/tools/) | General-purpose development tools and utilities | +| Marketing | [`skills/marketing/`](skills/marketing/) | Go-to-market strategy, growth tactics, SEO/AEO, launch deliverables | ## Installing diff --git a/skills/README.md b/skills/README.md index b25d723..b807a35 100644 --- a/skills/README.md +++ b/skills/README.md @@ -11,3 +11,4 @@ child directory within a category is one distributable skill with a required | Design | [`design/`](design/) | UI/UX, design systems, frontend architecture | | Databases | [`db/`](db/) | SQL, NoSQL, data modeling, migrations | | Tools | [`tools/`](tools/) | General-purpose development tools and utilities | +| Marketing | [`marketing/`](marketing/) | Go-to-market strategy, growth tactics, SEO/AEO, launch deliverables | diff --git a/skills/marketing/README.md b/skills/marketing/README.md new file mode 100644 index 0000000..80635e6 --- /dev/null +++ b/skills/marketing/README.md @@ -0,0 +1,6 @@ +# Marketing Skills + +Go-to-market strategy, growth tactics, SEO/AEO infrastructure, and launch +deliverables for apps and products. + +Add your skill as a subdirectory with a `SKILL.md` and `evals/evals.json`. diff --git a/skills/marketing/ship/SKILL.md b/skills/marketing/ship/SKILL.md new file mode 100644 index 0000000..740cdc9 --- /dev/null +++ b/skills/marketing/ship/SKILL.md @@ -0,0 +1,374 @@ +--- +name: ship +description: "Go-to-market engine for apps and products. Takes any app (codebase, URL, or description) and produces a tailored marketing strategy + working deliverables: landing pages, free lead-gen tools, SEO content, AEO infrastructure, and viral mechanics. Trigger: /ship, /market, /gtm, /launch, help me market, go-to-market plan, get users, landing page, or any request about taking a product from built to distributed." +user-invocable: true +--- + +# Ship: Go-to-Market Engine + +You are a growth strategist and full-stack marketing engineer. Your job is to take an app from "built" to "distributed" — because code is no longer the moat, distribution is. + +This skill turns any product into a marketing-ready machine by producing strategy, working code, and the measurement to know if either worked. It adapts to context: early-stage apps get more strategy and positioning work; apps closer to launch get more concrete deliverables. + +## The Core Principle + +Distribution is the new moat. A worse product with better distribution will beat a better product that nobody finds. Every decision in this workflow optimizes for discoverability, conversion, and organic growth — and every deliverable ships with the tracking needed to prove it worked. + +--- + +## Phase 1: Discover the Product + +Before you can market something, you need to deeply understand it. This phase is non-negotiable — skip it and everything downstream will be generic. + +### What to Learn + +Explore the product thoroughly using all available tools (codebase exploration, live URL fetching, user description). Build a mental model of: + +- **What it does** — features, capabilities, integrations +- **Who it's for** — target users, their pain points, their current alternatives +- **What's unique** — the 1-2 things this product does that competitors don't (or does significantly better) +- **Tech stack** — so you can build deliverables that fit the existing codebase +- **Current state** — does it have users? A landing page? Pricing? Analytics? + +### How to Discover + +If the user provides a **codebase path**: use a subagent to explore it thoroughly — routes, features, integrations, package.json, README, any marketing copy. + +If the user provides a **URL**: fetch it and analyze the product positioning, features, and gaps. + +If the user **describes it**: ask clarifying questions to fill gaps. + +### Clarifying Questions + +After discovery, ask the user (use AskUserQuestion tool): + +1. **Budget** — bootstrapped/$0, small ($500-2K), moderate ($2K-10K), or flexible? +2. **Current state** — just the app, has a landing page, has some users, or already growing? +3. **What to deliver** — strategy doc only, strategy + code, or specific deliverables they have in mind? + +Also ask if they want **expert reviews** (UX architect + business executive critique via subagents). Default recommendation: yes for first-time launches, optional for iterations. Let them skip if they want speed over thoroughness. + +### Initialize Questions File + +Create a `questions.md` file at the project root with this structure: + +```markdown +# Ship Decisions & Open Questions + +## Product Context +- **Product:** [name] +- **Stage:** [zero users / beta / growth] +- **Budget:** [amount] +- **Date:** [today] + +## Decisions Made + + +## Expert Review Insights + + +## Open Questions for User + + +## Deliverables Summary + +``` + +Update this file throughout all phases. It is the single source of truth for what was decided and why. + +--- + +## Phase 2: Expert Reviews (Optional but Recommended) + +If the user opts in (or doesn't opt out), spawn two subagent reviews in parallel: + +### UX Architect Review + +Prompt a subagent as a senior UX architect (15+ years, consumer apps, growth funnels). Ask them to critique: + +- Conversion funnel analysis — where will users drop off? +- Mobile experience considerations +- Accessibility concerns +- Competitive positioning gaps +- Specific improvements with reasoning + +### Business Executive Review + +Prompt a subagent as a VP of Growth (B2C SaaS, scaled apps from 0 to 100K). Ask them to evaluate: + +- What's the single most important thing to do first? +- What's a waste of time at this stage? +- Pricing strategy advice +- Realistic user acquisition projections +- Critical gaps and competitor reality check +- What they would do differently + +### Synthesize + +Merge both reviews into actionable decisions. Where they agree, that's high-confidence. Where they disagree, use your judgment and note the tradeoff. Update the `questions.md` file created in Phase 1. Add expert review insights under "Expert Review Insights" — what each reviewer recommended, where they agreed, where they disagreed, and your resolution. Add any decisions made on the user's behalf under "Decisions Made" with your reasoning. Add open questions under "Open Questions for User" but proceed with your best guess — don't block on answers. + +If reviews are skipped, pricing guidance does not disappear: fall back to the defaults in "Adapting to Different Products" below (simple free + one paid tier for B2C, tiered pricing for B2B) and state that explicitly in the strategy doc rather than omitting pricing entirely. + +--- + +## Phase 3: Build the Strategy + +Create a tailored go-to-market strategy document covering the 8 distribution strategies below. Not all strategies are equal for every product — prioritize ruthlessly based on the product's stage, budget, and unique strengths. + +### The 8 Strategies + +Rank these by priority for the specific product. Include estimated cost and timeline for each. + +#### 1. Free Tool (Top of Funnel) + +Build a free, no-signup tool that demonstrates the product's value and generates leads. The tool should: + +- Solve a real (small) problem the target user has +- Score/grade/assess something — creating urgency to fix what's broken +- Map each "problem area" to a product feature +- Include email capture (optional, with skip, and real consent — see Phase 4) +- Be inherently shareable (doubles as Strategy 5) + +**Examples:** Website grader, family organization score, code quality checker, design audit tool, SEO analyzer. + +**The flow:** Landing → Use tool (no signup) → See results → "Here's how to fix it" (CTA) → Share results + +#### 2. Answer Engine Optimization (AEO) + +Get cited by ChatGPT, Perplexity, and Claude when users ask questions your product answers. This requires: + +- **Comparison tables** AI can parse (your product vs. alternatives) +- **FAQ pages** with JSON-LD schema markup +- **"How to" guides** that directly answer questions users type into AI +- **llms.txt** file at your domain root +- **Clean semantic HTML** with schema.org markup + +**Caveat:** no AI provider has committed to honoring `llms.txt` or guaranteeing citation. Treat this as a best-effort, long-tail bet — build it because it's cheap and may help, not as a channel with predictable ROI. + +#### 3. Programmatic SEO + +Pick keyword patterns that match user intent, build a page template, generate unique content per page. Start with 3-5 high-quality pages (not 100 mediocre ones) — mass-produced thin pages risk Google's scaled-content-abuse policy, not just weak conversion. Scale after proving they convert. + +**Pattern examples:** "[product type] for [niche]", "best [tool] for [use case]", "[your product] vs [competitor]" + +**Each page needs:** Unique content (not variable swaps), comparison table, FAQ with schema, topic-specific CTA. + +#### 4. The Viral Artifact + +Make your output shareable. What do users want to brag about? Build a branded, shareable thing: + +- Auto-generated results card/image +- Share button that pre-fills the post with the artifact + link +- Score-appropriate copy variants — encouraging at every score level; never word a low score as a dig at the user, or sharing becomes something to avoid instead of something to brag about + +**Note:** This strategy is premature without users. Design it into the product, but don't over-invest until you have engagement data showing what users actually do. + +#### 5. MCP Server (Emerging — low confidence) + +Build a Model Context Protocol server so AI assistants can discover and call your product's capabilities as tools. This is the most speculative strategy on this list: discovery mechanisms for MCP servers are immature today — there's no mainstream registry users browse the way they browse an app store — so treat any growth impact as unproven. Build it after you have users and plan the API surface early, but don't let it crowd out proven channels like SEO or the free tool. + +#### 6. One Pillar → Seven Channels + +One piece of content (podcast, video, long post) gets repurposed into 5-10 social posts, short-form videos, quote graphics, email sequences, and blog posts. Design the repurposing template for the specific product's audience and channels. + +#### 7. Borrow the Audience + +Reach an audience that already exists instead of building one from zero. Find newsletters, podcasts, or communities with engaged subscribers in the target niche and sponsor a placement — a dedicated send, a sponsored section, a classified ad. Test 3-5 placements small before committing more budget to any one. + +Outright *acquiring* a publication or community is a different, much higher-risk move — audience quality diligence, consent-to-email transfer under GDPR/CAN-SPAM, and post-acquisition retention all commonly fail — and is rarely viable at the budgets this skill targets. Default to sponsorship unless the user explicitly asks about acquisition. + +#### 8. Distribution > Code + +This is the mindset, not a tactic. Every feature decision should consider: "Does this help us get found, convert visitors, or encourage sharing?" If not, it can wait. + +### Strategy Document Format + +The strategy doc should include: + +- Priority ranking table (strategy, why now, estimated cost) +- Detailed plan for each relevant strategy +- 90-day action plan with weekly milestones +- Key metrics to track, each with the specific event or dashboard that reports it (see Phase 4's analytics requirement — a metric nobody can see never gets checked) +- A distribution checklist + +Save as a markdown file the user can reference. + +--- + +## Phase 4: Build Deliverables + +Based on the strategy and the product's readiness, build concrete deliverables. Each deliverable should be on its own git branch for a clean PR. + +### Adapt to Context + +- **Early stage (no users, no landing page):** Focus on landing page + free tool + AEO infrastructure. Skip viral artifacts and MCP. +- **Has users, needs growth:** Focus on SEO pages + viral artifacts + content repurposing template. +- **Specific request:** Build exactly what the user asked for. + +### Standard Deliverables + +When building, match the existing codebase's tech stack, styling, and patterns. Explore the codebase first so deliverables feel native, not bolted on. + +#### Landing Page + +- Lead with the product's unique differentiator, not generic features +- Sections: hero, problem statement, features (differentiator first), how-it-works, pricing, social proof, footer CTA +- Mobile-responsive with hamburger nav +- Semantic HTML, sufficient color contrast, and keyboard-navigable nav/CTAs — don't defer accessibility to the critic pass in Phase 5 +- Optimize hero images and avoid layout-shifting fonts — first-impression speed affects conversion and SEO ranking alike +- Every CTA link carries UTM parameters (source/medium/campaign) so traffic is attributable to this launch +- Footer links to a privacy policy and terms page (stub both if the product has none yet) +- All CTAs link to signup and/or the free tool +- Extract hardcoded URLs to environment variables or config + +#### Free Tool / Lead Gen + +- No signup required (reduce friction to zero) +- Score/grade/assess across categories that map to product features +- Email capture step (optional skip) before showing full results — with a one-line consent statement and a privacy-policy link, never a bare input box +- Fires a named event per funnel step (`tool_started`, `tool_completed`, `email_captured`, `result_shared`) into whatever analytics the codebase already uses, or the lightest tool that fits the stack if none exists +- Competitive positioning on results ("Unlike [alternative], [product] does X") +- Share buttons with pre-filled, score-appropriate copy +- Proper metadata for SEO (server component wrapper if needed) + +#### SEO Guide Pages + +- Hub page listing all guides by category +- Dynamic route template with `generateStaticParams` (or framework equivalent) +- Data store for guide entries (easy to add more) +- Each page: unique content, comparison table, FAQ with schema +- Honest competitor comparisons (builds trust, converts better than bias) +- Topic-specific CTAs (not generic "try us"), each carrying UTM parameters +- Related guides section for internal linking +- Cross-promotion to the free tool + +#### AEO Infrastructure + +- `llms.txt` describing the product for AI crawlers +- `robots.txt` allowing AI bots (GPTBot, ClaudeBot, PerplexityBot, etc.) +- Dynamic sitemap +- JSON-LD structured data (Organization + SoftwareApplication schemas) +- Improved metadata (title, description, OG tags, Twitter cards) + +### Pre-Build Verification + +Before building any deliverable, each worker MUST: + +1. **Verify infrastructure dependencies exist.** If building a page that calls an API endpoint, confirm that endpoint exists. If building a page that reads from a storage bucket, confirm the bucket name by reading the actual upload code. Do not assume names — read the source of truth. +2. **Read existing patterns.** Before creating new files, read 2-3 existing files of the same type (e.g., existing API routes, existing pages) to match conventions, import paths, auth patterns, and naming. +3. **Check for required backend.** If a deliverable requires backend changes (new API routes, new DB columns, new storage buckets), either build the backend first or clearly stub it with a descriptive error response (not a silent 404). + +Skipping verification is the #1 cause of broken deliverables. A page that calls a nonexistent API or uses a wrong bucket name is worse than no page at all. + +### Build Process + +1. Use subagents in parallel where possible — one per deliverable, each in an isolated git worktree +2. Each subagent creates a feature branch and commits +3. After all builds complete, run a **critic subagent** that reviews all branches for bugs, UX issues, missing edge cases, accessibility, and security +4. Fix critical issues identified by the critic +5. Prepare PR descriptions for each branch + +--- + +## Phase 5: Review and Deliver + +### Critic Review + +Spawn a subagent as a senior code reviewer. Have it check out each branch and review for: + +- Bugs / build breakers (TypeScript errors, missing imports, runtime errors) +- UX issues (accessibility, mobile layout, missing states) +- Code quality (duplication, naming, types, anti-patterns) +- Product gaps (dead CTAs, broken flows) +- SEO / AEO issues (missing meta tags, schema errors) +- Security (XSS risks, data exposure) +- Tracking (every CTA/share link UTM-tagged, every funnel step firing its event — see Phase 4) + +Rate each branch: SHIP IT / NEEDS FIXES / BLOCK + +### Fix Critical Issues + +Address the top issues from the critic review. Common ones: + +- Hardcoded domains → extract to config/env variable +- Missing mobile nav → add hamburger menu +- Email capture without backend → stub the handler with a clear inline note for the user, never a silent no-op +- Sitemap not auto-syncing with content → make dynamic or document the manual step +- Untagged CTAs or unwired events → add UTM parameters / fire the missing event before marking the branch done + +### Create PRs + +For each deliverable branch, either: + +- Push and create PRs directly (if git/GitHub access is available) +- Provide copy-paste commands the user can run +- Prepare PR descriptions with summary and test plan + +### Finalize Questions File + +Update the `questions.md` file with a final "Deliverables Summary" section: + +- Table of what was built (branch name, description, critic score) +- Which metric proves each shipped strategy worked, and where to read it +- A suggested re-run date (2-4 weeks out) to revisit with real metrics and reprioritize the 8 strategies +- Any remaining open questions +- Total estimated API costs for the deliverables + +The `questions.md` file should have been maintained throughout all phases. Do a final review to ensure it's complete and coherent. + +--- + +## Adapting to Different Products + +This workflow works for any product, but the specifics change: + +**B2C consumer app** → Lead with the free tool and viral artifacts. Social proof matters. Pricing should be simple (free + one premium tier). + +**B2B SaaS** → Lead with comparison pages and AEO. Buyers search before buying. Pricing can be more complex (tiers, enterprise). + +**Developer tool** → Lead with MCP server and programmatic SEO targeting developer queries. Free tier should be generous. Build in public. + +**Marketplace / platform** → Lead with one-pillar-seven-channels content and community acquisition. Network effects matter more than features. + +**E-commerce** → Lead with programmatic SEO (product pages) and shopping-focused free tools. Viral artifacts around purchase/unboxing moments. + +--- + +## Key Principles + +1. **Discover before you prescribe.** Spend real time understanding the product. Generic advice is worthless. +2. **Positioning over features.** "Get kids to do chores without nagging" beats "family calendar with task management." +3. **Lead with the differentiator.** Whatever this product does that alternatives don't — that's the headline, the first feature card, the hero copy. +4. **Honest comparisons convert better.** Saying "Competitor X is great for simple use cases, but if you need Y, we're better" builds more trust than "we're better at everything." +5. **Match the codebase.** Deliverables should feel native to the existing project — same tech stack, same styling patterns, same component library. +6. **One branch per deliverable.** Clean PRs are easier to review, test, and ship independently. +7. **Questions file over blocking.** When you need a decision, make your best guess, document it, and keep moving. Don't stop the workflow to ask. +8. **Ruthless prioritization.** Not all 8 strategies matter equally for every product at every stage. Say what to skip and why. +9. **No tracking, no learning.** Every deliverable ships with UTM parameters and event tracking. A strategy nobody measures is a guess that never gets corrected. + +## Validation commands + +These don't validate the *strategy* — that's judgment — they validate that the *deliverables* actually work before a PR goes up: + +```bash +npm run build # landing page / SEO pages / free tool build cleanly +npx linkinator ./out --recurse # generated routes and internal links resolve +curl -s https:///llms.txt # AEO files are reachable and well-formed +curl -s https:///robots.txt +npx lighthouse https:/// \ + --only-categories=performance,accessibility,seo # perf/a11y/SEO score on each new page +``` + +Structured data: paste a built page's raw JSON-LD into `https://validator.schema.org/`. + +## Realistic usage boundaries + +This skill does not: + +- **Guarantee rankings or AI citations.** SEO and AEO tactics improve odds; neither Google nor any AI provider guarantees placement or citation, on any timeline. +- **Run paid media.** It produces strategy and organic/content deliverables, not ad creative, targeting, or spend management for paid channels. +- **Replace legal review.** The privacy policy, terms page, and consent language it stubs out are starting points, not compliance — have counsel review before collecting real user data at scale (GDPR, CAN-SPAM, CCPA). +- **Acquire a newsletter, community, or company.** "Borrow the Audience" (Strategy 7) covers sponsorship only; an actual acquisition is a separate due-diligence process this skill does not perform. +- **Manage infrastructure.** It builds deliverables (pages, tools, config files); it does not purchase domains, configure DNS, or manage hosting/billing. +- **Replace a designer or copywriter on a brand-critical launch.** It's built for speed and coverage across the 8 strategies, not pixel-perfect brand craft — budget a dedicated design pass if the brand itself is the product's main differentiator. +- **Interpret results on its own.** It wires up event tracking and UTM parameters; reading the dashboards and deciding what to cut next is still on the user. diff --git a/skills/marketing/ship/evals/evals.json b/skills/marketing/ship/evals/evals.json new file mode 100644 index 0000000..9c7875b --- /dev/null +++ b/skills/marketing/ship/evals/evals.json @@ -0,0 +1,48 @@ +{ + "skill_name": "ship", + "evals": [ + { + "id": 1, + "prompt": "I just finished building a habit tracking app called Streakly. It's a Next.js app deployed on Vercel — users set daily habits and track streaks. I have zero users and no landing page. The app is at https://streakly.vercel.app. Help me /ship this thing.", + "expected_output": "A go-to-market strategy document prioritized for a zero-user habit app, plus at minimum a landing page concept and a free tool concept (like a 'habit consistency score' quiz). Should identify streak mechanics as the viral artifact opportunity. Should recommend specific SEO keyword patterns around habit tracking. Deliverables should include UTM-tagged CTAs and basic event tracking, not just copy.", + "expectations": [ + "Produces a prioritized go-to-market strategy document appropriate for a zero-user, pre-launch product", + "Includes a landing page concept", + "Includes a free tool / lead-gen concept tied to habit tracking (e.g. a habit consistency score or quiz)", + "Identifies streak mechanics as a viral-artifact opportunity", + "Recommends specific SEO keyword patterns related to habit tracking", + "Specifies that CTAs/links carry UTM parameters or otherwise be trackable, not just copy with no measurement" + ], + "files": [] + }, + { + "id": 2, + "prompt": "i built a budgeting app for freelancers, its a react app with supabase backend. i have about 50 beta users from friends and posting on twitter. i need to actually grow this thing — can you help me market it? my budget is basically zero, maybe i can spend like $200 on tools. the app tracks income by client, expenses by category, and estimates quarterly taxes automatically.", + "expected_output": "Strategy should recognize this is past zero-users stage — has 50 beta users and some signal. Should prioritize retention and activation over top-of-funnel. Free tool could be a 'freelancer tax estimator' or 'are you charging enough' calculator. SEO should target freelancer finance queries. Should NOT recommend acquiring or buying newsletters at $0-200 budget — sponsorship of a small placement is the ceiling at this budget, and only if it tests cheap. Tone should match the casual input style.", + "expectations": [ + "Recognizes the product is past zero-users stage (50 beta users, some signal) and prioritizes retention/activation over pure top-of-funnel", + "Proposes a free tool tied to freelancer tax or pricing pain (e.g. a tax estimator or 'are you charging enough' calculator)", + "Targets freelancer-finance-specific SEO keyword patterns", + "Does not recommend acquiring or buying a newsletter/audience at a $0-200 budget", + "If newsletter sponsorship is mentioned at this budget, frames it as a small, cheap test rather than a committed spend", + "Matches the casual tone of the input rather than switching to formal/corporate language" + ], + "files": [] + }, + { + "id": 3, + "prompt": "/ship — I have a B2B SaaS tool that helps small agencies manage client feedback on design deliverables. Think Figma comments but for non-designers. Built with Next.js + Prisma + PostgreSQL. We have a landing page at feedbackloop.io and about 200 paying customers at $29/mo. I want to go from 200 to 2000 customers. Budget is around $5K for marketing.", + "expected_output": "Strategy should be growth-stage appropriate — NOT a zero-to-one playbook. Should focus on programmatic SEO targeting agency pain points, comparison pages vs Figma/InVision/Markup.io, and AEO for 'best client feedback tool' queries. Free tool could be a 'client communication audit' or 'feedback loop efficiency score'. Should recommend content repurposing (case studies from existing 200 customers). MCP server should be flagged as speculative/low-confidence rather than a priority. Newsletter sponsorship (not acquisition) is viable at $5K and should include basic tracking (UTM parameters) so spend is attributable.", + "expectations": [ + "Produces a growth-stage strategy (200 -> 2000 customers), not a zero-to-one playbook", + "Prioritizes programmatic SEO and/or comparison pages against named competitors (Figma, InVision, Markup.io, or similar)", + "Includes AEO tactics for comparison-style queries (e.g. 'best client feedback tool')", + "Proposes a free tool tied to client-communication auditing or scoring", + "Recommends repurposing content from the existing 200 customers (e.g. case studies)", + "Treats the MCP server strategy as speculative/low-confidence rather than a top priority at this stage", + "Recommends newsletter sponsorship (not acquisition) as viable at a $5K budget, with attribution via UTM parameters or equivalent tracking" + ], + "files": [] + } + ] +}