/swing-research

name: swing-research
description: Deep research with cross-verification and source tiering. Use when investigating technologies, comparing tools, fact-checking claims, evaluating architectures, or any task requiring verified information. Triggers on "조사해줘", "리서치", "research", "investigate", "fact-check", "비교 분석", "검증해줘".
argument-hint: "[topic or question to research]"
allowed-tools: WebSearch, WebFetch, Read, Grep, Glob, Bash, Agent

Cross-Verified Research

Systematic research engine with anti-hallucination safeguards and source quality tiering.

Rules (Absolute)

1. **Never fabricate sources.** No fake URLs, no invented papers, no hallucinated statistics. 2. **Source-traceability gate.** Every factual claim must be traceable to a specific, citable source. If a claim cannot be traced to any source, mark it as **Unverified (internal knowledge only)** and state what verification would be needed. Never present untraced claims as findings. 3. **No speculation as fact.** Do not present unverified claims using hedging language as if they were findings. Banned patterns: "아마도", "~인 것 같습니다", "~로 보입니다", "~수도 있습니다", "probably", "I think", "seems like", "appears to be", "likely". If a claim is not verified, label it explicitly as **Unverified** or **Contested** — do not soften it with hedging. 4. **BLUF output.** Lead with conclusion, follow with evidence. Never bury the answer. 5. **Scaled effort.** Match research depth to question scope:

• **Narrow factual** (single claim, date, specification): 2-3 queries, 2+ sources
• **Technology comparison** (A vs B): 5+ queries, 5+ sources
• **Broad landscape** (market analysis, state-of-art): 8+ queries, 8+ sources

Default to the higher tier when scope is ambiguous. 6. **Cross-verify.** Every key claim must appear in 2+ independent sources before presenting as fact. "Independent" means the sources conducted their own analysis or reporting — two articles that both cite the same original source (press release, blog post, study) count as ONE source, not two. Trace claims back to their origin. 7. **Scope before search.** If the research question is ambiguous or overly broad, decompose it into specific sub-questions in Stage 1 and present them to the user for confirmation before proceeding to Stage 2. Do not research a vague question — sharpen it first.

Pipeline

Execute these 4 stages sequentially. Do NOT skip stages.

Stage 1: Deconstruct

Break the research question into atomic sub-questions.

Input: "Should we use Bun or Node.js for our backend?"
Decomposed:
  1. Runtime performance benchmarks (CPU, memory, startup)
  2. Ecosystem maturity (npm compatibility, native modules)
  3. Production stability (known issues, enterprise adoption)
  4. Developer experience (tooling, debugging, testing)
  5. Long-term viability (funding, community, roadmap)

• Identify what requires external verification vs. internal knowledge
• If the original question is vague or overly broad, present the decomposed sub-questions to the user for confirmation before proceeding (Rule 7)
• For each sub-question, note what a traceable source would look like

Stage 2: Search & Collect

For each sub-question requiring verification:

1. **Formulate diverse queries** — vary keywords, include year filters, try both English and Korean 2. **Use WebSearch** for broad discovery, **WebFetch** for specific page analysis 3. **Classify every source** by tier immediately (see Source Tiers below) 4. **Extract specific data points** — numbers, dates, versions, quotes with attribution 5. **Record contradictions** — when sources disagree, note both positions 6. **Trace origin** — when multiple sources cite the same underlying source, identify the original

Search pattern (scale per Rule 5):

Query 1: [topic] + "benchmark" or "comparison"
Query 2: [topic] + "production" or "enterprise"
Query 3: [topic] + [current year] + "review"
Query 4: [topic] + "issues" or "problems" or "limitations"
Query 5: [topic] + site:github.com (issues, discussions)

**Fallback when WebSearch is unavailable or returns no results:** 1. Use WebFetch to directly access known authoritative URLs (official docs, GitHub repos, Wikipedia) 2. Rely on internal knowledge but label all claims as **Unverified (no external search available)** 3. Ask the user to provide source URLs or documents for verification 4. Reduce the minimum source requirement but maintain cross-verification where possible

Stage 3: Cross-Verify

For each key finding:

• Does it appear in 2+ independent Tier S/A sources? → **Verified**
• Does it appear in only 1 source? → **Unverified** (label it)
• Do sources contradict? → **Contested** (present both sides with tier labels)

Remember: "independent" means each source did its own analysis. Two articles both citing the same benchmark study = 1 source.

Build a verification matrix:

| Claim | Source 1 (Tier) | Source 2 (Tier) | Status |
|-------|----------------|----------------|--------|
| Bun 3x faster startup | benchmarks.dev (A) | bun.sh/blog (B) | Verified (note: Bun's own blog = biased) |

Stage 4: Synthesize

Produce the final report in BLUF format.

Output Format

## Research: [Topic]

### Conclusion (BLUF)
[1-3 sentence definitive answer or recommendation]

### Key Findings
[Numbered findings, each with inline source tier labels]

1. **[Finding]** — [evidence summary]
   Sources: 🏛️ [source1], 🛡️ [source2]

2. **[Finding]** — [evidence summary]
   Sources: 🛡️ [source1], 🛡️ [source2]

### Contested / Uncertain
[Any claims that couldn't be cross-verified or where sources conflict]
- ⚠️ [claim] — Source A says X, Source B says Y

### Verification Matrix
| Claim | Sources | Tier | Status |
|-------|---------|------|--------|
| ... | ... | ... | Verified/Unverified/Contested |

### Sources
[All sources, grouped by tier]

#### 🏛️ Tier S — Academic & Primary Research
- [Title](URL) — Journal/Org (Year)

#### 🛡️ Tier A — Trusted Offici