$npx -y skills add Rune-kit/rune --skill researchWeb search and external knowledge lookup. Gathers data on technologies, libraries, best practices, and competitor solutions.
| 1 | # research |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Web research utility. Receives a research question, executes targeted searches, deep-dives into top results, and returns structured findings with sources. Stateless — no memory between calls. |
| 6 | |
| 7 | ## Calls (outbound) |
| 8 | |
| 9 | None — pure L3 utility using `WebSearch` and `WebFetch` tools directly. |
| 10 | |
| 11 | ## Called By (inbound) |
| 12 | |
| 13 | - `plan` (L2): external knowledge for architecture decisions |
| 14 | - `brainstorm` (L2): data for informed ideation |
| 15 | - `marketing` (L2): competitor analysis, SEO data |
| 16 | - `hallucination-guard` (L3): verify package existence on npm/pypi |
| 17 | - `autopsy` (L2): research best practices for legacy patterns |
| 18 | - `ba` (L2): research similar products and integrations |
| 19 | - `graft` (L2): research source repo patterns before grafting |
| 20 | - `mcp-builder` (L2): research MCP standards and existing implementations |
| 21 | - `scaffold` (L1): research project templates and best practices |
| 22 | |
| 23 | ## Execution |
| 24 | |
| 25 | ### Input |
| 26 | |
| 27 | ``` |
| 28 | research_question: string — what to research |
| 29 | focus: string (optional) — narrow the scope (e.g., "security", "performance") |
| 30 | ``` |
| 31 | |
| 32 | ### Step 1 — Formulate Queries |
| 33 | |
| 34 | Generate 2-3 targeted search queries from the research question. Vary phrasing to cover different angles: |
| 35 | - Primary: direct question as search terms |
| 36 | - Secondary: "[topic] best practices 2026" or "[topic] vs alternatives" |
| 37 | - Tertiary: "[topic] example" or "[topic] tutorial" if implementation detail needed |
| 38 | |
| 39 | ### Step 2 — Search (Minimum 3 Complementary Sources) |
| 40 | |
| 41 | <HARD-GATE> |
| 42 | Every research conclusion MUST be backed by at minimum 3 complementary sources from DIFFERENT source types. |
| 43 | Single-source conclusions are flagged as `low` confidence regardless of source authority. |
| 44 | </HARD-GATE> |
| 45 | |
| 46 | Call `WebSearch` for each query. Collect result titles, URLs, and snippets. Identify the top 3-5 most relevant URLs prioritizing **source diversity**: |
| 47 | |
| 48 | | Source Type | Examples | Why | |
| 49 | |-------------|----------|-----| |
| 50 | | **Official docs** | Framework docs, API reference, RFC | Authoritative but may lag behind reality | |
| 51 | | **Community** | Stack Overflow, GitHub Issues, Reddit | Real-world pain points, edge cases | |
| 52 | | **Technical blogs** | Dev.to, Medium engineering blogs, personal blogs | Practical experience, tutorials | |
| 53 | | **Repositories** | GitHub repos, npm packages, example code | Working implementations | |
| 54 | |
| 55 | **Selection rules:** |
| 56 | - Source authority (official docs > major blogs > personal blogs) |
| 57 | - Recency (prefer 2025-2026) |
| 58 | - Relevance to the query |
| 59 | - **Diversity: never select 3+ URLs from the same domain** — spread across source types |
| 60 | |
| 61 | |
| 62 | ### Step 2b — Diminishing Returns Detection |
| 63 | |
| 64 | After each WebSearch call, evaluate whether additional searches are productive: |
| 65 | |
| 66 | **Track across search results**: |
| 67 | - **Entity set**: Extract key entities from each result set (library names, API names, version numbers, technique names, company names) |
| 68 | - **New entity ratio**: `new_entities_in_this_search / total_entities_found_so_far` |
| 69 | - **Result overlap**: How many URLs from this search were already seen in previous searches |
| 70 | |
| 71 | | Signal | Threshold | Action | |
| 72 | |--------|-----------|--------| |
| 73 | | New entity ratio < 10% | Last search added almost nothing new | Skip remaining queries, proceed to Step 3 with existing results | |
| 74 | | Result overlap > 60% | Most URLs already fetched or seen | Skip this query's results entirely | |
| 75 | | All 3 queries return same top 3 URLs | Search space is exhausted | Proceed directly to Step 3 — more queries won't help | |
| 76 | |
| 77 | **Report when triggered**: |
| 78 | ``` |
| 79 | Note: Research saturation reached after [N] searches — [M] unique entities found. |
| 80 | Additional queries showed <10% new information. Proceeding with synthesis. |
| 81 | ``` |
| 82 | |
| 83 | **Why**: Research skills commonly waste 2-3 WebFetch calls on pages that repeat information already gathered. Saturation detection saves tool calls and context tokens while preserving research quality — the first 3 sources typically contain 90%+ of available information. |
| 84 | |
| 85 | ### Step 3 — Deep Dive |
| 86 | |
| 87 | Call `WebFetch` on the top 3-5 URLs identified in Step 2. Hard limit: **max 5 WebFetch calls** per research invocation. For each fetched page: |
| 88 | - Extract key facts, API signatures, code examples |
| 89 | - Note the source URL and publication date if visible |
| 90 | - Tag the source type (official/community/blog/repo) for Step 4 triangulation |
| 91 | |
| 92 | ### Step 4 — Synthesize (Triangulation) |
| 93 | |
| 94 | Across all fetched content, **triangulate** — don't just aggregate: |
| 95 | - Identify points of consensus across sources (≥3 sources = strong signal) |
| 96 | - Flag any conflicting information explicitly (e.g., "Source A says X, Source B says Y") |
| 97 | - Check if conflicts are temporal (old vs new info) or genuine disagreement |
| 98 | - Assign confidence using source diversity: |
| 99 | |
| 100 | | Confidence | Criteria | |
| 101 | |------------|----------| |
| 102 | | `high` | 3+ sources from differe |