deep-research

name	deep-research
description	Conduct high-quality multi-round research with explicit evidence tracking, source scoring, and synthesis.
version	2.0.0
author	Pulse Coder Team

Deep Research Skill

This skill is for serious research tasks where shallow summaries are not enough. Use it to build evidence-backed conclusions through iterative search, extraction, and validation.

When to Use

Use deep-research when you need to:

• Build a reliable understanding of a complex topic.
• Compare multiple approaches, vendors, or technical designs.
• Validate claims with primary sources and recent updates.
• Produce decision-ready output instead of a generic summary.

Do not use deep-research for simple factual lookups that need only 1-2 queries.

Research Quality Bar

Always optimize for:

• Coverage: enough breadth to avoid tunnel vision.
• Depth: enough source detail to avoid summary-only output.
• Verifiability: each key claim can be traced to sources.
• Freshness: prefer recent material when recency matters.
• Actionability: conclusions include practical implications.

Required Workflow

0) Frame the task first

Before searching, identify:

• Goal: what decision or understanding is needed.
• Scope: topic boundaries, region, timeframe, language.
• Output shape: comparison, recommendation, landscape, etc.

If critical constraints are missing, ask one concise clarification question.

1) Search in rounds (default 6-10 rounds)

Run iterative rounds and avoid repeating near-identical queries.

Per round, briefly track:

• Query used
• Intent of this query
• New findings (what changed vs prior rounds)
• Open gaps to resolve next

Suggested progression:

• Rounds 1-2: landscape and terminology
• Rounds 3-6: focused deep dives by subtopic
• Rounds 7-10: cross-checking, edge cases, and updates

If the user explicitly asks for very broad coverage (for example 30+ or 50+ rounds), use batching by subtopic and still maintain dedup and evidence quality.

2) Source selection and scoring (required)

For important claims, prefer sources in this order:

1. Official docs, standards, maintainers, first-party publications
2. Reputable technical analyses with concrete evidence
3. Community posts only as supplementary context

For each key source, judge quickly on:

• Authority (official or expert)
• Recency (is date still relevant)
• Evidence density (examples, data, implementation detail)
• Bias risk (marketing-only or unsupported claims)

3) Extract beyond snippets when needed

Search snippets are often insufficient. When a source is important but ambiguous, read/extract fuller content before concluding.

4) Cross-validate before final claims

Before finalizing, verify critical points across multiple independent sources. Explicitly flag:

• Consensus points
• Conflicts or disputed claims
• Unknowns that remain unresolved

5) Stop criteria

Stop when all are true:

• Core questions are answered
• Major contradictions are addressed
• Additional rounds produce low novelty

Otherwise continue with targeted rounds.

Query Strategy Guidelines

Use query patterns such as:

• " official documentation"
• " architecture tradeoffs"
• " benchmark OR case study"
• " limitations OR failure modes"
• " 2025 OR 2026 update"

Avoid low-value repetition:

• Do not run semantically duplicate queries unless testing source drift.
• Do not over-index on one domain unless it is primary documentation.

Output Format (Required)

Return results in this structure:

Overview

• Research objective and scope
• 3-6 key takeaways

Detailed Findings

• Grouped by subtopic
• Include concrete facts, not only opinions
• Attach source links to important claims

Evidence Matrix

• Claim
• Confidence (high/medium/low)
• Supporting sources (2+ when possible)
• Notes on caveats or conflicts

Comparison and Trade-offs (when applicable)

• Option A/B/C with pros, cons, and fit scenarios

Recommendations (when applicable)

• Clear, prioritized actions
• Short rationale for each action

Gaps and Open Questions

• What is still uncertain
• What to verify next if deeper research is needed

Sources

• Group links by primary vs secondary
• Prefer clean, non-duplicate URLs

Style and Reliability Rules

• Be explicit about uncertainty; do not fake confidence.
• Distinguish facts from interpretation.
• Do not present a single-source claim as settled truth.
• If evidence is weak, say so and recommend next checks.

Optional Post-Research Follow-up

After delivering research, optionally ask one follow-up question only when useful:

• "Do you want me to generate a frontend static webpage for this research summary?"

If user says yes:

• Detect available frontend and deployment skills at runtime.
• Build a readable static page with:
  • concise overview
  • expandable details (for example via
    )
  • sources with links
• Return deployment details: site_id, path, URL, local verify result.

If user says no:

• End cleanly, and mention webpage generation can be requested later.