RW Research Lab Router

Startup

1. Read

   references/standalone.md

   ,

   references/method.md

   , and

   references/standards.md

   .
2. Read the materials provided by the user in this round; if no materials are provided, only complete the parts allowed by current evidence.
3. Retrieve

   references/atoms.jsonl

   when rule judgment is required; read

   references/cases.md

   when encountering similar tasks.
4. Read

   references/domain-guide.md

   when selecting methods or tools, and use

   assets/worksheet.md

   to organize deliverables.
5. Read

   references/acceptance.md

   .

   references/behavior-tests.json

   is only used for testing and not as facts for user tasks.
6. When current literature, APIs, report specifications, or journal requirements may change, open the official links in

   references/source-map.md

   for verification and record the date.

Work Stages

1. Confirm the task, input format, data sensitivity, operating environment, deliverables, and acceptable failure modes.
2. Break down the task into discovery, acquisition, deduplication, extraction, evaluation, synthesis, statistics, visualization, or writing checks.
3. Inventory currently available local commands, Python packages, APIs, web tools, and user-provided repositories.
4. Check licenses, certifications, costs, rate limits, maintenance status, data outbound, and reproducibility.
5. Select a preferred tool and a fallback solution, and design a minimal sample test.
6. Run or describe the minimal test, recording versions, commands, results, failures, and stop conditions.

Operating Rules

• Select tools based on tasks and inputs first, not tasks based on existing repo names.
• Local research-lab is an optional integration, not a prerequisite for operation.
• Code being installable or compilable does not mean real-time APIs, models, or data sources are available.
• Tool outputs must retain inputs, versions, parameters, and sources.
• Do not confuse tool discovery and systematic review database coverage.
• API metadata may be incomplete; cross-verify key identifiers.
• Check rate limits, authentication, costs, and terms of service before batch runs.
• Prioritize local or approved processing paths for sensitive data.
• Use minimal sample tests for fields and failure handling in batch tasks.
• Calculate manual review costs when selecting tools.
• Repository popularity, star count, and recent commits alone cannot prove suitability.
• When no suitable tool is available, output an executable manual process instead of forcing a selection.

Output

• Preferred tool, fallback solution, and selection reasons.
• Environment, license, privacy, and cost requirements.
• Minimal test, results, and stop conditions.

Stop Conditions

• Do not claim that a tool is currently available without operational evidence.
• Do not upload sensitive research data to unauthorized platforms.
• Do not stop tool routing due to the absence of a certain local directory.
• Do not automatically install, log in, pay, or modify the production environment.

Standalone Operation

• By default, do not read private workspaces, personal corpus directories, or preset research-lab.
• Files, text, links, and data provided by the user are inputs for the current task, not installation dependencies.
• When the network is unavailable, continue using stable methods within the Skill; mark parts requiring current facts as pending verification.
• Can connect with other research Skills in this package if they exist; when installed alone, directly return instructions for the next step without stopping the current task.

Source Discipline

• Separate user materials, public sources, current inferences, and unknown matters.
• Report specifications only check report transparency, not automatically prove design quality.
• Public source abstracts are stored within the Skill; return to official pages when needing versions, costs, policies, APIs, or current journal requirements.
• Do not generate non-existent papers, data, DOIs, tool operation results, or journal requirements.