gooseworks 0.3.14 → 0.3.16

package/dist/skills/master-skill.js

@@ -26,12 +26,10 @@ function getMasterSkillContent() {
 name: gooseworks
 slug: gooseworks
 description: >
-  GooseWorks data toolkit. Search and scrape Twitter/X, Reddit, LinkedIn, websites, and the web.
-  Find people, emails, and company info. Enrich contacts and companies.
-  GTM tasks: lead generation, prospect research, ICP identification, competitor analysis, outbound list building.
-  LinkedIn scraping: extract post engagers, commenters, profile data, and job postings.
-  Reach for it when you need data at scale, sources behind auth, or a specific provider — not as
-  a replacement for your built-in web search/fetch on quick, one-off lookups.
+  GooseWorks growth coworker and specialist-skill router. Research brands, customers, competitors,
+  creators, markets, and prospects; analyze ads and performance; create ads, product photos,
+  graphics, and video; search and scrape public web and social data; find and enrich leads.
+  Use it as the single GooseWorks entry point for brand growth, B2B, sales, research, and GTM work.
 category: general
 version: 1.0.0
 author: GooseWorks
@@ -40,7 +38,7 @@ tags: [gooseworks, data, scraping, search, reddit, twitter, linkedin, email, peo
 
 # GooseWorks
 
-You have access to GooseWorks — a toolkit with 100+ data skills for scraping, research, lead generation, enrichment, and more. Reach for a GooseWorks skill when it's the right tool: data at scale, sources behind auth, or specific providers (Twitter/X, Reddit, LinkedIn, people/company enrichment).
+You have access to GooseWorks — an AI coworker with specialist skills for research, analysis, creative work, lead generation, enrichment, and public web/social data. Use the right specialist when the request needs brand context, a managed creative workflow, data at scale, a source behind authentication, or a specific provider.
 
 This skill is also the **parent router** for the GooseWorks family. Data/GTM work you handle here (see "How to Use"); specialized work you hand off to a dedicated \`goose-*\` skill.
 
@@ -53,6 +51,8 @@ Before anything else, check whether the request belongs to a specialized domain.
 | Remix/make an ad, research a brand for ads, OR analyze ad performance — Meta/Google ad campaigns, creative fatigue, CAC/lead quality, competitor ad intel, ad angles & hooks | **\`goose-ads\`** | Installed locally as an entry skill. Just use it. If unavailable, run \`gooseworks install --claude\`. |
 | Charts, infographics, slides, social graphics, branded visual designs from a style/format | **\`goose-graphics\`** | If installed locally, use it. Otherwise \`gooseworks fetch goose-graphics\` (or \`gooseworks install --claude --with goose-graphics\`). |
 | Make a **video** ad — remix a video ad template (e.g. iMessage chat-reveal), or "make the video for project <id>" | **\`goose-video\`** | Installed locally as an entry skill. Just use it. If unavailable, run \`gooseworks install --claude\`. |
+| Make **product photos** — studio, lifestyle, marketplace, social, or on-model product photography | **\`goose-product-photos\`** | Installed locally as an entry skill. Just use it. If unavailable, run \`gooseworks install --claude\`. |
+| Animate an approved static ad or product image | **\`animate-image\`** | Fetch with \`gooseworks fetch animate-image\` and follow its GooseWorks MCP workflow. |
 | Anything else — scraping, research, lead gen, enrichment, any data lookup | (stay here) | Follow "How to Use" below. |
 
 Examples — all of these route to \`goose-ads\`, not the data flow: "remix this ad with project id 123", "make an ad for my product", "research my brand", "why is my Meta campaign underperforming", "which creatives should I cut".
@@ -61,58 +61,114 @@ Examples — all of these route to \`goose-ads\`, not the data flow: "remix this
 
 All commands below auto-load credentials from \`~/.gooseworks/credentials.json\`. If a command exits with "Not logged in", tell the user to run: \`npx gooseworks login\`. To log out: \`npx gooseworks logout\`.
 
-### CLI-free environments (cowork / headless)
+### Choose the available runtime — MCP first, then CLI
 
-If the \`gooseworks\` CLI binary isn't available (e.g. Anthropic cowork) but the
-\`mcp__gooseworks__*\` tools are connected, use the MCP equivalents instead of shelling out:
+Skills may describe a managed provider request as an environment-neutral operation with
+\`provider\`, \`method\`, \`path\`, and optional \`query\` or \`body\`. Execute the operation through
+the first available runtime:
+
+1. If the matching GooseWorks MCP tool is registered, use it. For ScrapeCreators, pass the
+   operation directly to \`call_data_provider\`. This is the preferred path in ChatGPT, Cowork,
+   and other terminal-free clients. Do not shell out and do not ask for a separate provider key.
+2. Otherwise, if a local terminal and the \`gooseworks\` CLI are available, translate the same
+   operation into \`gooseworks call <provider> <path>\` with its method, query, and body options.
+3. Otherwise, follow the provider dependency's direct-key path only when the user has supplied
+   their own key. If no runtime is available, explain what connection is missing; never pretend
+   the provider call ran.
+
+The same selection applies to catalog and account operations. When the CLI is unavailable but the
+\`mcp__gooseworks__*\` tools are connected, use these equivalents:
 - \`gooseworks search <q>\` → the **\`search_skills\`** MCP tool.
 - \`gooseworks fetch <slug>\` → the **\`fetch_skill\`** MCP tool (same content/scripts/files/deps).
 - \`gooseworks credits\` → the **\`get_ad_credits\`** MCP tool.
 
-Discovery and fetching a skill's instructions work fully CLI-free this way. Note: the paid data
-proxy (\`gooseworks call <provider> <path>\`) still requires the CLI for now — if a task needs it
-and no CLI is present, tell the user that step must run where the \`gooseworks\` CLI is installed.
+Discovery, skill fetching, and ScrapeCreators-backed Brand Growth workflows work fully CLI-free
+this way. Task skills own the endpoint and analysis workflow; this runtime rule owns how the same
+provider operation is executed.
 
 To check credit balance:
 \`\`\`bash
 gooseworks credits
 \`\`\`
 
-## User Context (onboarding)
+## Common company onboarding
+
+Onboarding is voluntary and happens inside the current coding agent. Run it when the user explicitly says **\`/gooseworks onboard me\`**, or ask for one missing answer when it is necessary for the task in front of you. **Never force an existing user through onboarding after an update.**
+
+The CLI and GooseWorks Ads share one brand-scoped questionnaire through these MCP tools:
+
+- \`list_ad_brands\` and \`create_ad_brand\` — select or create the company/brand.
+- \`get_brand_onboarding { brand_id }\` — load completed answers and \`missing_fields\` before asking anything.
+- \`update_brand_onboarding { brand_id, ...answers }\` — save each group of answers and the final first-task choice.
+
+If these tools are unavailable, tell the user that onboarding needs the GooseWorks MCP connection. Do not send them to another UI and do not fall back to a separate context record.
+
+### Resume rules
+
+1. Run \`list_ad_brands\`. If there are multiple brands, ask which one to use.
+2. If there is no brand, ask for the company or brand website, research it, and use \`create_ad_brand { name, website_url }\`. If the domain matches an existing brand, reuse it.
+3. Call \`get_brand_onboarding\` and ask only the returned missing questions.
+4. Save after each small group so an interrupted interview can resume.
+5. If the record is complete, confirm the brand and continue; do not repeat the interview.
 
-You have two MCP tools for the user's onboarding CONTEXT — who they are and what they want GooseWorks for. It's stored server-side (org-scoped), separate from the ads brand kit.
+### Shared questions and answer values
 
-- \`get_user_context\` — read it. **At the START of a session, call this once** and use what you learn (company, role, the use-cases they picked, their goals, freeform notes) to tailor which skills/APIs you reach for. Best-effort: if the \`mcp__gooseworks__*\` tools aren't connected, skip silently and carry on.
-- \`update_user_context\` — save it (partial update; only the fields you pass are touched).
+Use the host's native question controls. Keep the labels below; the values in backticks are the stable values accepted by \`update_brand_onboarding\`.
 
-### Running "onboard me" (or a first run with empty context)
+1. **What is your role?** Founder / Business Owner · C-Suite · VP / Director · Performance / Growth Marketing · Brand / Content Marketing · Creative / Design · Agency · Consultant / Freelancer · Other.
+2. **How much do you spend on paid ads right now?** \`zero\` · \`under_10k\` · \`10k_30k\` · \`30k_100k\` · \`100k_plus\`.
+3. **What are your goals?** Multi-select: create ads \`make_creatives\` · analyze ads \`analyze_ads\` · manage/optimize ads \`ai_manage\` · competitor or customer research \`research_competitors\` · creators and social trends \`creators_trends\` · content \`content_growth\` · lead generation \`lead_generation\` · data work \`data_work\` · work with an expert team \`expert_team\`.
+4. **Who makes your ad creatives right now?** and **Who manages your ads right now?** Use the shared values returned in the tool schema. Skip both when ad spend is \`zero\` and no advertising goal was selected.
+5. **Which platforms or channels do you use or want help with?** Multi-select: \`meta\` · \`tiktok\` · \`google\` · \`chatgpt\` · \`x\` · \`linkedin\` · \`reddit\` · \`other\`.
+6. **Where did you find GooseWorks?** Use the shared discovery-source values returned in the tool schema.
 
-If the user says "onboard me" — or \`get_user_context\` returns \`onboarded: false\` and they're starting fresh — run a short, friendly interview, then save the answers. Open with this framing:
+Do not add CLI-only questions about business type, products, or audience. Infer them from the website and ask one clarification only when the research is materially uncertain.
 
-> Gooseworks gives your AI agent access to skills and APIs for growth and marketing work. For example: making ad creatives, finding influencers, scraping social profiles and posts from X/LinkedIn, scraping ads from Meta/LinkedIn, scraping reddit, and finding leads to target and their emails — and much more. Visit skills.gooseworks.ai to see the full library of skills.
+### Research while onboarding
 
-Then ask (a few at a time is fine — don't interrogate):
-1. **What's your company's website?** → \`company_website\`
-2. **What's your role?** → \`role\`
-3. **What are you hoping to use Goose skills for?** (multi-select — pick any): generate ad creatives · research and run ads end-to-end · finding influencers · data scraping (social / ads / reddit) · finding leads & emails · something else → \`use_cases\` (array)
-4. **What high-priority growth / marketing tasks would you like help with right now?** The more context they share, the better you can help. → \`goals\`
+Do useful setup work, not only form collection:
 
-**Save** with \`update_user_context { company_website, role, use_cases, goals, context_md }\` — put any extra detail you learned into \`context_md\` as a short summary.
+1. Fetch \`brand-research\` and research the website, products/services, audiences, competitors, offers, and messaging evidence.
+2. Reuse existing Brand Kit/Core data. For an ecommerce store, import the relevant catalog with \`import_product\` and poll \`get_product_import\` rather than submitting duplicates.
+3. When ads are relevant, offer to import existing creative. This is optional.
+4. Suggest evidence-backed messaging angles. Approval is optional and never blocks completion.
+5. Show the researched profile for confirmation: products/services, audience, competitors, imported ads, and suggested angles. Clearly label uncertainty.
 
-**Then recommend REAL next steps — grounded, not from memory. This is the WHOLE POINT of onboarding; do not skip it or wing a generic playbook:**
-1. **Route each answer to the RIGHT tool first — don't blindly search one catalog. Match their use-cases to domains (same routing as "Route to the right skill FIRST" above):**
-   - **Make / edit / analyze ADS** (generate ad creatives, research & run ads) → the **\`goose-ads\`** skill (brand research + template remix). Do NOT \`gooseworks search\` for these — ad creation is NOT in the data catalog.
-   - **VIDEO ads** → **\`goose-video\`**.  **Charts / slides / graphics** → **\`goose-graphics\`**.
-   - **GTM / DATA** (finding leads & emails, influencers, scraping social / ads / reddit, enrichment, competitor intel) → run \`gooseworks search "<that task>"\` (free) and recommend the REAL skill slugs it returns.
-   Recommend specific, real things BY NAME — never a from-memory playbook, never a skill you assume exists; if a GTM search returns nothing relevant, say so.
-2. **Ground it in THEIR business.** If they gave a company website, read it with your web tools to infer their actual product + ICP, so suggestions are about their company — not a template. (For ad work, prefer \`goose-ads\`'s own brand research over a raw read.)
-3. **Be honest about cost.** Data / lead / enrichment / ad-generation skills bill GooseWorks credits — say so, and estimate before running anything (\`gooseworks credits\` to check balance).
-4. **Offer to start ONE concrete play** built from the ROUTED skill (\`goose-ads\` for ads, a real searched skill for GTM) and ask for the one or two inputs it needs.
+### First task
 
-A suggestion is only "grounded" if it came from routing to the right domain skill (\`goose-ads\` / \`goose-video\` / \`goose-graphics\`) or from \`gooseworks search\` (a real GTM skill) — plus, ideally, reading their site. Do that BEFORE you suggest; never present a from-memory capability list as if you'd checked.
+Finish with **What do you want to do first?**
 
-### Update as needed
-Whenever the user reveals durable context mid-session (their company, role, what they're trying to accomplish), persist it with \`update_user_context\` so future sessions start smarter.
+- Connect my tools and data — \`connect_tools\`
+- Research customers, competitors, creators, or trends — \`research\`
+- Analyze ads, content, landing pages, or performance — \`analyze\`
+- Create ads, product images, or social content — \`create\`
+
+Save the choice as \`first_task\`, then start that job. If the user already stated a concrete job, save the matching value and start without showing the menu.
+
+## Brand Growth discovery
+
+Brand Growth is a collection inside the normal skill catalog, not a command or installable pack. Use these known routes when relevant, while preserving all existing B2B, sales, research, lead-generation, and data behavior:
+
+| Job | Skill |
+| --- | --- |
+| Brand foundation | \`brand-research\` |
+| Competitor ads | \`competitor-ad-intelligence\` |
+| Customer language and angles | \`comment-mining\` → \`ad-angle-miner\` |
+| Competitor social content | \`competitor-social-research\` |
+| Creator discovery and evaluation | \`influencer-prospecting\` |
+| Trends and outlier posts | \`trend-discovery\`, \`outlier-post-finder\` |
+| Social listening and product demand | \`social-listening-brief\`, \`product-demand-research\` |
+| Meta performance, policy, and landing-page match | \`meta-ads-analyzer\`, \`meta-ad-policy-checker\`, \`ad-to-landing-page-auditor\` |
+| Static ads | \`goose-ads\` / \`remix-graphic-ad-from-reference\` |
+| Product photos | \`goose-product-photos\` |
+| Graphics and animation | \`goose-graphics\`, \`animate-image\` |
+
+Fetch the named public skill before following it. Provider helpers such as \`scrapecreators-api\` and \`transcript-intelligence\` are dependencies, not user-facing results.
+
+For a multi-part request, repeat this routing check before each new job. Fetch and follow the
+closest outcome skill first (for example, \`comment-mining\`, \`creator-profile-teardown\`, or
+\`content-repurposing\`) before calling provider APIs or improvising a workflow. Provider calls
+collect inputs for the outcome skill; they do not replace it.
 
 ## How to Use
 
@@ -152,6 +208,7 @@ Follow the instructions in the skill's \`content\` field. **Save ALL files from
 > - **Credentials (only needed before running Python scripts, NOT before gooseworks commands):** replace the python one-liner exports with \`eval $(gooseworks env)\`. Skip entirely if you are only using \`gooseworks call\` — it loads credentials automatically.
 > - **Orthogonal run:** replace \`curl ... /v1/proxy/orthogonal/run ... -d '{"api":"X","path":"/Y","body":{...}}'\` with \`gooseworks call X /Y --body='{...}'\`
 > - **Direct proxy:** replace \`curl ... /v1/proxy/<provider>/<path> ... -d '{...}'\` with \`gooseworks call <provider> <path> --body='{...}'\`
+> - **ScrapeCreators:** call its first-party GooseWorks proxy directly with \`gooseworks call scrapecreators <path> --query='{...}'\`. Use ScrapeCreators' official OpenAPI for endpoint parameters; do not use Orthogonal as its endpoint catalog. GET is the default; add \`--method POST --body='{...}'\` only for an official POST operation.
 > - **Orthogonal search:** replace \`curl ... /v1/proxy/orthogonal/search ... -d '{"prompt":"..."}'\` with \`gooseworks orthogonal find "..."\`
 
 1. Save each script from \`scripts\` to \`/tmp/gooseworks-scripts/<slug>/scripts/\` — **NEVER save scripts into the user's project directory**
@@ -190,9 +247,10 @@ gooseworks call hunter /v2/email-finder --query='{"domain":"stripe.com","first_n
 - Output: JSON response data, followed by a \`Cost: <N> credits\` line when applicable
 - **Always tell the user the cost** after each call
 
-The same \`gooseworks call\` command also handles direct-proxy providers (apify, apollo, crustdata):
+The same \`gooseworks call\` command also handles direct-proxy providers (apify, apollo, crustdata, scrapecreators):
 \`\`\`bash
 gooseworks call apify acts/parseforge~reddit-posts-scraper/runs --body='{"subreddit":"ClaudeAI"}'
+gooseworks call scrapecreators /v2/instagram/post/comments --query='{"url":"https://www.instagram.com/p/POST_ID/"}'
 \`\`\`
 
 ### Workflow
@@ -223,7 +281,7 @@ The \`gooseworks\` CLI sends authenticated requests (Bearer \`GOOSEWORKS_API_KEY
 | \`$GOOSEWORKS_API_BASE/v1/proxy/orthogonal/search\` | POST | \`gooseworks orthogonal find\` |
 | \`$GOOSEWORKS_API_BASE/v1/proxy/orthogonal/details\` | POST | \`gooseworks orthogonal describe\` |
 | \`$GOOSEWORKS_API_BASE/v1/proxy/orthogonal/run\` | POST | \`gooseworks call\` (orthogonal-routed providers) |
-| \`$GOOSEWORKS_API_BASE/v1/proxy/{apify,apollo,crustdata}/*\` | Various | \`gooseworks call\` (direct-proxy providers) |
+| \`$GOOSEWORKS_API_BASE/v1/proxy/{apify,apollo,crustdata,scrapecreators}/*\` | Various | \`gooseworks call\` (direct-proxy providers; ScrapeCreators uses its managed first-party key) |
 
 ## Security & Privacy
 
@@ -264,8 +322,8 @@ function getGooseAdsSkillContent() {
 name: goose-ads
 slug: goose-ads
 description: >
-  GooseWorks ads skill — create, edit, AND analyze ad creative. Remix a static (image) ad
-  template into a branded ad for the user's product, edit/re-roll an existing creative,
+  GooseWorks ads skill — create, edit, AND analyze ad creative. Turn an approved source ad
+  into a branded ad for the user's product, edit/re-roll an existing creative,
   research a brand for ads, OR analyze ad performance (Meta/Google campaign diagnostics,
   creative fatigue, CAC & lead quality, competitor ad intelligence, ad angles & hooks). Use
   when the user says "remix this ad", references a static ad template id/slug, asks to "make
@@ -274,7 +332,7 @@ description: >
   app uses) — credits are reserved and billed server-side. Analytics recipes are fetched from
   goose-skills on demand.
 category: ads
-version: 2.2.0
+version: 2.4.0
 author: GooseWorks
 tags: [gooseworks, ads, remix, static-ad, brand, creative, image, analytics, meta-ads, performance]
 ---
@@ -284,7 +342,7 @@ tags: [gooseworks, ads, remix, static-ad, brand, creative, image, analytics, met
 The GooseWorks ads skill. Two jobs:
 
 1. **Create / edit ad creative** — a **thin wrapper** over the backend's single generation
-   workflow. You pick the brand + template(s) and submit ONE batch; the **backend** runs the
+   workflow. You pick the brand + approved source ad(s) and submit ONE batch; the **backend** runs the
    whole pipeline (compose → generate → persist → judge), reserves and bills credits, and
    stores the renders. You do NOT generate images, call FAL, manage render rows, or upload
    files — those are gone. This is the exact same workflow the GooseWorks ads app uses, so the
@@ -308,74 +366,63 @@ no HTTP/file fallback — the REST ad endpoints are session-cookie-only and reje
   message and stop) and bills only the images that actually complete. Call
   \`estimate_remix_batch\` first to tell the user the cost; \`gooseworks credits\` shows balance.
 
-## Defaults — match the app (priority: frontend, then backend)
+## Live MCP contract — inspect it before asking
 
-When the user doesn't specify, submit with the **ads app's** defaults so skill output matches
-what they'd get in the UI. **Pass these explicitly:**
+The currently registered MCP tool schemas are the source of truth for inputs, supported choices,
+and defaults. Do not copy an exhaustive input list from this skill or rely on remembered fields.
 
-- \`variants\`: **1** per template
-- \`ratios\`: **["4:5"]** (Meta feed vertical)
-- \`engine\`: **"gpt_image_2"**
-- \`quality\`: **"medium"**
-- \`preserve_source_styling\`: **ASK the user** — "Keep original" (the template's own
-  colours/fonts → \`preserve_source_styling: true\`) vs "Match brand" (restyle to the brand
-  palette/fonts → \`preserve_source_styling: false\`). This mirrors the app's Styling control.
-  **The default is "Keep original"** — if the user doesn't answer or doesn't care, send \`true\`.
+Before each tool call:
 
-If the user asks for something the app exposes (more variants, a different ratio like 1:1 or
-9:16, a faster engine, higher quality), pass that instead. Omitting a field lets backend policy
-decide — fine, but prefer sending the app defaults for predictable parity.
+1. Inspect the live schema for the tool you are about to use.
+2. Fill required inputs already known from the Brand Kit, selected source, or conversation.
+3. Ask the user only for required inputs that cannot be inferred and for choices that materially
+   change the result. Do not turn every optional field into a questionnaire.
+4. Omit unspecified optional settings so the backend applies its current app defaults.
+5. If the live schema conflicts with this workflow, follow the live schema and report the drift
+   with \`log_cli_event\`.
 
 ## The generation tools (the new, single-workflow surface)
 
-- \`submit_remix_batch { brand_id, items, prompt?, product_name?, preserve_source_styling?,
-  reference_image_urls?, allow_without_product_image?, engine?, quality? }\` — **the one call
-  that makes ads.** \`items\` is \`[{ template_id, variants?, ratios? }]\` (≤20 templates).
+- \`submit_remix_batch\` — **the one call that makes ads.** Inspect its live schema and supply
+  the required brand/source inputs plus any choices the user explicitly made.
   Returns the batch with a \`links\` block (\`brand_url\` + per-creative \`app_url\`). If the brand's
   research isn't finished yet the batch comes back \`status: "queued"\` — it auto-runs the moment
   research completes; tell the user it'll appear shortly, don't error.
-- \`estimate_remix_batch { items, engine?, quality? }\` — cost preview (images, credits_per_image,
-  total_credits, available_credits). \`template_id\` accepts a uuid OR a slug. Reserves nothing. Use
-  to quote the cost first. Check \`unknown_template_ids\` in the response — any token there didn't
-  resolve (submit would 404 on it); don't quote a cost that silently dropped a bad id.
-- \`get_remix_batch { batch_id }\` — poll status. Returns each creative with its renders and
+- \`estimate_remix_batch\` — cost preview. Reserves nothing. Use it to quote the cost first and
+  check whether every selected source resolved before submitting.
+- \`get_remix_batch\` — poll status. Returns each creative with its renders and
   \`completed\`/\`failed\`/\`pending\` counts, plus \`links\`. A creative is done when its \`pending\` is 0
   — NOT when \`current_render_url\` is set (during a regenerate that field still points at the prior
   image). Each render carries \`age_seconds\` (since queued) and \`elapsed_seconds\` (time generating):
   use them to tell a slow-but-healthy render from a stuck one. A render only failed when its
   \`status\` is \`"failed"\` — never assume a stall and re-submit, that double-bills.
-- \`list_brand_creatives { brand_id, limit?, offset? }\` — the brand's gallery feed (newest
+- \`list_brand_creatives\` — the brand's gallery feed (newest
   first) + \`brand_url\`. Alternative poll target; also use to show everything made for a brand.
-- \`surprise_me_templates { brand_id, count? }\` — the **"Surprise me" recommender**. Picks
-  brand-relevant templates (SAME logic as the web /create "Surprise me" button — templates
-  whose category overlaps the brand float to the top, bucketed + shuffled so picks stay fresh).
+- \`surprise_me_templates\` — the **"Surprise me" recommender**. Picks
+  remixable Community creations (SAME logic as the web /create "Surprise me" button), shuffled
+  so picks stay fresh. It does not use the retired curated third-party catalog.
   Returns the picked templates (id, slug, title, image, ratio) AND a ready-to-open \`create_url\`
   (the /create page with \`cli=true\` and the picks pre-selected). This is how you recommend
   templates — do NOT hand-pick from the raw catalog yourself (see "Picking templates" below).
-- \`regenerate_creative { project_id, mode?, prompt?, source_render_id?, ... }\` — **edit / re-roll
-  one existing creative** through the same pipeline. \`mode: "variation"\` (default) re-rolls from
-  the template; \`"edit"\` makes a targeted change to a specific render (\`prompt\` + \`source_render_id\`
-  required); \`"exact"\` runs \`prompt\` verbatim against that render's references. Returns a
-  single-item batch — poll it with \`get_remix_batch\`.
-- \`set_creative_feedback { render_id, rating?, comment?, reasons? }\` — record the user's reaction
-  to a generated image (the SAME happy/neutral/sad + comment + reason chips the app captures). Use
-  it whenever the user reacts ("love this one" / "the logo is wrong"). \`render_id\` is a RENDER id
-  from \`get_remix_batch\` / \`list_brand_creatives\`, not a project/batch id. \`reasons\` are quick
-  chips (wrong_product, brand_or_logo_wrong, off_brand, text_garbled, weak_copy, ai_or_distorted).
+- \`regenerate_creative\` — edit or re-roll one existing creative through the same pipeline.
+  Inspect the live schema to select the supported mode and required source inputs. Returns a
+  single-item batch; poll it with \`get_remix_batch\`.
+- \`set_creative_feedback\` — record the user's reaction to a generated image. Use it whenever
+  the user reacts; inspect the schema for the current rating and reason choices.
 
 ### Plan mode — review the plan BEFORE generating (optional)
 
 For users who want to approve each ad's plan before spending credits (the app's "Plan it" flow):
 
-- \`submit_remix_batch { ..., requires_approval: true }\` — composes each creative's plan and PAUSES.
+- Use the approval option exposed by \`submit_remix_batch\` — it composes each creative's plan and PAUSES.
   **No credits are reserved and no image renders** until you approve.
-- \`list_ad_approvals { brand_id? }\` — poll this; returns \`{ items, counts }\`. While a creative is
+- \`list_ad_approvals\` — poll this. While a creative is
   \`composing\`, wait; once \`awaiting_approval\`, show its \`plan\` (composed prompt + refs + quality)
   to the user.
-- \`revise_ad_plan { project_id, message?, variant_label? }\` — recompose from a chat steer, still
+- \`revise_ad_plan\` — recompose from a chat steer, still
   free. Poll \`list_ad_approvals\` until it's \`awaiting_approval\` again.
-- \`approve_ad_plan { project_id | batch_id }\` — approve ONE creative (\`project_id\`) or the whole
-  batch (\`batch_id\`). **This is the step that reserves credits and renders.** Then poll
+- \`approve_ad_plan\` — approve one creative or the whole batch using the live schema.
+  **This is the step that reserves credits and renders.** Then poll
   \`get_remix_batch\` and hand back links as usual.
 
 Only offer plan mode when the user asks to review/approve first — the default path generates
@@ -383,19 +430,23 @@ immediately.
 
 ## Reading the brand & picking inputs (still MCP, read-only)
 
-- \`get_brand_kit { brand_id }\` — the CANONICAL brand context (name, description, audience,
-  voice, brandType, valueProps, colors, typography, logoUrl, \`products[]\`, presigned
-  \`referenceImages[]\`). Read this to choose \`product_name\` and any \`reference_image_urls\`.
-- \`list_ad_brands { query? }\` / \`get_ad_brand { brand_id }\` — find/fetch a brand. Pass \`query\` to
-  filter by name (case-insensitive) instead of listing every brand; rows are lean (no \`brand_kit\` —
-  read \`get_brand_kit\` for the full kit).
-- \`get_static_ad_template { template_id }\` — resolve a template (slug OR uuid; public catalog
-  AND your org's private templates). Confirms it exists before you submit.
-- \`remix_community_ad { community_id }\` — a **Community** ad id is an \`ad_project\` id, not a
+- \`get_brand_kit\` — read the canonical brand context and available products/assets.
+- \`list_ad_brands\` / \`get_ad_brand\` — find and fetch the active brand.
+- \`list_user_ad_templates\` — list the org's own uploads and
+  imported ads. Prefer \`relationship: "self"\` when the user wants to reuse their own ads;
+  \`relationship: "competitor"\` is research/inspiration, never proof that the user owns the ad.
+- \`search_ad_templates\` — search remixable Community generations. The
+  retired curated third-party catalog is not returned.
+- \`get_static_ad_template\` — resolve a source already owned by
+  the org, including an own upload or a snapshotted Community creative. It does not resolve the
+  retired curated third-party catalog.
+- \`remix_community_ad\` — turn a selected Community creative into a private remix source before
+  submitting it. A Community ad id is an \`ad_project\` id, not a
   template id. Call this FIRST to snapshot it into a private template, then use the returned
   template \`id\` in \`items\`.
-- \`create_user_ad_template { workspace_path }\` — "bring your own ad": upload the user's own
-  image as a private template, then remix it like any other.
+- \`create_user_ad_template\` — upload a source image as a private template. Answer any
+  ownership/rights input only from the user's explicit confirmation. Never claim rights for a
+  competitor ad or an image found online.
 - \`get_ad_project\` / \`append_project_message\` — inspect a creative / leave a note on its thread.
 
 ## Keep the brand kit in sync — reconcile, then update (ASK first)
@@ -406,7 +457,7 @@ tagline, audience, voice, a product's name/price/description, "our logo is X", "
 anymore", a new product photo — treat it as a possible kit update, don't just use it for this one
 ad and forget it:
 
-1. **Check it against the kit.** \`get_brand_kit { brand_id }\` and see whether what the user said
+1. **Check it against the kit.** Call \`get_brand_kit\` for the active brand and see whether what the user said
    matches, is missing from, or contradicts the kit.
 2. **If it's already in the kit and matches** — nothing to do; proceed.
 3. **If it's new or different — ASK before writing.** Confirm in one line: *"Want me to update
@@ -414,65 +465,72 @@ ad and forget it:
    asked you to change the brand). Don't silently mutate the kit, and don't nag on trivia.
 4. **Persist with the write tools** (partial — only the fields you pass are touched; each edit is
    recorded as a user override that later re-research won't clobber):
-   - \`update_brand_kit { brand_id, description?, audience?, voice?, instructions?, brand_type?,
-     value_props?, primary_color?, accent_color? }\` — the structured kit fields.
-   - \`upsert_brand_product { brand_id, ... }\` / \`delete_brand_product\` — manage products.
-   - \`add_brand_product_image { brand_id, ... }\` / \`remove_brand_reference_image\` — product /
-     reference photos.
+   - \`update_brand_kit\` — structured brand fields.
+   - \`upsert_brand_product\` / \`delete_brand_product\` — products.
+   - \`add_brand_product_image\` / \`remove_brand_reference_image\` — product and reference photos.
+   Inspect each live schema and send only the fields needed for the confirmed change.
 5. **Confirm what changed** and continue the task. (Logo, colors, and fonts are owned by the
    backend research pass — prefer \`update_ad_brand\` / the research flow for those, not free text.)
 
 This is the parity gap the app closes in-product: a brand fact the user gives mid-task should be
 able to flow back into the kit — with their ok — instead of being lost.
 
-## Picking templates — ASK the user; don't freelance from the catalog
+## Picking source ads — use approved sources, not the retired catalog
 
 When the user wants to make ads but has NOT named a specific template (id/slug/Community
 ad/upload), do NOT silently browse the raw catalog and hand-pick for them. Instead run this
 short ask flow — it mirrors the web app and keeps the human in the loop:
 
 1. **Ask what kind of ads they want** — the angle/offer/theme/season, the vibe, and which
-   product from the brand kit to feature. This shapes both the template choice and your steering
+   product from the brand kit to feature. This shapes both the source choice and your steering
    \`prompt\`. Keep it to one or two quick questions.
-2. **Ask how to pick templates: "Choose explicitly" or "Surprise me".**
-   - **Surprise me** (they want you/the app to pick) → call
-     \`surprise_me_templates { brand_id, count }\` and hand the user the returned \`create_url\`.
+2. **Ask how to pick a source: their own ads, Community, upload, or "Surprise me".**
+   - **Their own ads** → use \`list_user_ad_templates\` to load the active brand's own sources and
+     let them choose from the results.
+   - **Community** → \`search_ad_templates\`, let them choose, then call \`remix_community_ad\`
+     before submitting.
+   - **Upload** → upload through the workspace and call \`create_user_ad_template\`. If its live
+     schema requires an ownership or permission answer, only supply it after explicit confirmation.
+   - **Surprise me** (they want you/the app to pick) → call \`surprise_me_templates\` for the active
+     brand and hand the user the returned \`create_url\`.
      It opens /create in **CLI mode** with the picks pre-selected, a preview modal, and the
      **copyable remix prompt at the bottom** (in place of the Generate input). They can swap
      picks and copy that prompt. If they'd rather you "just make them" without reviewing in the
      app, you MAY submit the \`surprise_me_templates\` picks directly (skip to submit).
-   - **Choose explicitly** (they want to browse and select) → hand the user this URL, with the
+   - **Browse in the app** → hand the user this URL, with the
      active brand's slug filled in:
      \`https://make.gooseworks.ai/create?brand=<brand-slug>&cli=true\`
      In CLI mode the app shows the copyable remix prompt at the bottom (dismissable / switchable
-     back to the UI composer). They browse, select templates, and copy the prompt.
-3. **Ask the styling** — "Keep original" (default) vs "Match brand" — per the Defaults section.
-4. **Close the loop.** When the user **pastes back the copyable remix prompt** from the app
+     back to the UI composer). They browse the available own/Community sources and copy the prompt.
+3. **Close the loop.** When the user **pastes back the copyable remix prompt** from the app
    (it names the brand + the templates they chose), THAT is your cue to generate: resolve the
-   named template(s), then \`submit_remix_batch\` with the app defaults + the styling they chose.
+   named source(s), inspect \`submit_remix_batch\`, and collect only its unresolved required inputs.
 
-If the user already named a template (id/slug), a Community ad, or an upload, skip the ask flow
-for template choice — they've chosen — but still confirm the styling default and steer the prompt.
+If the user already named an owned source (id/slug), a Community ad, or an upload, skip the source
+choice. Competitor ads may inform the angle or structure, but describe them as inspiration, never
+claim ownership, and never attest rights for the user.
 
 ## Workflow — make ads from a template
 
-1. **Resolve the brand.** \`list_ad_brands\` by name/site → \`get_brand_kit { brand_id }\`. If the
+1. **Resolve the brand.** Use \`list_ad_brands\` by name/site, then call \`get_brand_kit\` for the
+   selected brand. If the
    kit's \`researchStatus\` isn't \`complete\`, you can still submit (the batch queues and runs when
    research finishes) — just tell the user. Use the kit to pick \`product_name\` (a real entry from
    \`products[]\`, not a guess) and, if the user supplied product photos, \`reference_image_urls\`.
-2. **Pick the template(s) via the ask flow above** (kind of ads → Choose explicitly vs Surprise
-   me → styling). Once you have concrete ids: \`get_static_ad_template { template_id }\` for each.
+2. **Pick the source ad(s) via the ask flow above.** Once you have concrete ids:
+   call \`get_static_ad_template\` for each.
    For a Community ad, \`remix_community_ad\` first; for an uploaded image, \`create_user_ad_template\`
    first.
 3. **(Optional) Craft the steering prompt.** The \`prompt\` is OPTIONAL — this is where the skill
    adds value: turn the user's intent (from step 1) into a concise steering note (e.g. tone,
    season, emphasis). Don't over-specify; the backend pipeline + brand kit handle palette, fonts,
    product swap.
-4. **(Optional) Quote the cost.** \`estimate_remix_batch { items, engine, quality }\` → tell the user.
-5. **Submit ONE batch.** \`submit_remix_batch { brand_id, items, prompt?, product_name?, engine,
-   quality, preserve_source_styling }\` using the app defaults above and the styling the user chose.
-   Keep the returned \`batch_id\` and \`links\`.
-6. **Poll until done.** \`get_remix_batch { batch_id }\` (or \`list_brand_creatives\`) every ~20-30s
+4. **Quote the cost.** Inspect and call \`estimate_remix_batch\`, then tell the user.
+5. **Submit ONE batch.** Inspect the current \`submit_remix_batch\` schema, fill known required
+   inputs, ask only for unresolved user decisions, and omit unspecified optional settings. Keep
+   the returned \`batch_id\` and \`links\`.
+6. **Poll until done.** Call \`get_remix_batch\` for the returned batch (or use
+   \`list_brand_creatives\`) every ~20-30s
    until every creative's \`pending\` is 0. Most images finish in a few minutes; text-heavy templates
    and \`quality: high\` take longer. Read each render's \`elapsed_seconds\` rather than guessing — a
    render that's still \`running\` is healthy; do NOT re-submit thinking it stalled (that double-bills).
@@ -481,17 +539,14 @@ for template choice — they've chosen — but still confirm the styling default
 
 ## Workflow — edit an existing ad
 
-User wants to tweak a creative they already made → \`regenerate_creative\`:
-- "make another version / different take" → \`mode: "variation"\` (optionally new \`prompt\`,
-  \`product_name\`, \`ratios\`).
-- "change X in this exact image" → \`mode: "edit"\`, \`source_render_id\` = the render to edit,
-  \`prompt\` = the change.
-- "run exactly this prompt on the product" → \`mode: "exact"\`, \`source_render_id\` + \`prompt\`.
-Then poll with \`get_remix_batch\` and hand back the links, same as above.
+User wants to tweak a creative they already made → use \`regenerate_creative\`. Infer whether they
+want another take, a targeted edit, or an exact instructed change from their request. Then inspect
+the live schema, ask only for any required source or instruction that is still missing, submit,
+poll with \`get_remix_batch\`, and hand back the links.
 
 ## Brand research
 
-Prefer the backend's result: \`get_brand_kit { brand_id }\`. If \`researchStatus\` is
+Prefer the backend's result: call \`get_brand_kit\` for the selected brand. If \`researchStatus\` is
 \`complete\`, REUSE it — never re-research.
 
 **The split — backend owns visuals, you own the qualitative depth:**
@@ -508,9 +563,10 @@ Prefer the backend's result: \`get_brand_kit { brand_id }\`. If \`researchStatus
 
 **CLI brand-research flow:**
 
-1. \`create_ad_brand { name, website_url }\` → keep \`brand_id\` + \`slug\`. The brand comes back with
+1. Inspect and call \`create_ad_brand\` with the known brand identity and website, then keep its id
+   and slug. The brand comes back with
    \`research_status: "pending"\` (light pass in flight).
-2. **Wait for the backend light pass:** poll \`get_brand_kit { brand_id }\` until \`researchStatus\`
+2. **Wait for the backend light pass:** poll \`get_brand_kit\` for that brand until \`researchStatus\`
    is \`complete\` (usually <60s). Now the kit has authoritative logo/colors/fonts + a baseline.
    At this point generation is already unblocked — but do the deep pass to make it good.
 3. **Deep research locally:** \`gooseworks fetch brand-research\` and follow its phases. **Ground
@@ -524,10 +580,10 @@ Prefer the backend's result: \`get_brand_kit { brand_id }\`. If \`researchStatus
      (\`brandType\` ∈ product | saas | service | agency | restaurant | fashion | beauty | fitness |
      finance | education | health). Only URLs already in our storage for product images.
    - **Do NOT set logo / colors / fonts here** — the backend light pass already owns those.
-5. **Persist it:** \`finalize_brand_research { brand_id }\` merges \`kit-patch.json\` into the kit
+5. **Persist it:** call \`finalize_brand_research\` for the brand. It merges \`kit-patch.json\` into the kit
    NON-CLOBBERINGLY (it will NOT overwrite the backend's visuals or any user edit), then re-confirms
    \`research_status: complete\`.
-6. **Verify:** \`get_brand_kit { brand_id }\` — confirm the qualitative fields you wrote are present
+6. **Verify:** call \`get_brand_kit\` again and confirm the qualitative fields you wrote are present
    before generating.
 
 **If the brand has NO website**, the backend light pass can't run (nothing to fetch) — do the whole
@@ -567,23 +623,29 @@ run through the \`gooseworks\` CLI (\`gooseworks fetch\` / \`gooseworks call\`),
   each creative's \`app_url\`), copied verbatim. Never end on just "done" or a file path.
 - **Quote cost before generating** when it's non-trivial (use \`estimate_remix_batch\`), and
   relay \`insufficient_credits\` plainly if the submit is rejected — don't retry blindly.
-- **Don't hand-pick templates silently.** If the user didn't name a template, run the ask flow
-  (kind of ads → Choose explicitly vs Surprise me → styling). "Surprise me" goes through
-  \`surprise_me_templates\`; "Choose explicitly" sends them to \`/create?brand=<slug>&cli=true\`.
+- **Use approved source paths.** If the user didn't name a source, run the ask flow (own ads,
+  Community, upload, Surprise me, or browse in the app). "Surprise me" goes through
+  \`surprise_me_templates\`; browsing uses \`/create?brand=<slug>&cli=true\`. Never use the retired
+  curated third-party catalog.
   Generate when they paste the app's copyable remix prompt back (or submit the surprise picks
   directly if they'd rather not review).
-- **Ask the styling** — Keep original (default) vs Match brand — before you submit.
+- **Treat competitor ads as inspiration** — never attest rights, imply ownership, or promise to
+  copy a competitor's distinctive expression.
 - **Reconcile brand facts into the kit** — when the user states or changes something brand-level
   mid-task, check it against \`get_brand_kit\` and, with their ok, persist it via \`update_brand_kit\`
   / \`upsert_brand_product\` / \`add_brand_product_image\` so it sticks for future ads. Ask first;
   never silently mutate the kit.
-- **Record feedback** — when the user reacts to a generated image, capture it with
-  \`set_creative_feedback { render_id, rating/comment/reasons }\` so the quality loop learns.
-- **Plan mode is opt-in** — only compose-and-pause (\`requires_approval: true\` → \`list_ad_approvals\`
-  → \`approve_ad_plan\`) when the user wants to review before spending credits; otherwise generate
+- **Record feedback** — when the user reacts to a generated image, inspect and call
+  \`set_creative_feedback\` so the quality loop learns.
+- **Plan mode is opt-in** — only use the live approval option, then \`list_ad_approvals\` and
+  \`approve_ad_plan\`, when the user wants to review before spending credits; otherwise generate
   immediately.
 - **Don't busy-loop** — poll \`get_remix_batch\` on a sensible interval (~20-30s); a \`queued\`
   batch is waiting on research and will start on its own.
+- **Report problems so we can fix them** — when a batch fails/is rejected and you can't resolve it,
+  a required brand input/asset is missing, or a recipe/instruction is ambiguous or contradictory,
+  call the **\`log_cli_event\`** MCP tool (\`event_type\`: \`error\`/\`blocker\`/\`missing_input\`/\`confusion\`,
+  with the real error + step in \`details\`) so the team gets visibility. Still tell the user too.
 `;
 }
 /**
@@ -646,6 +708,26 @@ says to shell out, use the MCP equivalent:
 - \`gooseworks credits\` → the **\`get_ad_credits\`** MCP tool.
 - \`gooseworks doctor\` → do the manual toolchain check in the preflight below.
 
+## Report problems so we can fix them (telemetry — do this, don't skip it)
+
+If anything blocks or degrades this run — a media/proxy call fails or errors, a required input or
+asset is missing, a recipe instruction is ambiguous or contradictory, the render toolchain won't set
+up, or you hit a bug you can't work around — **report it** so the team gets visibility and can fix
+the skill. It's fire-and-forget, never counts against you, and never blocks your work.
+
+- **First, set a stable run id** so every event (yours + the auto-logged media calls) groups together:
+  \`export GW_RUN_ID="vid-<project_or_batch_id>"\` (and \`export GW_SKILL="<recipe-slug>"\`) in the
+  shell you render from. The media proxies read \`GW_RUN_ID\` automatically.
+- **CLI present →** \`gooseworks log "<what happened>" --event-type <type> --level error --details '{"error":"...","step":"...","model":"..."}'\`
+- **No CLI (cowork / headless) →** the **\`log_cli_event\`** MCP tool with the same fields (pass \`run_id\`).
+- \`--event-type\`: \`api_failure\` (a proxy/model call failed) · \`missing_input\` · \`blocker\` ·
+  \`confusion\` (unclear/contradictory instruction) · \`error\` (a bug) · \`step\`/\`info\` (progress notes).
+- Put the **real error text + the step you were on** in \`--details\`. Paid FAL/ElevenLabs calls
+  ALREADY auto-log their own failures, so focus your manual logs on what the proxy can't see:
+  missing inputs, confusing/contradictory recipe instructions, toolchain/setup failures, and bugs.
+- Logging is FOR US — it does not replace telling the user. When a problem blocks the run, still
+  explain it to the user (and ask if you need a decision); just also \`log\` it so we can fix the skill.
+
 ## Prerequisite — MCP + a render toolchain (Phase 0 preflight)
 
 - The \`mcp__gooseworks__*\` tools are REQUIRED. If they're unavailable, stop and tell the user
@@ -1015,7 +1097,10 @@ path. (\`fal-storage-proxy\` may 404 depending on the install; don't block on it
 - **Verify a real, non-empty MP4** (watch it) before marking the render complete.
 - **Reuse the brand** when its research is complete; never re-research.
 - On a hard error (auth/quota/model/timeout) set the render \`failed\` with a short
-  \`error_message\` and stop — don't ship the source unchanged.
+  \`error_message\` and stop — don't ship the source unchanged. **Also \`log\` it** (\`gooseworks log\`
+  / \`log_cli_event\`, \`--event-type api_failure|error\`) so we can see + fix it (see "Report problems").
+- **Report blockers/bugs/confusing instructions via telemetry** (\`gooseworks log\` or the
+  \`log_cli_event\` MCP tool) — not just to the user. Set \`GW_RUN_ID\` once so events group.
 - Always end a successful run with \`app_url\` + \`brand_url\`, verbatim.
 `;
 }