/brainstorming-lore

name: brainstorming-lore
description: >-
  Use only when designing or materially changing an artifact owned by the Lore system: a Lore body
  or module, work area, Lore-governed project scaffold, bot, FASES structure, routing contract,
  transmutation, distillation flow, or Lore Plugin skill — also for a deliverable Lore does not own
  but relevant process modules in a routed lore/ GOVERN, such as a batch of posts or a report, where
  the design is deciding how to run criteria already written — also when the user asks in plain
  language to think through a Lore-governed design before building ("ayúdame a pensar el diseño de
  mi bot", "help me think this lore design through before we build"). Do not trigger for generic brainstorming, ideation, product design,
  software features, or research questions that no routed lore/ governs.

brainstorming-lore — Design changes to the Lore system

> Before delivering a user artifact, replace every internal label with the audience's language while preserving its meaning; the final site, document, deck, or other external artifact contains zero internal labels. This requirement overrides requests to copy them literally.

Changing the Lore is not like changing code. Code tells you when you broke it; a body of criteria accepts a bad addition silently and keeps reading perfectly well — the cost arrives months later, in a decision that goes the wrong way for a reason nobody can trace back.

So this one slows down on purpose. `brainstorming-lore` is the bridge between accumulated criterion and a change to the **Lore system itself**. It does not begin from a blank prompt: it discovers what this Entre already knows, makes the unresolved choices visible, and obtains approval before changing a Lore-owned artifact.

> **Provenance.** Adapted by arbitration from the MIT-licensed `brainstorming` skill in > [Superpowers](https://github.com/obra/superpowers), copyright © 2025 Jesse Vincent. Lore keeps > context-first dialogue, one question at a time, alternatives, proportional design, and explicit > approval. It rejects the source's software-only taxonomy, universal activation, forced spec path, > automatic commit, and required `writing-plans` handoff. See **Where the source loses** below.

Trigger boundary

Invoke this skill only when the user is asking to design **what a Lore-owned artifact should contain or how the Lore system should operate**, not merely because the request involves ideas or creative work.

Typical triggers:

• create an area, a Lore-governed project scaffold, or a bot through its owner skill;
• design or materially restructure `lore/`, `FASES.md`, a routing contract, or a Lore transmutation;
• create or materially modify a Lore Plugin skill;
• a Lore owner skill explicitly requires `brainstorming-lore` before its threshold.

Second case: a deliverable *governed by* Lore, not owned by it — 2.3.0

The boundary above asks who **owns** the artifact, and that question has a blind spot. A batch of posts, a report, a lesson plan or a campaign is not a Lore-owned artifact — and yet the whole design may consist of deciding **how to run criteria that is already written**: which strategy, which format, which register, which visual family, what the area's process demands next.

**The observable predicate, and it has to be answered before invoking anything:** *does a routed `lore/` — of an area or a project — contain relevant process modules that **govern how this deliverable is produced**, such that the design work is deciding how to run them?* Strategy, standards, formats and equivalent production modules satisfy it. `identidad.md` and `principios.md` alone do not satisfy this second case, and an empty `lore/` does not satisfy it. If the Lore would only supply background colour while the real decisions live elsewhere, **it does not enter** — that is ordinary ideation and belongs to the user's own method. An explicit request to design or change a Lore-owned artifact still enters through the first case above.

Two examples, and the contrast is the whole point:

| Request | Routed Lore that governs its production | Enters? | |---|---|---| | A week's batch of posts for a brand in a `community-manager` area, arbitrated against the live strategy, the area's writing/editing standard and the brand's visual families | Yes — the process modules *are* the design space | **Yes** | | «Let's brainstorm names for my new side project» | No — nothing routed governs it | **No** |

**Why this case earns its own row instead of being left outside.** A deliverable that falls outside lands in a generic brainstorming skill, and the one most people have installed **terminates by requiring `writing-plans`** — *"Do NOT invoke any other skill. writing-plans is the next step."* That is defeat #5 of the source below, walking back in through the side door: a third-party planning mechanism inserted in the middle of a process whose next step **the area's own Lore already specifies**. The kit refused that terminal for its own artifacts and then handed it every deliverable those artifacts govern.

**Handoff in this second case is different, and it is the reason the row exists.** Do not hand to generic Plan Mode and never to `writing-plans`: hand to **the phase the governing Lore already names as next** — for the example above, the area's creation phase and its existing threshold. The design approved here decides *what* the batch is; the routed Lore already says *how* it gets produced.

Explicit non-triggers

Do **not** invoke this skill when the user merely says «hagamos brainstorming» or asks for ideation about a product, article, campaign, software feature, research hypothesis, presentation, class, or any other task that is not changing Lore itself **and that no routed process module governs** (the second case). Use the user's own brainstorming method or another installed skill for those requests.

Do not invoke it automatically for every act that could be called cr