fandom-lore

name	fandom-lore
description	Query Fandom wikis (resolved and read via Bright Data) to extract fan-curated personality traits, relationship dynamics, and fan-framed story arcs for a subject -- the depth Wikipedia's neutral tone doesn't carry. Use when generate-psych-profile or story-universe need fan-interpretation signal alongside gather-citations' verified facts.
metadata	{"agent":"research-factcheck","source":"Project Atlas Agent Skills Manifest (Fandom enrichment)","layer":"L5-content-verify"}

fandom-lore

Harvest fan-curated character/subject depth from Fandom wikis and structure it into signal the narrative stage can use -- without ever storing the raw wiki prose.

When to use

• A subject approved for production has (or might have) an active Fandom wiki, and generate-psych-profile/story-universe want fan-interpretation signal on top of gather-citations' verified facts.
• Applies broadly, not just to fictional characters -- mythological figures, historical franchises, and games/anime/movie characters can all have deep Fandom coverage.

Sources (spec §5.5 mapping, Fandom enrichment)

• Bright Data (live) via the brightdata MCP server -- same vendor already used by gather-citations and fetch-signals, chosen so this skill doesn't introduce a second scraping vendor (no Apify): search_engine (engine: "google", site:fandom.com <subject>) to resolve the right wiki, then scrape_as_markdown (or scrape_batch for multiple sub-pages, e.g. dedicated "Personality"/"Relationships" pages) to read it.

Function signature (manifest contract)

def fandom_lore(subject: str) -> dict:
    """Return structured fan-interpretation signal for a subject, or an empty/zero-confidence
    result if no Fandom wiki was found."""

Inputs / Outputs

• Input: subject.
• Output: {subject, wiki_resolved, traits[], relationships[], arc_tags[], fan_debates[], coverage_confidence, provenance: "fan_interpretation"} -- see hermes/agents/fandom-lore/schema.json.

Copyright-safe rule (spec §2.5)

Scraped markdown is a transient input to the extraction call only -- never write raw wiki prose to storage. Persist only the structured signal (traits/relationships/arc_tags/fan_debates), each backed by a short (<25 word) paraphrase in evidence, never a verbatim quote.

Provenance rule

Everything this skill returns is tagged provenance: "fan_interpretation", never upgraded to a fact. Downstream agents must hedge fan-sourced claims ("fans have long read this as...") rather than asserting them -- this is what keeps fan headcanon from being scripted as verified history.

Implementation

1. Resolve the wiki: call brightdata's search_engine with site:fandom.com <subject>. Take the top fandom.com result as wiki_resolved.
2. If no fandom.com result is found, stop here and return {subject, traits: [], relationships: [], arc_tags: [], fan_debates: [], coverage_confidence: 0, provenance: "fan_interpretation"} directly -- do not invoke the LLM to invent fan opinions for a subject with no wiki.
3. Read the page: call brightdata's scrape_as_markdown on the resolved URL (and scrape_batch on any linked "Personality"/"Relationships"/"Trivia" sub-pages).
4. Call the hermes-bridge MCP tool run_judgment_agent(insight_type="fandom-lore", query=<ask>, context={"subject": subject, "wiki_url": <resolved_url>, "scraped_content": <markdown from step 3>}). Hits Hermes's POST /v1/agents/fandom-lore (hermes/agents/fandom-lore/), same self-correcting LLM loop / mock-fallback pattern as gather-citations. Unlike gather-citations today, this skill passes real retrieved content into context from the start -- don't let this regress into training-data-only judgment (see the gap noted in gather-citations' own SKILL.md).

Backend dependency

• API keys: Bright Data is live (already wired for gather-citations/fetch-signals) -- no new vendor, no new budget line.
• Writing structured signal to the graph (Railway) has the same stubbed status as gather-citations' facts until the Postgres/AGE backbone is wired.

Model

deepseek-direct/deepseek-chat for extraction. Scraped wiki pages can be long -- apply Jina Reader-style compression before the judgment call if a single page exceeds prompt budget (spec §11.3).