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

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

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: when an owner skill has its own threshold, 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.

1. Ground the conversation before asking

Resolve the nearest project or area root and read before asking:

1. CLAUDE.md or AGENTS.md — the host-selected contract and routing;
2. FASES.md — current state and already-decided work;
3. lore/index.md — map of applicable criterion;
4. identity, principles, and only the thematic Lore modules routed by the index;
5. source notes or materials explicitly named by the user.

If a file does not exist, continue with what is available and say which source of orientation is missing. Do not invent Lore to fill the gap. When loose notes share the tree, invoke save-to-lore and read its conditional notas.md function for source-side classification before treating their contents as criteria.

Summarize internally:

• purpose and quality north;
• current phase and relevant prior decisions;
• constraints and anti-scope;
• what is already approved versus genuinely unresolved.

Do not make the user repeat answers already written in those sources.

2. Scale the process to uncertainty

This skill is domain-neutral inside its Lore boundary: it can design Lore artifacts for software, editorial work, research, teaching, design, operations, or a mixed project, but it does not design the domain deliverable itself.

• Direct design: the outcome and constraints are mostly known. Confirm only the unresolved choice, then present a short design in chat.
• Exploratory design: purpose is known but important trade-offs remain. Ask focused questions, compare approaches, then present the design in sections.
• Decomposition: the request contains several independent outcomes. Show the boundaries and order first; design only the first coherent unit unless the user explicitly wants the full system.

Infer the depth and apply it silently. Ask only about an unresolved choice that changes the result; do not announce the label. Hidden complexity may increase depth; never use a label to reduce an owner skill's required gate.

3. Clarify one decision at a time

Ask one question at a time. Prefer a concrete recommendation with alternatives when the source material supports one; use an open question when it does not.

When the work begins from provisional canon, ask only what is necessary for a first victory. Every later question must unlock a decision or improve the artifact, and the conversation must admit uncertainty and correction instead of turning the first answer into permanent doctrine.

Only ask what changes the design:

• who or what the result serves;
• success criterion;
• constraints and non-goals;
• compatibility and portability expectations;
• acceptable evidence and verification;
• irreversible or externally visible consequences.

Stop asking when the remaining uncertainty can be stated as a trade-off in the proposal.

Build the artifact while deciding

For a structural operation — creating a bot, project or area, or materially transmuting or crystallizing one — maintain an accumulated artifact, not a hidden interview transcript. After each answer, carry the decision into the working design. At contextual milestones, show the result so far in plain language: what it has become, what changed, and what remains unresolved.

The quality signal is recognizable continuity: the user can still see their original intention inside the growing artifact and can correct its direction without rebuilding it. Work one decision at a time; the recap proves accumulation, it does not reopen approved choices. This contract does not apply to a mechanical edit, a read-only consultation, or one incremental Lore capture.

The second signal is fertile effort: the shared work produces recognizable movement in the artifact, even when it includes disagreement, correction or demanding review. Do not equate a healthy process with agreement, pleasing the user or frictionless compliance. Make the gain visible; if effort accumulates without changing the artifact or criterion, stop and repair the process.

The accumulated artifact is the shared return point. Healthy structural work does not require constant contact: several clues or independent advances may accumulate between milestones. The recap calls them back into one visible design, and approved distillation returns what changed to the shared criterion without erasing either participant's autonomy.

The first victory in a new bot

When create-bot arrives with only an idea, design backwards from the first victory: the smallest real outcome that proves the bot can help this person work. Ask the minimum needed to make that outcome possible. Preserve uncertainty and correction in the proposal instead of forcing a complete identity before use; every later question must unlock the victory or improve its quality.

The person's professional profile emerges progressively through use, when enabled. First configuration may ask whether to use that module, explaining both outcomes without recommending either option. It never requests a CV, résumé, work history or life story during first use. Facts stated while doing real work may become small candidates for save-to-lore at a natural milestone; until the person reviews them, they are context rather than identity. If disabled, no profile file or biographical proposals are created and every other capability remains available.

Orientation for somebody new to the kit — suggested, never asked — 2.3.0

When this skill is running the kit's first use (use-lore §0 hands the conversation here), the person may have no picture of what Lore is. Suggest one short orientation and infer its shape from how they have been writing — a concept map, a short text, a plain-language explanation, a worked example over the artifact they are about to receive. use-lore §0 carries the inference rule and the exact wording; do not duplicate it here.

Two limits, and they come from this skill's own invariants rather than from politeness:

• It is an offer, not a question. «One question at a time» is a budget, and a question that does not change the design spends it for nothing. Which tutorial format somebody prefers changes no artifact — so it is proposed in one line, corrected in one line, and never becomes a decision the conversation waits on.
• It never runs instead of the design. The threshold of this skill is an approved design, and an orientation delivered in its place is a conversation that felt productive and moved nothing. If only one of the two fits in the turn, it is the design.

4. Compare approaches

For consequential choices, present two or three approaches with their real trade-offs. Lead with the recommendation and explain why it best serves the project's identity and present phase.

An approach is not a cosmetic variation. It must differ in a decision such as scope, ownership, coupling, publication boundary, evidence burden, or maintenance cost. Remove options that violate Lore or the explicit anti-scope.

5. Present a proportional design

Present enough structure for the user to know what will happen:

• intended outcome and boundary;
• chosen approach and why;
• artifacts or systems affected;
• routing and ownership;
• failure modes or protected material;
• verification and definition of done;
• what remains outside this change.

For a direct design, this can be a few sentences. For exploratory work, split it into coherent sections and request feedback as needed. Use domain vocabulary; do not force every design into software headings such as components, data flow, or error handling.

Then state the threshold plainly and wait for explicit approval.

6. Handoff after approval

After approval:

1. record the approved design in the active task state when the environment supports it;
2. hand execution to the native Plan Mode or planning mechanism available in the current agent;
3. invoke the artifact's owner skill at the point it becomes responsible;
4. keep any later owner-specific threshold intact.

This skill does not require writing-plans or any other third-party planning skill. It also does not create a spec file or commit by default. Create a design document only when the user, the project's Lore, or the owner skill requires a durable artifact. Never commit or push merely because brainstorming ended.

Where the source loses

The Superpowers source is valuable but was written for a different purpose. Against Lore's plugin identity, it loses in five places:

1. Universal activation loses to a Lore-only boundary. A generic request to brainstorm must not activate this skill; only a change to a Lore-owned artifact enters this route.
2. Software taxonomy loses to domain neutrality. spike / bounded / architectural is useful in code work but distorts research, editorial, teaching and publication decisions.
3. A fixed spec directory loses to local structure. Lore follows the project's own routing and language instead of creating docs/superpowers/specs/ everywhere.
4. Automatic commit loses to user authority. Approval to design is not approval to change git or publish externally.
5. A mandatory writing-plans terminal loses to provider portability. Claude, ChatGPT/Codex and other agents may expose different native planning mechanisms.

Invariants

• Read contract, state and routed Lore before asking the user to reconstruct context.
• One question at a time.
• Structural work maintains an accumulated artifact and periodically proves recognizable continuity.
• Fertile effort changes the artifact or criterion; agreement and pleasing are not substitutes.
• Independent advances return through recap and approved distillation; constant contact is not required.
• Compare two or three approaches when a consequential choice exists.
• Design depth scales; explicit approval remains.
• Owner skills keep ownership and their own threshold.
• No spec file, commit, push or implementation is implied by brainstorming approval.
• The workflow remains provider-neutral and domain-neutral.