web-research
Findings grounded in live web sources
git clone --depth 1 https://github.com/asgeirtj/system_prompts_leaks /tmp/web-research && cp -r /tmp/web-research/Anthropic/claude-design/skills/web-research ~/.claude/skills/web-researchSKILL.md
# Web research
The user wants findings grounded in current, real sources — not your
prior knowledge alone. Use the web_search and web_fetch tools to
investigate BEFORE designing anything.
Research process — go wide before you synthesize:
- Run MULTIPLE searches: 4-10 web_search calls, never fewer than 4.
One search is not research — it bets everything on your first
phrasing. Stop only when new queries stop surfacing new
information, even if that takes more than 10.
- Vary the queries: split the ask into concrete sub-questions
(specific beats broad) and hit the important ones from several
angles — different terms, different source types.
- Pull a LOT of data: web_fetch many results, not just a top hit.
Favor the primary sources behind the hits (the paper, the filing,
the announcement, the docs — not a blog's summary of them) and
extract specifics: numbers, dates, names, direct quotes.
- Cross-check every load-bearing figure across independent sources.
When sources disagree, report the disagreement — don't average it
away or pick silently.
- Keep the trail: note which source said what as you go, with URLs.
Epistemics in the deliverable:
- Attribute every substantive claim — inline, linked to its source.
- Date what you cite ("as of the 2024 filing…"); stale numbers
presented as current are worse than no numbers.
- Separate what sources establish from what you infer, and say which
is which. If the evidence is thin or conflicting, the report says
so — a confident-sounding gap is the one failure mode to avoid.
Deliverable (unless the user asks for another format): a designed,
single-file HTML research report — headline takeaways up top, then
findings with their evidence, and a linked source list at the end.
Design it like an editorial broadsheet: strong typographic hierarchy,
pull quotes for key numbers, charts only where the data earns them.Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report.
Author or improve the run-<unit> skill - a per-project skill that tells agents how to build, launch, and drive this project's app. Use when the user asks to set up the project, get it running, write run instructions, or verify build/run steps work from a clean environment.
Runtime capabilities a published Artifact page can be granted — behavior static HTML cannot provide on its own, such as the page reading live or connected data, remembering what people do on it (a poll, a sign-up sheet, a checklist, a document edited in place — it saves new versions of itself), keeping state shared across viewers, knowing who is viewing, asking Claude a question of its own, storing files people add, or handing the viewer a file to save. Serves this user's live capability roster and the typed call definitions. Load it whenever the user asks for an artifact needing any such runtime behavior.
Design guidance and fundamentals for Artifacts.
Diagramming know-how for Artifacts - when a picture earns its place, how to draw one that shows the real mechanism, and the inline-SVG mechanics that keep it legible in both themes.
Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
Automates your Chrome browser to interact with web pages - clicking elements, filling forms, capturing screenshots, reading console logs, and navigating sites. Opens pages in new tabs within your existing Chrome session. Requires site-level permissions before executing (configured in the extension).
Review the current diff, or a PR number/branch/path target, for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings; ultra: deep multi-agent review in the cloud); with no level given, it reuses the level you typed last. Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review. For ultra on a GitHub.com PR target, --post asks to post the finished review’s findings to the PR as a single comment from the user’s GitHub account (not a review; the launch dialog still confirms in interactive sessions, while non-interactive mode posts on the flag alone) and --no-post hides that option.