research-then-implement

Store research findings in a durable Brief file under .planning/research/<topic>/BRIEF.md. Before any new investigation, check that directory and memory files for matching topics, then reuse, redo, or supplement the existing research instead of starting over.

Define the research question, investigate official docs via context7, community practices via bb-browser, and reference implementations in code. Record raw findings in sources.md, then distill them into a Brief with a recommendation, rejected alternatives, and constraints before writing any code.

A Brief should state the research question, a specific recommendation, key findings with sources, at least one rejected alternative with reasons, concrete constraints, and an actionable implementation checklist. Vague Briefs that do not constrain implementation fail the quality gate.

Skip it when the implementation approach is already clear, when fixing bugs with a known root cause, or when doing pure research with no implementation intent. Those cases are better served by direct implementation, debugging skills, or a dedicated deep-research skill.

Stop instead of silently working around the problem. Update the Brief with the new finding, inform the user that practice diverged from the research, and proceed with the corrected approach so the artifact stays accurate.