feat(brainstorming): research prior art before design - #2116
Conversation
|
I've used a research skill in brainstorming flow extensively since generated proposals are often not grounded in best practices and models can learn a lot by reading established code (e.g. patterns used, naming schemes, tests to write, libraries to use) reducing the amount of code agents have to invent. The implemented change is meaningfully smaller and targeted than my typical flow, and if maintainers agree with direction we could add a separate /research-implementations skill separately that I most often use to ask the agent to refine /brainstorming questions. |
|
Full review done (security + code review against current dev). Direction affirmed — this is the feature @obra asked for on #386, it's built correctly on top of the v6.3.0 three-path router, and the structural work is clean (architectural-path-only insertion, correct DOT wiring, complete renumbering, disciplined scope). Requesting changes on five substantive points before it can land:
Minor, while you're in there: spaced em-dashes (the file is 43/43 ' — '; your additions use unspaced), and tighten altitude — sibling checklist items run 6-13 words, the new one ~40. This was already the strongest outside submission of the window; with the predicate re-keyed and a battery behind the actual wording, it gets over the line. — Claude Fable 5, Claude Code 2.1.228, reviewing on behalf of @obra |
Summary
This PR adds a conditional, tooling-agnostic prior-art research step before
brainstorming proposes design approaches. It addresses the research portion of #2093, follows up on #386, and implements the maintainer's requested direction:
avoid coupling the workflow to GitHub or
gh, and explicitly delegate theresearch to a subagent.
When a decision depends on unfamiliar or current external knowledge, the skill dispatches one focused, read-only research subagent, asks it to inspect implementation source and tests, and uses the resulting APIs, patterns, edge cases, boundaries, and evidence gaps in the approach comparison. Self-contained work skips the step.
Who is submitting this PR? (required)
What problem are you trying to solve?
In a background-job architecture brainstorming session, the untreated agent recommended pg-boss over BullMQ and SQLite from model recall. It dispatched no research subagent, inspected no external implementation or tests, and presented unattributed compatibility and durability claims for a difficult-to-reverse infrastructure choice.
The existing workflow asks for 2–3 approaches but has no conditional point that grounds those approaches in current library/API behavior. PR #386 identified the same gap, but remains GitHub/
gh-specific, targetsmain, has no before/after behavioral evaluation, and has not implemented the maintainer's requested subagent revision.What does this PR change?
It adds one conditional step after clarifying questions in the checklist, process graph, and detailed guidance in
skills/brainstorming/SKILL.md. Research uses the tools available in the current harness, must be delegated to one read-only subagent, and is skipped when project context is sufficient.Is this change appropriate for the core library?
Yes. The behavior applies to any project making decisions about external technology, APIs, libraries, established practices, or difficult-to-reverse architecture. It is provider- and domain-agnostic, adds no dependency, and
does not promote a third-party service.
What alternatives did you consider?
ghsearches: rejected because it couples core behaviorto one provider and was the specific concern raised on feat(brainstorming): add research existing solutions step #386.
the brainstorming decision flow and separate invocation was unreliable in
the untreated eval.
Does this PR contain multiple unrelated changes?
No. The complete diff is one behavior change in one file: 33 additions and 10 deletions in
skills/brainstorming/SKILL.md.Existing PRs
dev, and supplies RED/GREEN plus task-completion evals.GitHub reports
maintainerCanModify: true, but that permits obra maintainers to edit the contributor branch; it does not let this contributor take over Vincent-lkm's fork.Environment tested
New harness support (required if this PR adds a new harness)
Not applicable. This PR does not add or modify harness support.
Evaluation
The initial human request was: add the research step described in #2093 to brainstorming, base it on implementation benchmarking, follow the contribution guidance, and validate it with evals.
Three behavioral candidate/control sessions were run after the initial change:
Three task-completion treatment sessions were also attempted; two produced valid paired comparisons and one was excluded for violating the read-only protocol.
Behavioral evals
Task-completion evals
These were one-attempt Luna smoke runs on a targeted DeepSWE subset, not an official score or statistically stable estimate. The FastAPI treatment was excluded when its subagent edited the shared worktree; Yaegi passed at baseline and therefore skipped treatment; KGateway failed during Docker image creation before the model ran.
Rigor
superpowers:writing-skillsandcompleted adversarial pressure testing
rationalizations, "human partner" language) without extensive evals
showing the change is an improvement
The external scenario concealed the desired research behavior and added time pressure while asking for a difficult-to-reverse infrastructure recommendation. The RED run made a confident recommendation with zero delegation. The first
GREEN wording exposed a loophole—documentation and issues were treated as implementation evidence—so the wording was tightened to require direct source and test inspection. The refined run then passed 7/7 deterministic checks. A counter-scenario verified that the conditional did not over-trigger for a self-contained wording decision.
Human review
@Jonksar explicitly confirmed review of the complete diff and approved creating
this PR after comparing it with the stalled #386.