anymorph 0.4.0 → 0.6.0

package/dist/skillpacks/geo/shared/vertical-playbooks/commerce.md

@@ -1,65 +0,0 @@
-# Commerce SEO/GEO/AEO Playbook
-
-## Scope
-
-Reusable guidance for ecommerce and consumer goods outside beauty-specific use cases. Use this for vertical strategy, diagnosis, and page planning.
-
-## Entity And Demand Patterns
-
-- Map demand across category, subcategory, product type, product family, SKU, and variant.
-- Common patterns: `category x use case`, `product type x audience`, `product x comparison`, `product x review`, `product x problem/compatibility`, and `SKU/model x spec/fit/size/material`.
-- Category pages are broad-intent assets. PDPs are exact product entity assets. Buying guides, comparisons, and reviews are decision-stage assets.
-- Variant pages and feeds are evidence layers for size, color, material, bundle, price, availability, and compatibility.
-- Prefer stable identifiers: brand, MPN, GTIN/EAN/UPC, SKU, model, and variant group.
-
-## Search And AI Surfaces
-
-- Web results, product rich results, merchant listings, shopping tabs, image/visual search, local inventory, retailer search, marketplace search, and AI answers that synthesize product and review content.
-- The same product should be understandable from page HTML, structured data, and feed data.
-- AI visibility is indirect and not guaranteed. The safest approach is crawlable, unique, evidence-backed product content plus fresh structured commerce data.
-- Owned pages, feeds, and marketplace/retailer listings should reinforce the same product entity facts.
-
-## Asset Plays
-
-- Category x use-case pages: pair category terms with real jobs-to-be-done, occasions, constraints, and product routing.
-- PDP upgrades: exact title, core attributes, specs, compatibility, materials, dimensions, images, shipping, returns, price, stock, reviews, and schema.
-- SKU-level evidence: publish model/SKU/GTIN/MPN where available and keep identifiers consistent across owned and syndicated surfaces.
-- Product schema and merchant listings: use Product/Offer data that matches visible content. Use variant grouping for product families.
-- Faceted navigation: control filters, sorts, and parameter URLs. Index only useful, distinct, demand-backed pages.
-- Variant strategy: define single PDP vs variant URL handling, canonicalization, inventory state, and ProductGroup data where appropriate.
-- Product feeds: maintain feed hygiene for large, fast-changing, or high-variant catalogs.
-- Reviews: support customer, expert, and editorial reviews with firsthand evidence, measurements, pros/cons, and best-fit context.
-- Comparison and buying guides: `best for X`, `A vs B`, `best under Y`, and `what to choose if Z`, with clear links to PDPs and category hubs.
-- Images/video: show the actual product, scale, setup, fit, usage, and variant differences.
-
-## Evidence And Claim Safety
-
-- Prefer verifiable attributes over persuasion copy.
-- Separate fact from marketing language.
-- Only claim specs, compatibility, performance, material, certifications, warranty, or `best for` statements when evidence exists.
-- Regulated or high-risk goods need separate review: supplements, OTC drugs, alcohol, nicotine, medical devices, children’s products, electronics safety, automotive parts, and sustainability claims.
-- Comparisons and guides need measurements, criteria, firsthand observations, and explicit tradeoffs.
-- Keep page, schema, feed, and retailer facts synchronized.
-- Freshness-sensitive facts include price, availability, shipping, returns, sale windows, inventory, policy details, out-of-stock, discontinued, backorder, and promo states.
-- If reviews or comparisons monetize outbound links, keep disclosures and link handling compliant.
-
-## Measurement Signals
-
-- Indexation and crawl coverage for categories, PDPs, and variant pages.
-- Product rich result and merchant listing eligibility, errors, and warnings.
-- Feed disapprovals, mismatch rates, attribute completeness, and freshness latency.
-- Impressions/clicks by category, use-case, comparison, PDP, and SKU query classes.
-- PDP conversion, add-to-cart, category-to-PDP CTR, and marketplace/retailer share.
-- Review coverage, rating volume, product identifier coverage, and valid schema coverage.
-- AI mention, owned citation, cited source mix, and branded query lift after guide/review publication.
-
-## Anti-Patterns
-
-- One thin PDP template repeated across many SKUs.
-- Category pages that are only product grids.
-- Query-fanout pages for every wording variation.
-- `Best` or review pages with no firsthand evidence, measurements, or tradeoffs.
-- Variant facts hidden behind JS selectors or collapsed product families.
-- Price, stock, shipping, or return mismatches between page, schema, feed, and retailer.
-- Missing or unstable product identifiers across syndication channels.
-- Treating GEO/AEO as separate from product data quality, crawlability, and evidence.

package/dist/skillpacks/geo/shared/vertical-playbooks/ota.md

@@ -1,62 +0,0 @@
-# OTA / Travel SEO/GEO/AEO Playbook
-
-## Scope
-
-Reusable guidance for OTA, travel marketplace, destination, lodging, tour, and things-to-do businesses. Use this for vertical strategy, diagnosis, and page planning.
-
-## Entity And Demand Patterns
-
-- Travel demand mixes entity-led planning with date, price, availability, route, and booking-led transactions.
-- Core entities: destination, neighborhood, property, operator, attraction, route, itinerary, traveler type, season, event, availability, price, review, and policy.
-- Durable patterns include `destination x traveler type`, `destination x use case`, `destination x season`, `destination x trip length`, `destination x things-to-do`, `destination x where-to-stay`, and `property/tour x availability + price + review`.
-- Best travel pages connect entities across trip planning, local context, inventory, and booking instead of treating keywords as isolated posts.
-
-## Search And AI Surfaces
-
-- Web results, maps/local packs, rich results, review surfaces, partner/affiliate listings, tourism boards, and AI travel-planning answers.
-- Travel planning pages should answer: who it is for, when to go, how long to spend, what to do in order, where to stay, cost assumptions, what is included, and what may be unavailable or seasonal.
-- Strong travel content is specific, itinerary-shaped, comparison-friendly, source-aware, and explicit about freshness and uncertainty.
-- Maps/local visibility is part of SEO for physical travel entities, not a separate concern.
-
-## Asset Plays
-
-- Destination hubs: neighborhoods, attractions, maps, audience fit, seasonality, and links to stays/tours/itineraries.
-- Itinerary pages: common durations, ordered plans, timing, transport, tradeoffs, alternatives, and booking modules.
-- Things-to-do pages: attraction entities with hours, access, cost/free status, location, seasonality, and best-fit traveler types.
-- Where-to-stay pages: neighborhood fit, accommodation types, budget bands, transit access, practical considerations, and inventory links.
-- Property/tour pages: price, availability, amenities, images, geo, cancellation, inclusions, exclusions, and review evidence.
-- Local readiness: name, address, geo, hours, category, business details, review signals, and profile consistency.
-- Partner/affiliate surfaces: keep names, location data, inventory facts, ratings, images, and policies consistent across syndicated listings.
-
-## Evidence And Claim Safety
-
-- Never publish stale availability or stale prices as if live.
-- Label prices, taxes, mandatory fees, `from` pricing, seasonal ranges, currency, cancellation terms, and uncertain timing clearly.
-- Distinguish live, feed-supplied, estimated, seasonal, and stale facts.
-- Separate evergreen editorial guidance from volatile booking facts.
-- Structured data must match visible page content and page purpose.
-- Do not mark up hidden, fake, misleading, or irrelevant review content.
-- Distinguish editorial recommendation, user review, partner-supplied fact, live feed fact, and estimated itinerary timing.
-- Safety content should use sourced, dated practical considerations. Do not declare areas categorically safe or unsafe without authoritative sourcing and review.
-- Use Google Business Profile, VacationRental, and things-to-do markup/feed concepts only when the tenant is eligible and the data matches visible content.
-- Freshness-sensitive facts include availability, hours, closures, seasonal access, review dates, policy changes, taxes, fees, inclusions, and cancellation terms.
-
-## Measurement Signals
-
-- Destination, itinerary, things-to-do, and where-to-stay impressions.
-- Indexation and rich-result coverage for key entity pages.
-- Booking conversion, inventory clickthrough, partner outbound CTR, and assisted conversions.
-- Map/profile visibility, direction/call/website actions, review volume, rating, and reply rate.
-- Freshness coverage for price, availability, hours, and policy fields.
-- AI mention, owned citation, itinerary answer inclusion, and cited source mix.
-
-## Anti-Patterns
-
-- Thin `best things to do` pages with no entity depth.
-- Destination pages with no traveler, season, or use-case segmentation.
-- Generic itinerary copy reused across destinations.
-- Mixing evergreen advice with stale booking facts.
-- Schema that does not match visible content.
-- Review markup without trustworthy visible reviews.
-- Hiding fees, blackout periods, closures, or booking constraints.
-- Contradictory partner and first-party listings.

package/dist/skillpacks/geo/shared/vertical-playbooks/saas.md

@@ -1,64 +0,0 @@
-# SaaS SEO/GEO/AEO Playbook
-
-## Scope
-
-Reusable guidance for B2B SaaS and software-led subscription businesses. Use this for vertical strategy, diagnosis, and page planning. Keep tenant-specific positioning and bets in `agent/STRATEGY.md`.
-
-## Entity And Demand Patterns
-
-- SaaS demand is entity-led: category, problem, role, workflow, use case, feature, integration, competitor, pricing model, security standard, and deployment model.
-- Map demand by buying stage: problem, use case, workflow, integration, evaluation, validation, implementation, and support.
-- Common patterns: `role x problem`, `workflow x tool`, `integration x integration`, `feature x use case`, `competitor x alternative`, `category x industry`.
-- Treat docs, integrations, trust pages, and comparisons as demand capture assets, not only support material.
-- Build pages that stand alone for users and search systems: clear scope, crawlable text, explicit product facts, stable terminology, self-contained answers, and proof near claims.
-
-## Search And AI Surfaces
-
-- Web search, AI answer surfaces, Bing/Copilot-style citation layers, review platforms, docs, help centers, changelogs, trust centers, and status/security pages.
-- Review platforms such as G2, Capterra, TrustRadius, and analyst-style marketplaces influence validation and external authority.
-- Documentation can capture high-intent implementation queries and assist activation when it links to product value and next steps.
-- AI search experiences may synthesize information from multiple indexed sources. Make product facts crawlable, current, and unambiguous, but do not assume any specific page type will be cited.
-
-## Asset Plays
-
-- Category pages: define the category, who it is for, differentiation, proof, pricing path, and links to deeper assets.
-- Problem pages: explain pain, root causes, measurable outcomes, and product fit. Avoid generic thought leadership.
-- Use-case pages: role, industry, scenario, inputs, outputs, success metrics, and examples.
-- Workflow pages: before/after process, systems touched, time/risk savings, and fit constraints.
-- Integration pages: what connects, triggers/actions, setup path, limitations, related docs, and adjacent integrations.
-- Alternative/comparison pages: objective criteria, current facts, tradeoffs, methodology, and buyer-help framing.
-- Docs-assisted activation: prerequisites, architecture notes, examples, demos, templates, and product pathways.
-- Trust pages: verified security, privacy, compliance, and admin-control facts with artifact paths. Do not list controls or certifications unless currently supported.
-- Proof assets: case studies, testimonials, review profiles, benchmarks, analyst mentions, and compliant review coverage/recency.
-
-## Evidence And Claim Safety
-
-- Attribute substantive claims to first-party product facts, public docs, customer evidence, third-party reviews, benchmarks, or trust artifacts.
-- Separate product facts from positioning. `Supports SAML SSO` is not the same as `best enterprise security`.
-- Comparison claims must be truthful, current, non-deceptive, and clear about methodology.
-- Do not imply certifications, integrations, customer logos, uptime, ROI, feature parity, or compliance posture without proof.
-- Security, compliance, privacy, and regulated-industry claims need an artifact path: trust center, policy page, release note, support doc, or certification.
-- Do not claim AI capability, autonomy, accuracy, compliance suitability, legal/medical/security adequacy, or productivity gains without product evidence and disclaimers.
-- Pricing, plan limits, edition availability, API limits, add-ons, and enterprise-only capabilities must match product docs and pricing pages.
-- Use careful ROI language. Prefer scenarios, ranges, and case-backed examples over universal promises.
-- AI-assisted content needs human editorial control; scaled low-value SaaS pages are a quality risk.
-
-## Measurement Signals
-
-- Indexation and crawl health by page type.
-- Non-brand impressions and rankings for category, problem, integration, workflow, and comparison intents.
-- AI citation, supporting-link appearance, and answer inclusion for tracked prompts.
-- Demo/trial starts, product-qualified signups, qualified pipeline, and win-rate influence.
-- Docs-to-signup assists, docs-to-demo assists, docs CTA CTR, and activation by doc cluster.
-- Review-platform completeness, rating, review coverage, recency, representativeness, and compliant solicitation.
-- Trust-page engagement and enterprise conversion assists.
-
-## Anti-Patterns
-
-- Thin `best X`, industry, or city pages with no real differentiation.
-- Treating GEO as separate from crawlability, canonical hygiene, and helpful content.
-- Hiding product facts behind JS, login walls, PDFs, or vague marketing copy.
-- Attack-style comparison pages.
-- Docs that rank but never route users to activation.
-- Security or compliance claims without proof paths.
-- Schema, AI text generation, or review widgets used as shortcuts to trust.

package/dist/skillpacks/geo/skills/brand-owned-diagnosis/SKILL.md

@@ -1,54 +0,0 @@
----
-name: brand-owned-diagnosis
-description: Use when diagnosing customer-owned discovered pages for GEO strategy actions, owned-site visibility gaps, content coverage issues, or technical page fixes.
----
-
-# Brand-Owned Diagnosis
-
-Use this skill for customer-owned pages that are not Anymorph-generated GEO pages.
-
-The output is a compact diagnosis plus action candidates for `assetType="brand_owned"`.
-
-## Scope
-
-Diagnose:
-
-- Existing brand-owned page coverage.
-- Content clarity, proof, comparison, and entity gaps.
-- Technical or crawl blockers on customer-owned pages.
-- GSC, SERP, AI response, and competitor gaps tied to a known owned URL.
-
-Do not propose:
-
-- Generated GEO page work.
-- Third-party outreach or external profile work.
-- New page generation when an existing generated GEO page is the right surface.
-
-## Workflow
-
-Read these references before producing proposals:
-
-- `references/workflow.md` for the full brand-owned product workflow, candidate rules, root causes, action families, scoring, and no-action cases.
-- `references/diagnosis-contract.md` for the exact runtime diagnosis contract and artifact submission shape.
-
-1. Read shared run context and the brand-owned candidate slice.
-2. Use `list_brand_owned_candidates` before broad SQL.
-3. Use `get_geo_intent_diagnostic` for intent-level explanation.
-4. Read page content or source only when the recommendation depends on the body or technical implementation.
-5. Return accepted proposals, rejected candidates, and no-action rationale.
-
-## Output Contract
-
-Return proposals that can be merged into final GEO actions.
-
-Each proposal should include:
-
-- intent or proposed intent.
-- existing page URL or page id when known.
-- root cause.
-- operation family.
-- priority and confidence.
-- evidence references.
-- concise change brief.
-
-Use no action when the owned page is not the bottleneck.

package/dist/skillpacks/geo/skills/brand-owned-diagnosis/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Brand-Owned Diagnosis"
-  short_description: "Diagnose customer-owned pages for GEO strategy actions."
-  default_prompt: "Use $brand-owned-diagnosis to diagnose owned-page GEO gaps for this workspace."

package/dist/skillpacks/geo/skills/brand-owned-diagnosis/references/diagnosis-contract.md

@@ -1,95 +0,0 @@
-# GEO Strategy: Brand-Owned Diagnosis
-
-You diagnose customer-owned discovered pages.
-
-## Scope
-
-Work only on pages where the tenant/customer site owns the page and the page is not an Anymorph-generated GEO page.
-
-Cases:
-
-- page exists but visibility is low
-- page is cited but the brand is not mentioned
-- brand is mentioned but not recommended
-
-Do not propose GEO page generation unless the orchestrator explicitly asks you to compare update-vs-create.
-
-## Evidence Order
-
-Use the cheapest sufficient evidence.
-
-1. Common run context and candidate rows from the orchestrator.
-2. `list_brand_owned_candidates` for the first brand-owned candidate slice.
-3. `get_geo_intent_diagnostic` for one intent before deeper checks.
-4. `get_page_insights` default compact mode for page decision evidence; use `mode: "full"`, `get_page_visibility`, or `list_ai_responses` only when raw evidence changes the recommendation.
-5. `get_page_content` only when content or technical diagnosis depends on the page body.
-6. `web_scrape` only for a specific competitor URL that changes the recommendation.
-
-Do not scrape broadly.
-
-## Root Cause Buckets
-
-Allowed buckets:
-
-- `intent_coverage_gap`
-- `content_depth_gap`
-- `entity_clarity_gap`
-- `generic_content_gap`
-- `proof_gap`
-- `comparison_gap`
-- `technical_issue`
-- `authority_gap`
-- `prompt_mismatch`
-- `not_a_problem`
-- `insufficient_evidence`
-
-Use `authority_gap` only with external citation evidence or repeated competitor recommendation reasons.
-
-## Action Families
-
-Allowed families:
-
-- `update_existing_page`
-- `retarget_existing_page`
-- `merge_or_redirect_page`
-- `no_action`
-
-Keep specific fixes such as proof, entity clarity, comparison coverage, and technical repairs in `rootCauses` and `operations`, not as separate action families.
-
-## Output
-
-Produce one `brand_owned` diagnosis object in this shape.
-
-Do not write intermediate diagnosis JSON files directly.
-
-Do not include `workspaceId`, `runId`, `channel`, final action id, or final `assetType`; the orchestrator can derive them.
-
-Use this shape:
-
-```json
-{
-  "summary": "Short diagnosis.",
-  "proposals": [
-    {
-      "intentId": "intent_123",
-      "candidateType": "page_exists_low_visibility",
-      "target": { "pageId": "page_123", "url": "https://example.com/page" },
-      "rootCauses": [
-        { "bucket": "proof_gap", "confidence": 0.72, "evidence": ["Specific evidence summary"] }
-      ],
-      "actionFamily": "update_existing_page",
-      "operations": ["Add customer proof near the answer block"],
-      "priority": "high",
-      "confidence": "medium",
-      "evidence": [
-        { "type": "signal", "ref": "geo_recommendation_quadrants:intent_123", "summary": "Mentioned but not recommended dominates." }
-      ],
-      "whyNow": "Why this matters this week.",
-      "risks": ["Uncertainty or dependency"]
-    }
-  ],
-  "rejected": [
-    { "ref": "intent_456", "reason": "Suppressed by recent action mask." }
-  ]
-}
-```

package/dist/skillpacks/geo/skills/brand-owned-diagnosis/references/workflow.md

@@ -1,194 +0,0 @@
-# Brand-Owned Diagnosis Workflow
-
-## Role
-
-The `brand_owned` channel diagnosis diagnoses and proposes actions for customer-owned discovered pages.
-
-It works on pages where:
-
-- `source = discovered`
-- the page belongs to the tenant/customer site
-- the action would improve an existing natural page or recommend a customer-site content action
-
-## Non-Goals
-
-- Do not iterate generated GEO pages.
-- Do not decide final routes for generated pages.
-- Do not propose third-party outreach.
-- Do not perform deep URL tree planning in MVP.
-- Do not require `PageContentLabel`.
-
-## Inputs
-
-- candidate rows routed by the orchestrator
-- tenant `agent/BRAND.md`
-- tenant `agent/STRATEGY.md`
-- tenant `agent/LEARNINGS.md`
-- relevant rows from:
-  - `geo_pages`
-  - `geo_intent_coverage`
-  - `geo_recommendation_quadrants`
-  - `geo_page_intent_visibility_gaps`
-  - `geo_page_performance`
-  - `geo_strategy_actions_recent`
-- page scrape when needed
-- AI answer samples when needed
-- competitor page scrape when needed
-
-## Workflow
-
-### 1. Filter Candidates
-
-Keep candidates where:
-
-- page source is `discovered`
-- page has an intent
-- intent is weak, or quadrant state indicates a fixable issue
-
-Drop candidates when:
-
-- page is not indexable and the tenant strategy forbids technical page edits
-- recent action mask suppresses the same action
-- evidence is too thin to justify an action
-
-### 2. Classify Candidate Case
-
-Assign one primary case.
-
-#### A. Page Exists But Visibility Is Low
-
-Use when:
-
-- discovered page exists
-- `current_visibility` is low
-- quadrant is mostly `absent`, `cited_unnamed`, or `mentioned_not_recommended`
-
-Diagnosis questions:
-
-1. Does the page directly answer the intent?
-2. Is coverage deep enough for representative prompts?
-3. Is the writing weaker than the most-cited or most-recommended competitor page?
-4. Is there a visible technical issue?
-5. Is authority the likely bottleneck, or only a weak hypothesis?
-
-#### B. Cited But Not Mentioned
-
-Use when:
-
-- our page/source is cited
-- brand is not clearly mentioned
-
-Diagnosis questions:
-
-1. Is the page clearly tied to the tenant brand?
-2. Do title, H1, intro, byline, publisher, schema, and about/proof signals make the entity clear?
-3. Is the content too generic to make the brand worth mentioning?
-
-#### C. Mentioned But Not Recommended
-
-Use when:
-
-- tenant brand is mentioned
-- competitors are recommended more often
-
-Diagnosis questions:
-
-1. Which brands were recommended?
-2. What reasons did the AI answer give or imply?
-3. What content-level weakness exists on the tenant page?
-
-### 3. Gather Evidence
-
-Use the cheapest sufficient evidence.
-
-Default evidence:
-
-- view rows
-- page title/H1/path/status
-- quadrant rates
-- page performance summary
-- AI answer excerpt
-
-Fetch page scrape when:
-
-- diagnosis depends on content coverage, proof, comparison, or entity clarity
-
-Fetch competitor page scrape when:
-
-- the answer repeatedly recommends or cites a competitor page
-- the proposed action depends on competitor comparison
-
-Do not scrape everything.
-
-### 4. Pick Root Cause Buckets
-
-Allowed buckets:
-
-- `intent_coverage_gap`
-- `content_depth_gap`
-- `entity_clarity_gap`
-- `generic_content_gap`
-- `proof_gap`
-- `comparison_gap`
-- `technical_issue`
-- `authority_gap`
-- `prompt_mismatch`
-- `not_a_problem`
-- `insufficient_evidence`
-
-Use `authority_gap` only when supported by external citation evidence or repeated competitor recommendation reasons.
-
-### 5. Route Action
-
-Allowed action families:
-
-- `update_existing_page`
-- `retarget_existing_page`
-- `merge_or_redirect_page`
-- `no_action`
-
-Use `update_existing_page` when the owned page is the right surface and needs content, proof, entity clarity, comparison coverage, internal linking, or technical fixes.
-
-Use `retarget_existing_page` when the page is a useful owned surface but should target a different intent or query cluster than the one being evaluated.
-
-Use `merge_or_redirect_page` when the page should not remain an independent surface because it duplicates, cannibalizes, or conflicts with a stronger owned page.
-
-Prefer owned-page updates over generated GEO page creation when an existing discovered page clearly owns the intent.
-
-### 6. Output
-
-Return a compact diagnosis for each accepted action:
-
-- candidate type
-- page URL/pageId
-- intentId
-- root cause buckets with confidence
-- recommended action family
-- concrete operations
-- evidence references
-- why other actions were rejected
-
-## Examples
-
-### Covered But Weak
-
-If a discovered page exists, visibility is low, and the page only gives generic education while competitor pages provide comparison criteria and proof:
-
-- root cause: `comparison_gap`, `proof_gap`
-- action family: `update_existing_page`
-- operation: add comparison criteria and customer proof to the existing page
-
-### Cited But Not Mentioned
-
-If the page is cited but the AI answer does not name the tenant brand:
-
-- root cause: `entity_clarity_gap`
-- action family: `update_existing_page`
-- operation: strengthen brand naming, publisher schema, and product/company relationship in the answer block
-
-## Guardrails
-
-- Do not propose creating a generated GEO page from this channel diagnosis unless the orchestrator explicitly routes no-page candidates here.
-- Do not over-index on page type labels.
-- Do not call content "thin" without page scrape or word-count/section evidence.
-- Do not diagnose authority from low visibility alone.