net-deep-research

SKILL.md

---
name: net-deep-research
description: Perform deep multi-source internet research before answering. Use when the user prefixes a request with /net, asks for the latest information, wants real-time facts, requests web verification, asks which framework, tool, product, policy, or implementation path is best right now, or needs evidence-based answers synthesized from multiple public sources such as official docs, official sites, GitHub, package registries, standards sites, and other stable public references.
---
# Net Deep Research

When this skill is triggered, do not answer immediately.

Turn the request into a controlled research workflow:
1. classify the question,
2. normalize the scope,
3. decompose it into subquestions,
4. derive critical claims,
5. research in rounds,
6. resolve or expose conflicts,
7. answer from a structured evidence map.

## Trigger Handling

If the user message starts with `/net`:
- remove the `/net` prefix
- trim whitespace
- treat the remainder as the actual research question

Then restate the question in one sentence before researching.

## Goal

Produce answers that are:
- current
- evidence-based
- multi-source
- explicit about uncertainty
- grounded in stable public sources
- clear about what is verified vs inferred

## Hard Rules

Apply these rules strictly:
1. For predictive, forward-looking, market, macro, or scenario questions, separate the answer into two layers:
   - `Verified Facts`
   - `Inference`
2. Tie every core conclusion to at least one primary source whenever possible.
3. Do not let secondary media, commentary, or community discussion be the only support for a key conclusion when a stronger source family is available.
4. If direct official fetching fails, use the fixed fallback order instead of ad hoc substitution.
5. Do not skip subquestion decomposition for non-trivial questions.
6. Do not treat multiple pages repeating the same original announcement as independent evidence.

## Mode Selection

Choose one `primary_mode`. Add one `secondary_mode` only if it clearly helps.

### Mode A: Current Fact Check
Use for questions about latest status, current availability, recent releases, or whether something is already live.

### Mode B: Capability Or Compatibility Verification
Use for questions about support, compatibility, feature availability, plans, versions, models, or platforms.

### Mode C: Implementation Or How-To Research
Use for questions about how to build, integrate, deploy, or implement something, including best practices and architecture.

### Mode D: Comparison, Selection, Or Policy Confirmation
Use for questions about choosing among alternatives, policy confirmation, framework selection, official rules, or tradeoff analysis.

## Classification Rules

Apply these rules in order:
1. If the question is about how to implement, integrate, deploy, or build, choose `Mode C`.
2. If the question is about comparing options, choosing the best option, or checking policy or official rules, choose `Mode D`.
3. If the question is about support, compatibility, or whether a feature exists, choose `Mode B`.
4. If the question is about the latest or current status of a fact, choose `Mode A`.

Use a secondary mode only when both are necessary:
- `Mode A + Mode B`: current support status
- `Mode B + Mode C`: whether possible, then how to implement
- `Mode D + Mode C`: choose a solution, then outline implementation

## Question Normalization

Before searching, extract:
- `subject`
- `target_capability` if any
- `time_scope` if provided
- `region_scope` if provided
- `version_scope` if provided

Do not invent missing scopes.

Then rewrite the request as one normalized question.

## Subquestion Decomposition

Before extracting claims, decompose the normalized question into up to 6 subquestions.

Always try to produce:
- `core_subquestions`: what must be answered to resolve the user's request
- `verification_subquestions`: what boundaries, prerequisites, or limitations must be checked
- `countercheck_subquestions`: what likely counterexamples, exceptions, or contradictions should be tested

For simple questions, 2-3 subquestions is enough.
For complex questions, use 4-6 subquestions.

Do not skip this step unless the question clearly qualifies for fast path.

## Claim Extraction

Derive at most 3 critical claims from the subquestions.

Typical claim shapes:
- whether the capability exists
- when the capability became available
- what scope, limitations, or exclusions apply
- which option best fits the user's goal
- what implementation path is most appropriate

Every important conclusion in the final answer should map back to one of these claims.

## Query Planning

Plan queries per claim, not just per question.

For each important claim, generate these core query slots:
- `direct_query`
- `official_query`
- `release_query`
- `contradiction_query`

Add one mode-specific slot:
- `Mode A` -> `recent_query`
- `Mode B` -> `compatibility_query`
- `Mode C` -> `implementation_query`
- `Mode D` -> `comparison_query` or `policy_query`

Keep the total query count between 4 and 8 for a normal request.

For technical, product, framework, or API questions, prefer bilingual query planning when helpful:
- use English queries for official docs, repos, and release notes
- use Chinese queries for China-specific products, policy, regional availability, or local interpretation
- do not force bilingual searching when the domain is clearly single-language

## Research Rounds

Use a staged research workflow.

### Round 1: Primary Evidence
Search primary and official sources first.
Goal: establish the strongest direct evidence for each claim.

### Round 2: Independent Verification
Add independent support from a different strong source family.
Goal: confirm scope, version, timing, or practical limitations.

### Round 3: Conflict Resolution
Run only when needed.
Trigger this round when:
- strong sources disagree
- timing or version differences matter
- region or plan differences may explain the conflict
- the answer would otherwise rely on weak evidence

Goal: explain the disagreement, not just note it.

## Research Budget And Stop Rules

Use these defaults unless the question clearly demands more depth:
- `max_search_rounds = 3`
- `target_primary_sources_per_core_claim = 1`
- `target_total_supporting_sources_per_core_claim = 2`
- `max_key_claims = 3`

Stop when all of these are true:
- each core claim has direct support or a clearly stated evidence gap
- no major unresolved conflict blocks the main answer
- uncertainty is explicit where evidence is weak

Escalate to another search round when any of these are true:
- a claim depends only on weak or secondary support
- a key source appears outdated for the user's time scope
- two strong sources materially disagree
- implementation advice depends on unverified capability assumptions

## Source Routing

Use source families, not fixed websites, as the primary routing method.

### Mode A Priority
1. official announcement, changelog, release notes
2. official docs
3. official repository releases
4. high-quality secondary reporting

### Mode B Priority
1. official docs
2. API reference or SDK docs
3. official repository, release, or issue
4. package registry pages

### Mode C Priority
1. official docs
2. official repository README, examples, guides
3. package registry pages
4. stable technical references

### Mode D Priority
1. official docs or official sites
2. government, institutional, or standards sources when relevant
3. official repository, pricing, feature, or explanation pages
4. high-quality secondary analysis

## Preferred Source Families

Prefer these source families when relevant:
- official documentation sites
- official company or organization sites
- official changelogs and release notes
- GitHub repositories and releases
- package registries such as PyPI and npm
- standards sites such as RFC, IETF, and W3C
- government and institutional sites
- stable technical references such as MDN

## Accessibility, Stability, And Dedup Rules

Prefer sources that are:
- public
- readable without login
- likely to remain available
- broadly reachable for both international and China-based users when possible

Avoid depending on:
- login-gated content
- short-form social posts
- low-signal community threads as the only evidence
- content farms or SEO spam pages
- unattributed reposts

If direct official fetching fails, use this fixed fallback order and do not skip steps:
- official page -> official mirror or official alternate page -> official changelog or release note -> official GitHub or official repository page -> package registry or standards page -> stable technical reference
- government or institution page -> official FAQ -> official press release -> official transcript or bulletin -> high-quality institutional analysis

Apply source dedup rules:
- do not count mirrored pages of the same original announcement as independent evidence
- do not count a media rewrite of an official post as a separate primary source
- treat same-origin release note plus marketing page as one source family unless they provide materially different evidence

## Source Filtering And Scoring

Reject a source as key evidence if it:
- requires login for the core content
- does not clearly support any claim
- is only a repost without the original source
- is obviously low quality or SEO-generated

Score each candidate source across 6 dimensions, each from 0 to 2.
Apply the rules for each dimension mechanically: start from score 2 and walk down until a condition matches.
Total score range: `0-12`.

---

### 1. authority — who published it

Apply these checks in order. Stop at the first match.

| Condition | Score |
|---|---|
| The domain IS the official domain of the subject under research (e.g. `nextjs.org` for Next.js, `python.org` for Python, `rust-lang.org` for Rust) | 2 |
| The domain IS a `.gov`, `.edu`, or standards-body domain (e.g. `rfc-editor.org`, `w3.org`, `ietf.org`, `iso.org`, `ieee.org`) | 2 |
| The page IS on the subject's own GitHub/GitLab org (e.g. `github.com/facebook/react` for React) | 2 |
| The page IS on a curated developer reference platform (e.g. `MDN`, `caniuse.com`, `web.dev`, `docs.rs`, `nodejs.org/api`) | 1 |
| The page IS an official package-registry entry (e.g. `npmjs.com/package/*`, `pypi.org/project/*`, `crates.io/crates/*`) | 1 |
| The page IS authored by a verified project maintainer or recognized core contributor (e.g. a maintainer's blog, their personal GitHub, a signed commit/issue) | 1 |
| The page IS on an established tech publication with editorial process (e.g. `arstechnica.com`, `lwn.net`, `theverge.com` for product news only) | 1 |
| None of the above match | 0 |

---

### 2. stability — will this URL still work in 12 months

**Prefer automated scoring.** For each candidate URL, run the bundled Python scorer first:

```
python3 tools/score_stability.py --json "<url>"
```

This returns `{"score": <0|1|2>, "rule": "<matched_rule>", "explanation": "..."}`.

Use the returned score directly. Only fall back to manual scoring when the Python runtime is unavailable.

Manual scoring rules (identical to the script's logic, for reference):

| Condition | Score |
|---|---|
| The URL IS a GitHub/GitLab permalink: `/releases/tag/*`, `/blob/<sha>/*`, `/commit/*`, or a repo root with a fixed name | 2 |
| The URL IS on `docs.*` subdomain, `*.readthedocs.io`, `*.github.io`, or a `/docs/*` path on the official domain | 2 |
| The URL IS a `.gov`, `.edu`, standards-body, or institutional archive page | 2 |
| The URL IS a package-registry permalink (e.g. `npmjs.com/package/<name>`, `pypi.org/project/<name>`) | 2 |
| The URL IS an official blog post on the project's own domain (e.g. `nextjs.org/blog/*`) | 1 |
| The URL IS an official mirror or alternate-source page | 1 |
| The URL IS a reputable news outlet or established tech-publication article | 1 |
| The URL IS a third-party blog platform (e.g. `medium.com`, `dev.to`) — content may be reorganized or paywalled later | 1 |
| The page IS a social-media post (Twitter/X, Reddit, Hacker News, etc.) or a personal blog with no institutional backing | 0 |
| The URL contains session IDs, temporary tokens, or link-shortener domains (`t.co`, `bit.ly`, etc.) | 0 |

---

### 3. accessibility — can anyone read it without barriers

Apply these checks in order. Stop at the first match.

| Condition | Score |
|---|---|
| Page loaded successfully with NO login prompt, NO paywall overlay, NO captcha challenge, and NO geo-block | 2 |
| Page loaded but requires a free account to view beyond the first N paragraphs (e.g. Medium metered wall) | 1 |
| Page loaded but the site is known to be geo-restricted in some major regions (e.g. `bard.google.com` in specific regions) | 1 |
| Page requires login or paid subscription to view the core content; the visible portion is only a summary | 0 |
| Page is entirely behind a paywall, login wall, or captcha gate | 0 |

---

### 4. freshness — how current relative to the question's time scope

This dimension is scored **relative to the question**, not by absolute recency alone.

**Step 1: Determine the reference window.**

| Question has... | Reference window |
|---|---|
| Explicit `time_scope` (e.g. "in 2024", "last month", "since v18") | Use the user-stated window |
| A specific version number | Match against that version only |
| No time scope | Default to last 12 months |

**Step 2: Assign score based on how the source falls relative to the window.**

| Condition | Score |
|---|---|
| Source was published or last-updated WITHIN the reference window, AND explicitly covers the version/timeline asked | 2 |
| Source was published or last-updated within the reference window, but does not explicitly mention dates or versions | 1 |
| Source date is UNKNOWN but the content appears current (e.g. mentions a recent feature, links to up-to-date references) | 1 |
| Source was published or last-updated 12-24 months outside the reference window, but no evidence it has been superseded | 1 |
| Source is clearly OUTSIDE the reference window by > 24 months | 0 |
| Source has been explicitly SUPERSEDED by a later official announcement, release, or deprecation notice | 0 |

For version-specific questions, apply this version-based override:
| Condition | Score |
|---|---|
| Source explicitly documents or references the target version | 2 |
| Source covers a nearby version (± 1 major) with the same API surface | 1 |
| Source covers a version known to have breaking changes relative to the target | 0 |

---

### 5. relevance — does the content directly address the claim

Quantified by evidence proximity: how many inference steps are needed to connect source content to the claim.

| Condition | Score |
|---|---|
| Source contains a direct, explicit statement that confirms or refutes the claim — zero inference steps needed | 2 |
| Source covers the general topic and allows ONE logical inference step to reach the claim (e.g. it lists a supported feature set, and the user's feature is clearly inside/outside it) | 1 |
| Source only mentions the topic tangentially, or requires TWO OR MORE inference steps to connect to the claim | 0 |
| Source is about a different subject entirely | 0 |

---

### 6. primacy — how close is this to the original information

This dimension punishes mirroring. Two pages repeating the same official announcement should not both score high.

| Condition | Score |
|---|---|
| This IS the original source: the official announcement, the original research paper, the first-hand documentation, the actual release note, the commit itself | 2 |
| This is a SECONDARY source that retells or analyzes the original, but ADDS meaningful original context (e.g. new benchmark data, a comparison the original didn't do, an implementation walkthrough) | 1 |
| This is a TERTIARY or DERIVATIVE source: a pure repost, a summary without added insight, a "news roundup", or a mirrored press release | 0 |
| This is a community discussion that merely links to or quotes the primary source without adding verified new information | 0 |

---

### Minimum Rules

- Do not use a source with total score below **5** (out of 12) as key evidence
- Every important claim must have at least one source with **both** `authority >= 1` AND `relevance >= 1`
- Every core conclusion must be anchored to at least one source with `primacy = 2` whenever possible
- If a claim's best source has `primacy = 0`, explicitly flag this as a "derivative only" evidence gap
- Must report the 6-dimension score breakdown for any source used as key evidence in the Sources section (e.g. `A:2 S:2 A:2 F:1 R:2 P:2 = 11/12`)

### Scoring Shortcuts (for fast triage)

Before doing the full 6-dimension score, apply these instant-reject / instant-accept shortcuts:

| Shortcut | Action |
|---|---|
| Source is a social media post (Twitter/X, Reddit, HN) AND is not from a verified project maintainer account | Auto-score authority=0, stability=0; proceed with remaining 4 dims only |
| Source is a content farm, SEO spam, or AI-generated slop | Reject immediately; do not score |
| Source is the official GitHub release page of the EXACT project the user asked about | Auto-score authority=2, stability=2, primacy=2; score remaining 3 dims fresh |
| Source is a community forum (StackOverflow, Reddit thread) with an accepted answer from a recognized maintainer | Score normally; authority may be 1 for the maintainer's answer

## Evidence Extraction

For each claim, extract evidence items with:
- `claim_id`
- `source_title`
- `source_url`
- `source_date_hint` if available
- `evidence_snippet`
- `source_score`
- `stance`: `support`, `oppose`, or `partial`

Do not over-quote. Extract only the part needed to support the claim.

## Conflict Handling

If a claim has both supporting and opposing evidence, explicitly mark it as conflicted.

Only use these conflict causes:
- version difference
- timing difference
- region difference
- plan tier difference
- wording ambiguity
- evidence insufficiency

Do not invent a conflict explanation without support.

When a claim is conflicted, internally build this mini-structure before answering:
- `claim`
- `supporting_evidence`
- `opposing_evidence`
- `conflict_cause`
- `current_best_explanation`
- `residual_uncertainty`

## Confidence Rules

Assign confidence per key claim:

### High
- at least 2 supporting sources
- at least 1 strong primary source
- no major unresolved conflict

### Medium
- at least 1 reasonably strong source
- some scope limitation or minor conflict

### Low
- only weak support
- or unresolved conflict
- or no clear primary source

## Evidence Map

Before writing the answer, build this internal structure:
- `question_restatement`
- `primary_mode`
- `secondary_mode` if any
- `normalized_question`
- `subquestions`
- `claims`
- `evidence_by_claim`
- `conflicts`
- `uncertainties`
- `final_conclusions`
- `answer_outline`

For predictive, market, macro, or outlook questions, the evidence map must also separate:
- `verified_facts`
- `inference`

Do not skip this step.

## Final Answer Format

Default section order:
1. `Question Restatement`
2. `Short Answer`
3. `Key Findings`
4. `Cross-Source Notes`
5. `Uncertainties or Limits`
6. `Sources`

For predictive, market, macro, or outlook questions, use this stricter order:
1. `Question Restatement`
2. `Short Answer`
3. `Verified Facts`
4. `Inference`
5. `Cross-Source Notes`
6. `Uncertainties or Limits`
7. `Sources`

For implementation or comparison questions, add a concise `Recommendation` block when useful.

## Writing Rules

In `Short Answer`:
- answer directly
- keep it concise

In `Key Findings`:
- separate confirmed facts from implications
- prioritize evidence from official or primary sources
- tie each core conclusion back to a claim

In `Cross-Source Notes`:
- explain where sources agree
- explain where they differ
- mention version, timing, regional, or plan differences when relevant

In `Verified Facts`:
- include only directly supported facts
- keep interpretation minimal
- attach stronger sources first

In `Inference`:
- derive each inference from the verified facts above
- do not present inference as confirmed fact
- explicitly signal when the inference depends on policy, timing, or assumption-sensitive interpretation

In `Uncertainties or Limits`:
- clearly state what could not be verified
- clearly state if official sources were unavailable and fallback layers were used
- do not hide missing evidence

In `Sources`:
- list the most useful sources, not every weak result
- prefer strong primary sources first

## Fast Path

Use fast path only when:
- the question is simple
- there is a clear primary source
- there is little risk of ambiguity

Even then:
- check the primary source
- add one independent supporting source if practical
- skip fast path if the answer depends on version, timing, region, or plan differences

## Example Handling Pattern

If the user asks:
- `/net What is the best agent framework right now, and use it to help me design a game?`

Then:
- classify as `Mode D` with `Mode C` secondary
- normalize the user goal and split it into selection and implementation subquestions
- compare current agent framework candidates using official docs, GitHub, releases, and stable public references
- verify the top candidate with at least one independent supporting source
- resolve any conflict about maturity, maintenance, or capability scope
- decide which framework best fits the requested goal
- then outline a game-building workflow using that framework
- clearly separate:
  - evidence for framework selection
  - implementation guidance for the game workflow

## Final Reminder

Research first.
Model the question second.
Resolve conflicts third.
Answer last.