| 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
- Resolve the wiki: call
brightdata's search_engine with site:fandom.com <subject>. Take
the top fandom.com result as wiki_resolved.
- 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.
- Read the page: call
brightdata's scrape_as_markdown on the resolved URL (and scrape_batch
on any linked "Personality"/"Relationships"/"Trivia" sub-pages).
- 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).
