dig-deep
Multi-Source Deep Technical Research & Verification
- ✓ When evaluating competing frameworks, libraries, or cloud technologies for production adoption.
- ✓ When investigating intricate technical bugs or root-cause post-mortems.
- ✓ When researching state-of-the-art architectures, RFCs, or consensus protocols.
- ✓ When making high-stakes technical architectural decisions that require multi-source consensus.
Trigger: Activated when the user requests an in-depth technical deep-dive, library comparison, or architectural investigation.
"Dig deep into NATS JetStream vs Kafka for IoT geospatial telemetry."
Multi-Source Evidence Cross-Referencing & Structured Synthesis
100,000 token budget for clean, targeted research lookups without context bloat.
Saves structured technical reports to docs/research/[topic-slug].md.
Reference Specifications (`references/`)
Hierarchical source reliability ranking (RFCs/Official Docs > Engineering Blogs > Community Articles).
Framework-specific focus areas for library evaluations, bug post-mortems, and architectural surveys.
Standardized markdown template enforcing factual claims, trade-off matrices, and actionable conclusions.
Executive Overview
Generic LLM search lookups often produce superficial summaries filled with hallucinated APIs, outdated library syntax, or regurgitated marketing fluff.
dig-deep is an evidence-backed technical research skill engineered to function like a Staff Research Engineer. It searches at least 5 distinct, authoritative sources, cross-examines conflicting engineering claims, and generates production-ready whitepapers stored in docs/research/.
3-Phase Research Protocol
[Phase 1: Research Brief] --> Formulates 3-5 targeted research questions with user
↓
[Phase 2: Execution] --> Queries >= 5 distinct sources across hierarchical tiers
↓
[Phase 3: Synthesis] --> Formulates comparative tables & saves docs/research/*.md
1. Hierarchical Source Priority (source-priority.md)
To guarantee technical integrity, dig-deep evaluates sources in strict order of authority:
- Tier 1 (Primary / Authoritative): Official vendor documentation, RFC specifications, language standards (TC39, ISO C++, PEP), and open-source repository source code.
- Tier 2 (Enterprise Engineering Blogs): Engineering blogs of companies operating at hyperscale (e.g., Uber, Netflix, Meta, Cloudflare, Discord).
- Tier 3 (Peer-Reviewed / Benchmark Papers): Academic papers (arXiv), formal benchmarks, and published CVE disclosures.
- Disallowed as Primary Anchors: Forum posts, Reddit, or opinionated personal blogs are strictly restricted to secondary anecdotal context and can never anchor a conclusion.
Zero-Hallucination Guardrails
- Consensus Checking: A claim is only accepted as fact if confirmed by multiple independent Tier 1 or Tier 2 sources.
- Explicit Knowledge Gaps: If documentation is contradictory or unverified, the skill explicitly states: “Knowledge gap identified: Source A asserts X, while Source B benchmarks Y. Marked as unverified.”
- Production Library Vetting: When evaluating dependencies,
dig-deepanalyzes GitHub stars, commit cadence, release frequency, open CVEs, and dependency bloat before recommending adoption.