worldsmith/skills/worldsmith-methodology/SKILL.md
Use when working in a project with a worldbuilding documentation ecosystem (docs/ or lore/ directory). Provides the documentation-first methodology: canonical hierarchy, doc roles (timeline, lore, characters, systems), propagation discipline, and the dual canonical and exploratory workflow.
npx skillsauth add queelius/claude-anvil worldsmith-methodologyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Rules and structure for documentation-first fiction worldbuilding. This skill provides what cannot be inferred from context alone: the editorial discipline, canonical hierarchy, propagation awareness, and character documentation standards that keep a worldbuilding project internally consistent as it grows.
Treat documentation as the source of truth for the fictional world. The manuscript is one expression of the world; the docs define it. Docs and manuscript should stay consistent with each other, but recognize that creative work is messy — bidirectional updates happen naturally. A scene might introduce a detail that needs to flow back into the docs, or a doc revision might require manuscript changes. Both directions are legitimate.
When docs and manuscript conflict, the docs are usually right — they represent deliberate editorial decisions. But exercise judgment. Sometimes the manuscript captures a better version of a detail that the docs haven't caught up with. The key discipline is noticing divergence and reconciling it, not enforcing rigid ordering.
All documents are living documents, including the project's CLAUDE.md. As the world evolves through writing, update the docs. As the docs evolve, keep CLAUDE.md current — it is the most frequently read document in any session and serves as the entry point to the entire editorial system. A stale CLAUDE.md undermines every subsequent action.
Worldbuilding projects organize their editorial knowledge across documents that serve specific roles. Think in terms of roles, not filenames — a project might call its timeline doc timeline.md, chronology.md, or history-dates.md. The role matters, not the name. Consult the project's CLAUDE.md for the mapping between roles and files.
Timeline Authority — The authoritative source for dates, event sequences, character ages at specific points, and day-numbering within chapters. When any other doc or the manuscript disagrees with the timeline on a date or sequence, the timeline wins.
Lore/History — Mythology, founding stories, cultural context, historical events in narrative form. Contains the "why" behind the world's current state. Typically has both canonical sections (established history) and exploratory sections (myths being developed, histories not yet referenced in manuscript).
Systems/Mechanics — Magic systems, technology rules, geography and climate, economic structures, political systems. Specs with consequences: not just "how the system works" but "what it means for characters and plot." Typically has exploratory sections for systems under development.
Character Tracking — Character arcs, voice patterns, relationships, emotional trajectories, key scene anchors. The working reference during manuscript writing. See Section 5 for documentation standards.
Style Conventions — Prose principles, POV rules, tense conventions, intentional repetitions list, anti-cliche rules, consistency checklist. The guardrails for how the story is told, distinct from what it tells.
Outline/Diagnostic Hub — Scene-by-scene or chapter-by-chapter breakdown with cross-references to other docs. Functions as a control panel: what happens, which characters are present, which world elements are in play, what state things are in. The place to check "where does X appear?"
Editorial Backlog — Future ideas, sequel hooks, unexplored threads, deferred decisions. Ranked or prioritized by potential impact. A holding pen that prevents good ideas from being lost while keeping them out of canonical docs until they're ready. Typically has exploratory sections only.
Themes/Anti-Cliche — Thematic rules, philosophical framework, what patterns to avoid, what patterns to preserve. The project's aesthetic and intellectual commitments — what makes this story this story and not a generic version of itself.
Feedback — Date-stamped editorial reviews, reader feedback, revision notes with priorities. Progress tracking across revision cycles. A historical record of editorial decisions.
Universe Bible (optional, recommended for multi-work projects). A narrative-form synthesis of all canonical lore: history told as story, systems explained through their consequences, cultures described through the lives of the people in them. Think of it as the Silmarillion for this world. Not a database, but a readable document that tells the story of the world itself. Generated and maintained from canonical docs by the lore-writer. Updated when canonical lore changes. For single-work projects the lore docs themselves may suffice, but for a shared universe with multiple works, the universe bible is the single document that synthesizes everything into one coherent narrative.
When sources disagree, resolve conflicts using this hierarchy (highest authority first):
Not every project will have all roles populated. Some projects may combine roles into fewer files. The hierarchy applies regardless of how many files exist.
The Silmarillion approach: you do not write a novel and then document what you wrote. You build a world and then the novel emerges from it. The documentation IS the world. The manuscript is one expression of it.
In practice, this means a specific creation order:
This is the default workflow for new content. The bidirectional flow in step 5 is natural and expected. The discipline is in steps 1-2: build the world before you tell stories in it.
When modifying established facts (correcting a date, updating a character's arc after a chapter is written, revising a system rule), treat the change as canonical. Update the authoritative source doc first, then reconcile affected docs and manuscript passages. Follow the canonical hierarchy: if the change originates in a lower-authority source, verify it against higher-authority sources before propagating.
When developing new material (drafting mythology, sketching a future plot thread, experimenting with a system extension), treat it as exploratory. Write to exploratory or provisional sections of the appropriate doc. Mark the content as provisional or speculative. Do not update the manuscript based on exploratory content. Do not propagate exploratory content to other canonical sections.
When exploratory content is ready to become canonical: resolve any conflicts with existing canonical material, move the content to canonical sections, then reconcile affected docs and manuscript as with any canonical change.
Determine the appropriate mode from context. Most user requests make it clear whether they're establishing facts or exploring possibilities. When ambiguous, ask.
A change to one document may require changes to others. Developing this awareness is more important than following a rigid checklist. When making a change, pause and consider: what else in the project depends on or references the thing that just changed?
The scope of propagation varies. A typo fix in a character name propagates narrowly — search and replace across files. A restructured timeline propagates widely — character ages, event references, outline entries, and manuscript passages may all need revision. Recognize which kind of change is happening and respond proportionally.
Consult the project's CLAUDE.md for the document structure and role mappings. CLAUDE.md itself is part of the ecosystem — when project-level facts change (world structure, canonical tables, character conventions, anti-cliche rules, series relationships), update CLAUDE.md to reflect those changes.
For detailed guidance on how changes ripple through interconnected docs, including examples organized by document role and the distinction between shallow and deep changes, consult ${CLAUDE_PLUGIN_ROOT}/skills/worldsmith-methodology/references/propagation-awareness.md.
Character docs earn their place by providing what Claude cannot infer from the manuscript alone: patterns, trajectories, and behavioral specifics that make characters recognizable and consistent across chapters.
Document how each character sounds — not generic labels ("speaks formally") but specific patterns ("uses rhetorical questions when deflecting, drops contractions under stress, favors botanical metaphors"). A well-documented voice pattern makes a character recognizable without dialogue tags.
Track specific moments that mark a character's arc trajectory. Not summaries ("she's getting braver") but anchored observations ("Chapter 12: flinches at the mention of the treaty but doesn't leave the room — first time she's stayed"). These accumulate into an arc map that shows where a character has been and where they're heading.
Reference specific chapter-and-moment pairs where a character makes pivotal choices, reveals information, or undergoes change. These anchors serve as landmarks when checking consistency: "Has this character already learned X? Check the scene anchor list."
Document which concepts, philosophies, or worldview elements a character embodies. Not personality labels but the specific ideas they represent and how those ideas shape their decisions.
Avoid generic descriptions that could apply to any character: "brave warrior," "wise mentor," "conflicted hero." Instead, document behavioral specificity: "pauses before speaking, fingers tracing the scar on her wrist" tells more than "thoughtful and haunted" ever could.
Projects may exist within a series or shared universe. Check the project's CLAUDE.md for references to related projects — sibling novels, prequel/sequel relationships, shared-world anthologies.
When working on world facts that are shared across projects (timeline events, geography, system rules, cultural constants), consult the related projects' docs for consistency. Project-local facts (character arcs, plot details, manuscript-specific style choices) do not require cross-project checking.
When a shared world fact changes, note which related projects may need updating. The current project's CLAUDE.md should list these relationships.
Watch for these categories of issues during any worldbuilding or editorial work:
Severity depends on context. A wrong date in a throwaway reference is less urgent than a wrong date in a pivotal scene. A crutch word used twice is different from one used twenty times. Exercise judgment rather than applying rigid severity classifications.
A universe can contain multiple works sharing the same canonical docs. Configuration lives in .worldsmith/project.yaml. If this file does not exist, worldsmith treats the project as single-work (existing behavior, no change).
When working in a multi-work project:
lore directory in project.yaml contains canonical docs that apply to all works. A change to a character entry here affects every work that character appears in.lore directory for work-specific docs (characters unique to that story, locations only relevant to that novella). Local lore does not affect other works.${CLAUDE_PLUGIN_ROOT}/skills/worldsmith-methodology/references/propagation-awareness.md — How changes ripple through interconnected docs, with examples by document role and guidance on shallow vs. deep changes.${CLAUDE_PLUGIN_ROOT}/skills/worldsmith-methodology/references/doc-structure-guide.md — What good worldbuilding docs look like, organized by role. Used by init-world when generating docs for new or adopted projects.tools
This skill should be used when the user asks about research directions, open problems, future work, or follow-up research from the academic literature. Trigger phrases include "open problems in X", "what's next for Y", "future work for paper Z", "research directions on T", "salient follow-up research", "what should I work on next in", "find me follow-up research unrelated to my prior work", "broad survey of W", "neglected directions in V". Routes the request to the right Vista MCP tool, reads back the structured paper sections, and synthesizes research directions in the conversation.
testing
Discover latent themes in the metafunctor corpus. Use when the user wants to find implicit through-lines across their blog posts, surface recurring ideas they have not consciously framed as a series, or get candidate themes for a synthesis post. Reads titles, descriptions, and tags; proposes 3 themes that connect 4+ posts each, each with a single-sentence through-line. Output is a proposal, not a draft. Trigger phrases include "find themes in my posts", "what threads connect my writing", "latent themes in my corpus", "scribe".
development
Use when drafting prose sections for a bookwright (technical non-fiction) project. Encodes the Bernoulli-textbook workflow: atom-outward design, deferral discipline, running threads, page budgets, Path A subagent pattern, header comment block convention.
testing
Use when drafting or executing a paired notebook for a bookwright chapter. Covers when notebooks are required vs optional, numerical-sanity-target convention, exec-from-fresh-kernel requirement, and stack-specific execution commands (Jupyter/R Markdown/Quarto).