brainstorming: offer an opt-in prior-art search before designing - #2428

Who is submitting this PR? (required)

What problem are you trying to solve?

In a maintainer conversation about the brainstorming skill, the specific
complaint was: when someone describes an idea, the skill goes straight into
designing it. The user is the one who has to think to ask "does this already
exist?" — the skill never offers to check. That means brainstorming can walk
someone through designing something from scratch when a existing tool, or a
feature already in their own codebase, would have done the job.

The maintainer's requested flow, close to verbatim:

• Gate: ask first, "is it ok if I search for prior art?"
• If yes, show what exists: "here are a dozen things that look like what
  you're describing. why are they wrong?"
• Then: "if this already existed, would you just use that one?" and "what is
  different than that prior thing?"

What does this PR change?

Adds one bullet to the "Understanding the idea" section of
skills/brainstorming/SKILL.md, right after the idea has been understood and
before "Exploring approaches." It has the skill ask permission to search for
prior art, and — only if the human partner says yes — present what it finds
and ask the two follow-up questions above. Declining skips it entirely.

Is this change appropriate for the core library?

Yes. Brainstorming is a core, domain-agnostic skill shipped with Superpowers,
and checking for prior art before designing something from scratch is useful
regardless of what kind of project someone is working on. This doesn't
integrate or promote any third-party service — it just tells the agent to
ask, then use whatever search/read tools it already has.

What alternatives did you consider?

• Always search, without asking first. Rejected — the maintainer's
  wording explicitly gates this on permission ("is it ok if I search"), and
  an unconditional search would burn tool calls/tokens on ideas where prior
  art obviously doesn't apply (e.g. "add a lint rule to this file").
• A separate opt-in step in the Visual Companion style, offered as its own
  message. Considered, since that's the existing pattern for optional
  brainstorming detours. Went with a single inline bullet instead to keep
  the diff minimal — the Visual Companion's separate section exists because
  it has real setup (a browser tab, a server) and per-question routing
  logic; a prior-art ask is a single question with a yes/no branch and
  doesn't need its own subsection.
• Adding this as a new checklist step + Process Flow diagram node, the
  way feat(brainstorming): research prior art before design #2116 (below) treats its own research step. Rejected for this PR: that
  adds diagram/checklist churn for a two-sentence behavior, and feat(brainstorming): research prior art before design #2116 is
  already carrying that structural change for a related-but-distinct
  purpose. Keeping this PR to one bullet avoids compounding two overlapping
  restructurings of the same checklist in flight at once.

Does this PR contain multiple unrelated changes?

No. One bullet, one file.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs:
  • feat(brainstorming): research prior art before design #2116 (feat(brainstorming): research prior art before design,
    open) — this is the closest match by title, but it's solving a
    different problem: it dispatches a read-only research subagent to
    look at unfamiliar or fast-moving external technology, APIs, and
    libraries so the design's technical approach is grounded in real
    implementation evidence. It triggers on "does the design need current
    external technical knowledge," lives at the "Exploring approaches" step
    (after clarifying questions, before proposing approaches), and is never
    presented to the user as a question — it just runs when applicable.
    This PR is about a different kind of prior art: whether the whole
    idea already exists as a tool, product, or feature, so the person
    might not need to build anything at all. It's presented to the human
    partner as an explicit yes/no question before anything is searched, and
    the follow-up is "would you just use that one" / "what's different,"
    not "what does the API look like." The two are complementary, not
    competing — this PR doesn't touch feat(brainstorming): research prior art before design #2116's diff and would apply cleanly
    on top of it either order.
  • brainstorming: add research step before proposing approaches #983 (closed) — same "research before proposing approaches" theme as
    feat(brainstorming): research prior art before design #2116, not this PR's user-facing existence check.
  • No open or closed PR asks the skill to check whether the described idea
    already exists as a product/tool and offer that as a gated, opt-in
    question to the user.

Environment tested

New harness support (required if this PR adds a new harness)

N/A — this PR does not add harness support.

N/A — this PR does not add harness support.

Evaluation

• Initial prompt: nightly recon dispatched to draft this change from a
  maintainer-conversation note; no live coding session ran through the
  modified skill.
• Eval sessions run after the change: 0.
• Outcome comparison: none collected. This repo's skill-behavior evals
  live in a separate superpowers-evals harness (Quorum), which drives real
  coding-agent CLIs through scenario acceptance criteria and isn't available
  in this headless box. This change was NOT behavior-tested. The exact
  diff is below for review; no before/after transcript is being claimed.

diff --git a/skills/brainstorming/SKILL.md b/skills/brainstorming/SKILL.md
index e3f1788..9621dd8 100644
--- a/skills/brainstorming/SKILL.md
+++ b/skills/brainstorming/SKILL.md
@@ -205,6 +205,7 @@ is the whole process.
 - Prefer multiple choice questions when possible, but open-ended is fine too
 - Only one question per message - if a topic needs more exploration, break it into multiple questions
 - Focus on understanding: purpose, constraints, success criteria
+- Once you understand what they're describing, offer a prior-art search — don't just do it: "Is it ok if I search for prior art?" If they decline, move on. If they agree, look for existing tools, products, or features that match, then show them what you found: "Here are a dozen things that look like what you're describing — why are they wrong?" Follow up with "If this already existed, would you just use that one?" and "What's different than that prior thing?" Carry whatever makes their idea distinct into the design.
 
 **Exploring approaches:**
 

Rigor

• If this is a skills change: I used superpowers:writing-skills and
  completed adversarial pressure testing (paste results below) — NOT
  done. writing-skills normally drives this through eval scenarios;
  that harness isn't reachable from this box (see Evaluation above).
  Flagging this explicitly rather than skipping it silently.
• This change was tested adversarially, not just on the happy path —
  NOT done, for the same reason.
• I did not modify carefully-tuned content (Red Flags table,
  rationalizations, "human partner" language) without extensive evals
  showing the change is an improvement — this only adds one new bullet;
  no existing tuned content was touched.

Human review

• A human has reviewed the COMPLETE proposed diff before submission

Opened as a draft, untested against real sessions, specifically so a
human reviews the wording and the maintainers' eval harness can weigh in
before this merges. Not to be merged as-is.