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.

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):

3. accessibility — can anyone read it without barriers

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

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.

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

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.

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.

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:

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.