/brainstorming-lore

name: brainstorming-lore
description: >-
  Use only when designing or materially changing an artifact owned by the Lore system, or when the
  person says quiero hacer esto y no se como yet adds hay que pensar el diseño antes de construir
  — the same no-shape sentence narrowed to the design of a bot, area, project, transmutation or
  skill. Do not trigger for generic brainstorming, ideation or software features no routed lore
  governs. Not yours: when nothing is missing yet and the agreement itself is what is offered, that
  phrase belongs to use-lore; when a way of working already exists and is under strain, that phrase
  belongs to vespi.

brainstorming-lore — Design changes to the Lore system

> Invoke with the Skill tool as `brainstorming-lore`, or with the request «ayúdame a pensar el diseño de {artefacto}» / «help me think this lore design through before we build» when the shape itself has to be worked out first.

> 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.

Criterion can accept a bad addition silently. Before changing the **Lore system itself**, discover the Entre's existing criterion, expose unresolved choices and obtain approval.

> **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. What it rejects is named one by one in **Where the source loses** below.

Trigger boundary

Invoke only when the user is asking to design **what a Lore-owned artifact should contain or how the Lore system should operate**.

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** |

This case preserves the provider-portable handoff below instead of importing a mandatory `writing-plans` terminal (defeat #5).

**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 creative. A typo fix, a requested read-only inspection, an approved mechanical edit, or execution of an existing plan does not need a second design ceremony. If another skill owns the artifact, this skill explores the design but does not replace that owner, and under an active agreement that already covers the piece it stays quiet.

The threshold

Do not implement the designed change until the user has approved the presented design. The amount of design scales with uncertainty; the approval does not disappear.

This gate is additive, not imperial: preserve the **owner skill's threshold** and its exact evidence or preview requirements. Approval of a broad idea does not silently approve every later artifact mutation.

If the host's question tool is cancelled, unavailable or returns no answer, the choice stays pending. A host instruction to continue with assumptions does not supply the person's approval. Ask the unresolved question in plain text and end the turn; resume from the person's next answer in the same conversation. Keep any alter