Specialists
Researching on the web
Cited research that reads pages properly, escalating to a real browser when a page needs one.
/research how does Stripe handle idempotency keys on retries
/research --deep migrating from Redis pub/sub to streams
/research --browser pricing on the competitor's siteWhat you get back
A written answer with its sources, saved to your project. Not a list of links — the pages are read, and the claims point at where they came from.
Because it's saved, "what did we find out about idempotency keys" works months later, and a teammate in the same workspace can ask it too.
The flags
| Flag | Effect |
|---|---|
--quick | A few sources, fast. For settling a specific question. |
--deep | Wide sweep, more sources, longer. For "I need to understand this area." |
--browser | Drives a real browser, for pages that need JavaScript or a login wall. |
--pro | Higher-capability models throughout. |
Without a flag it picks a depth from the question.
When it beats reading the docs yourself
- The answer is spread over several pages and you want it in one.
- The official documentation is wrong or out of date and you need the issue thread that says so.
- You want the answer recorded against the project rather than in a browser tab you'll close.
When it doesn't
Anything about your code. Use Searching your project — the answer is in the repository or in your own history, and the internet doesn't have it.
Cost
Deep research reads a lot of pages, and each is model input. --quick is
usually the right default. /usage shows what a session spent.
If it doesn't work
A page came back empty. It needed JavaScript. Rerun with --browser.
The sources are thin. The question was too broad. Narrow it — a specific version, a specific error, a specific product.
It's taking a long time. --deep is minutes. Run it in the background and
carry on with something else.