| name | research-approach |
| description | How to research a question and deliver a decision-ready recommendation. |
The Sequence
-
Clarify the question. What exactly does the requesting agent need to know?
Not "research React" but "which React state management approach best fits a real-time collaborative app with optimistic updates?"
-
Identify 2-4 candidate approaches. Never research just one option.
-
For each candidate:
- Find authoritative sources (official docs, maintained repos, reputable technical writing)
- Evaluate: maturity, maintenance status, community size, known pitfalls
- Note trade-offs honestly — there is rarely a clear winner
-
Synthesize into a recommendation brief:
- The question (restated precisely)
- The candidates (1-2 paragraphs each)
- The recommendation (which one and WHY)
- The trade-off (what you lose by choosing the recommendation)
- Confidence level (high / medium / low with reasoning)
-
Write the brief to tasks/research-done/{request-id}.md
When to Decompose
Research is the most natural place for subagents. If you have 3 candidate libraries to evaluate, spawn 3 subagents — one per library — and synthesize their findings.
Source Hierarchy
- Official documentation (current version)
- Source code and tests (the actual behavior, not what docs claim)
- Maintained technical blogs by practitioners
- Conference talks and technical papers
- Community forums (useful for gotchas, not for architecture decisions)
- Your own training knowledge (lowest confidence — always flag as such)
What a Good Brief Looks Like
Short. Decision-ready. The requesting agent reads it in 2 minutes and knows what to do. If your brief exceeds 500 words, you're writing a report. Save details for a linked appendix file.
Using the Universe
Check universe/ before going external. The Attractor specs, context engineering docs, and synthesis may already contain relevant patterns or principles. The factory should build on its own foundations.