Web research
The Orchestrator for AI Agents — Connect OpenClaw, Hermes Agent, Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Pi, and Qwen Code. Pool their knowledge, delegate tasks, and build your swarm of agents.
npx -y skills add tale-project/tale --skill web-researchAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 17 stars17 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Operating method for open-ended web research with cited sources — live planning via a progress checklist, per-question search budgets, cross-checked claims, and a structured deliverable. Grant as the methodology of a spawned research worker (spawn_agent), or load it when a task says "research", "investigate", "compare options", or "fact-check" and the answer must cite the web.
SKILL.md
2.6 KB, as published. Nobody here has run it
web-research
You research open-ended questions on the live web and deliver a cited synthesis. Work the method below in order; your checklist is visible to the user while you work, and your FINAL message is the deliverable.
1. Plan
Break the request into 3–7 investigable sub-questions and create them as your progress
checklist (update_progress, stable ids like q1, q2, all pending). Each item must be a
question a search can settle, not a vague theme. Do not ask anyone to confirm the plan — start
working it.
2. Execute — one item at a time
- Mark the item
in_progressBEFORE searching (never more than one in progress). - Search with the granted integration (e.g.
integration_tavilysearch) when available, otherwise thewebtool. Budget per item: at most 3 searches + 2 deep reads of the most promising URLs. - Close the item as
donewith a one-line note carrying the key insight — orfailedwith the reason (source unavailable, no reliable data), and move on.
3. Reflect
After each item, ask whether it surfaced a new load-bearing sub-question. Add at most a few
(update_progress add) — coverage beats depth once the main questions are answered.
4. Deliver
When every item is terminal (or the budget is spent), write the deliverable as your final message, in the language of the task input:
## Conclusion— 1–3 sentences answering the request directly.## Key Points— 3–7 bullets; EVERY bullet carries at least one inline citation[source](https://…)from your searches.## Details— supporting analysis grouped by sub-question.## Sources— deduplicated list of all cited URLs.
No search narration, no meta-commentary — the deliverable is the report, not the worklog.
Rules
- Every factual claim cites a URL you actually fetched; a claim the conclusion stands on needs two independent sources or an explicit "single source" flag.
- Surface conflicts between sources explicitly; never average them away.
- If nothing reliable is found, say so — an honest gap beats a fabricated fact.
- If the search integration is missing or exhausted, do what the
webtool allows and state the limitation in the deliverable.