菜单
Use when planning features and need current API docs, library patterns, or external knowledge; when testing hypotheses about technology choices or claims; when verifying assumptions before design decisions - gathers well-sourced, current information from the internet to inform technical decisions
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when analyzing a large corpus of text, code, or data that exceeds a single agent's effective context - orchestrates parallel Worker subagents, Critic review subagents, and a final Summarizer subagent with task tracking and failure recovery
Use to decide what kind of basic agent you should use
Use when creating a new opencode plugin or setting up plugin structure - provides complete file organization, manifest format, and component definitions for commands, agents, skills, hooks, and MCP servers
Use when creating specialized subagents for opencode or the task tool - covers description writing for auto-delegation, tool selection, prompt structure, and testing agents
Use when creating, releasing, or maintaining an opencode Plugin Marketplace - covers marketplace.json schema, version management, release checklists, changelog conventions, and validation to prevent sync drift between plugin.json and marketplace.json
Use when completing development phases or branches to identify and update AGENTS.md files that may have become stale - analyzes what changed, determines affected contracts and documentation, and coordinates updates
| name | researching-on-the-internet |
| description | Use when planning features and need current API docs, library patterns, or external knowledge; when testing hypotheses about technology choices or claims; when verifying assumptions before design decisions - gathers well-sourced, current information from the internet to inform technical decisions |
Gather accurate, current, well-sourced information from the internet to inform planning and design decisions. Test hypotheses, verify claims, and find authoritative sources for APIs, libraries, and best practices.
Use for:
Don't use for:
When given a hypothesis to test:
Example:
Hypothesis: "Library X is faster than Y for large datasets"
Search for:
✓ Benchmarks comparing X and Y
✓ Performance documentation for both
✓ GitHub issues mentioning performance
✓ Real-world case studies
Report:
- Supported: [evidence with links]
- Contradicted: [evidence with links]
- Conclusion: [supported/contradicted/mixed] with [confidence level]
| Task | Strategy |
|---|---|
| API docs | Official docs → GitHub README → Recent tutorials |
| Library comparison | Official sites → npm/PyPI stats → GitHub activity |
| Best practices | Official guides → Recent posts → Stack Overflow |
| Troubleshooting | Error search → GitHub issues → Stack Overflow |
| Current state | Release notes → Changelog → Recent announcements |
| Hypothesis testing | Define claims → Search both sides → Weight evidence |
| Tier | Sources | Usage |
|---|---|---|
| 1 - Most reliable | Official docs, release notes, changelogs | Primary evidence |
| 2 - Generally reliable | Verified tutorials, maintained examples, reputable blogs | Supporting evidence |
| 3 - Use with caution | Stack Overflow, forums, old tutorials | Check dates, cross-verify |
Always note source tier in findings.
Multiple approaches:
websearch for overview and current informationwebfetch for specific documentation pagesCross-reference:
Lead with answer:
Include metadata:
Handle uncertainty clearly:
| Mistake | Fix |
|---|---|
| Searching only one source | Cross-reference minimum 2-3 sources |
| Ignoring publication dates | Check dates, flag outdated information |
| Treating all sources equally | Use tier system, weight accordingly |
| Reporting before verification | Verify claims across sources first |
| Vague hypothesis testing | Break into specific falsifiable claims |
| Skipping official docs | Always start with tier 1 sources |
| Over-confident with single source | Note source tier and look for consensus |