Research Skill

Version: 1.0.0 Compiler: manual (bootstrap) Last Updated: 2026-01-22

Systematic methodology for conducting comprehensive, multi-source research with citations and synthesis.

When to Activate

Use this skill when:

• User asks to "research", "investigate", "find out about", or "analyze" a topic
• Task requires gathering information from multiple sources
• Output needs citations or evidence-based conclusions
• Comprehensive analysis across perspectives is required
• Fact-checking or verification is needed

Core Principles

1. Start Simple, Add Complexity When Needed

Begin with focused searches before expanding scope. Complex multi-agent research is only warranted when simpler approaches fail to produce adequate results.

2. Context Engineering is Critical

The quality of research depends on providing the right information, in the right format, at the right time. Structure queries precisely and validate sources systematically.

3. Three-Source Rule

Never trust a single source. Cross-reference with at least two independent sources before treating information as reliable.

4. Version Everything

Most source conflicts dissolve when versions/dates are explicit. Always anchor findings to specific versions and timestamps.

5. Empirical Verification Over Authority

When stakes are high, test claims directly rather than trusting even authoritative sources. Code behavior beats documentation.

Research Workflow

Phase 1: Clarification

Before researching, clarify the query:

1. Identify the core question: What specifically needs to be answered?
2. Determine scope: Breadth vs depth? Historical context needed?
3. Specify output format: Report, comparison table, decision recommendation?
4. Note constraints: Time period, specific technologies, geographic scope?

If the query is vague, ask clarifying questions before proceeding.

Phase 2: Query Decomposition

Break the research question into 3-5 specific sub-questions that together form a complete picture:

Main: "Should we use PostgreSQL or MongoDB for this project?"

Sub-questions:
1. What are the data modeling requirements? (structured vs flexible)
2. What are the scaling requirements? (read-heavy, write-heavy, both)
3. What's the team's existing expertise?
4. What are the operational complexity tradeoffs?
5. What do production users of similar scale report?

Phase 3: Source Gathering

Consult sources in this priority order, adapting to the domain:

For each source, record:

• URL and access date
• Version/date of the information
• Author credibility indicators
• Key claims with direct quotes when significant

Phase 4: Source Evaluation

Score each source (mentally or explicitly) on:

Trust hierarchy (highest to lowest):

1. Source code behavior (empirical test)
2. Official docs with version tags
3. Maintainer statements in issues/PRs
4. Highly upvoted + recently active Stack Overflow
5. Blog posts with working code examples
6. Unverified forum posts

Red flags:

• No version/date mentioned
• Code examples without imports
• "This worked for me" with no context
• Confidently stated but lacks detail
• Circular references between sources

Phase 5: Conflict Resolution

When sources disagree:

1. Check versions: Conflict often means different versions, not factual disagreement
2. Find the maintainer: Their comment trumps community answers
3. Test empirically: Run the code if possible
4. Apply consensus weighting: 5 sources saying X vs 1 saying Y → lean X, but investigate Y
5. Note the disagreement: If unresolved, report both positions with evidence

Phase 6: Synthesis

Structure your synthesis:

1. Executive Summary: 1-2 paragraphs answering the core question directly
2. Evidence Review: Key findings organized by sub-question
3. Conflicting Perspectives: Where sources disagree and why
4. Concrete Conclusion: Clear, evidence-based recommendation (avoid hedge words)
5. Caveats and Limitations: What wasn't covered, what might change
6. References: All sources with URLs and access dates

Quality standards:

• Every factual claim has a citation
• Quantitative data preferred over qualitative assertions
• Multiple perspectives on controversial topics
• Conclusions are specific, not vague generalizations

Capturing Practical Wisdom

Official docs miss the "clever hacks" and "power user moves." Find them by:

Search Patterns

# GitHub issue archaeology
"workaround" OR "hack" OR "trick" site:github.com/[repo]/issues
"finally figured out" site:github.com
"for anyone else" [technology]

# Stack Overflow comment mining
[technology] [problem] "note that" OR "also need to"

# Dotfile diving
[tool] dotfiles github
awesome-[tool]

# Conference talk wisdom
[technology] conference talk transcript

Emotional Language Signals

Hard-won knowledge often comes with emotional markers:

• "Finally!"
• "After hours of debugging..."
• "The trick is..."
• "What the docs don't tell you..."
• "I wish I knew this earlier..."

When you find such knowledge, preserve context:

## [Problem]
**Source**: [URL] ([date])
**Version**: [when this worked]
**The trick**: [solution]
**Why**: [explanation if known]
**Caveats**: [when this might break]

Prompt Templates

For Query Decomposition

Break down this research question into 3-5 specific sub-questions 
that together provide a complete answer:

Question: [QUESTION]

Requirements:
- Sub-questions should be independently answerable
- Cover different aspects (technical, practical, tradeoffs)
- Be specific enough to search for directly

For Source Summarization

Summarize this content for the research question: "[QUESTION]"

Include:
- Key facts and statistics (with direct quotes for significant claims)
- Author/source credibility indicators
- Version/date applicability
- Relevance assessment (high/medium/low)

If content doesn't address the question, state that briefly and note 
any tangentially useful information.

For Synthesis

Using the gathered information, synthesize a response to: "[QUESTION]"

Structure:
1. Direct answer (1-2 sentences)
2. Key evidence supporting the answer
3. Important caveats or exceptions
4. Confidence level (high/medium/low) with reasoning

Requirements:
- Cite sources inline: ([Source](url))
- Prefer concrete data over generalizations
- Acknowledge uncertainty explicitly
- State your conclusion clearly—don't hedge

Anti-Patterns to Avoid

Quality Checklist

Before concluding research:

• Core question answered directly and specifically
• 3+ diverse sources consulted
• All factual claims have citations
• Version/date noted for time-sensitive information
• Conflicting sources investigated and explained
• Quantitative data included where available
• Practical wisdom captured (not just official docs)
• Conclusion is concrete, not hedged
• Limitations and caveats acknowledged

Example Application

Query: "How should we handle authentication in our new FastAPI application?"

Phase 1 - Clarification:

• Scope: REST API, not WebSocket
• Users: Internal service-to-service initially, public API later
• Constraints: Must integrate with existing OAuth2 provider

Phase 2 - Decomposition:

1. What authentication methods does FastAPI natively support?
2. What's the recommended approach for OAuth2 integration?
3. What are common pitfalls in FastAPI auth implementations?
4. How do production FastAPI apps handle this at scale?

Phase 3-4 - Research:

• Official FastAPI security docs (v0.109): OAuth2 with JWT, multiple security schemes
• GitHub issue #1234: Common mistake with dependency injection order
• Blog: "FastAPI Auth in Production at Company X" - Token refresh patterns
• Stack Overflow (maintainer answer): Security best practices

Phase 5 - Synthesis: "Use FastAPI's built-in OAuth2PasswordBearer with JWT tokens. Implement token refresh following the pattern in FastAPI docs. Key pitfall: dependency injection order matters—security dependencies must be defined before routes that use them (GitHub #1234). At scale, consider Redis for token blacklisting (Company X blog)."

References

This skill synthesizes research methodology from:

• Anthropic: "Building Effective Agents" (2024)
• OpenAI: Agents Guide, Deep Research documentation
• LangChain: RAG and Context Engineering docs
• GPT-Researcher: Research agent implementation patterns
• Academic: Plan-and-Solve (arXiv:2305.04091), RAG (arXiv:2005.11401)