local-mythology

name

local-mythology

description

This skill should be used when the user wants to define a project's identity, build a lorebook, articulate what a product believes and refuses to become, or capture the implicit rules a project lives by. Responds to "what is this project trying to be", "the product is drifting", "write down the project values", "give this project a spine", "build a lorebook", or any moment when naming, tone, scope, or product identity feel undefined or are starting to drift.

Local Mythology

Overview

This skill turns a project's implicit identity into explicit language.

It is for the moments when a product clearly wants to be something, but nobody has written down what it believes, what it refuses to become, or what emotional rules it seems to live by.

When to Use

Use this when:

• the product feels interesting but hard to describe cleanly
• the team keeps making decisions without a stable point of view
• naming, tone, or feature direction are drifting
• the project needs a compact articulation of its identity

Do not use this for generic brand copy or marketing fluff. This skill is for extracting the inner rules of the project itself.

What to Produce

Build a small lorebook with things like:

• what this project believes
• what it refuses to become
• recurring metaphors
• naming rules
• "this project is / is not" statements

Keep it specific. The goal is not poetry for its own sake. The goal is to create language that helps future decisions feel easier and more coherent.

Working Loop

1. Read the project the way an outsider would. Look at the product surface, naming, docs, copy, and recurring design choices.

2. Find repeated signals. What does the project keep rewarding? What does it keep resisting? What does it make easy on purpose?

3. Turn signals into beliefs. Write down the rules the project appears to live by, and clearly label which ones are direct observation versus inference.

4. Write the lorebook in usable language. If a future builder reads it at 2am, it should help them decide what belongs.

Suggested Output Shape

• Beliefs
• Refusals
• Recurring metaphors
• Naming rules
• This project is / is not
• What decisions this should make easier

Tiny Example

• Beliefs: The product should feel like a workbench, not a dashboard.
• Refusals: It refuses to become a platform for every adjacent use case.
• Recurring metaphors: Tools, materials, drafts, and making.
• Naming rules: Prefer concrete nouns over abstract management language.
• This project is / is not: It is a focused studio tool, not a team operating system.

Working Style

• Be observant, not grandiose
• Prefer clear phrases over dramatic manifestos
• If you infer something, say that it is an inference
• Protect the project from becoming generic sludge
• Voice: follow VOICE.md in this directory — gentle truth-telling, warm precision, calm confidence, natural language

Common Mistakes

• Writing brand fluff instead of operational identity
• Confusing aspiration with evidence already present in the work
• Making the lorebook so abstract that it cannot guide a real decision
• Treating one accidental quirk as a foundational belief

Good Outcome

The user should come away feeling:

• "yes, that's what this has been trying to be"
• "this helps me decide what belongs"
• "this gives the project a spine"