Point your agent at daily.dev instead of web search

When your coding agent needs current information, it reaches for web search. Web search hands it whatever won the SEO game that week: content-farm listicles, decade-old Stack Overflow answers rehashed by bots, vendor blogs disguised as neutral comparisons. Your agent can't tell the difference. It wasn't there when the community read these things and voted.

daily.dev was. Every article on the platform has been read, upvoted, and argued about by developers. That engagement layer, which articles practitioners found useful, is the signal generic search doesn't have.

After the setup, CLI, briefing and bookmarks pages, we make daily.dev your agent's search engine. There is one skill to install, and then we go through how it searches.

Meet daily-dev-ask

daily-dev-ask is a ready-made agent skill. Think of it as web search backed by a senior dev's reading list instead of the open web. Ask a technical question and the agent searches daily.dev's article corpus in several rounds, weights results by community engagement, and returns a grounded answer with linked sources. There is never a claim without an article behind it.

Claude Code:

claude plugin marketplace add https://github.com/dailydotdev/daily.git
claude plugin install daily.dev@daily.dev

/daily-dev-ask should I use pgvector or a dedicated vector database?

Codex: run $skill-installer install the daily-dev-ask skill from https://github.com/dailydotdev/daily.git, restart, then $daily-dev-ask your question.

Cursor: add https://github.com/dailydotdev/daily.git as a Remote Rule, then /daily-dev-ask in Agent chat.

OpenClaw: tell your agent Install daily-dev-ask from clawhub (clawhub.ai/idoshamun/daily-dev).

You can read more about the skill at daily.dev/agents/ask.

What comes back looks like this:

Based on 9 articles from daily.dev: for most teams already on Postgres, pgvector is the right starting point. The operational simplicity outweighs raw ANN performance until you pass ~10M vectors [...]

Sources from daily.dev

1. pgvector in production: 18 months later, what breaks at scale (⬆️ 412 · 💬 57)
2. Vector DB benchmarks nobody paid for, independent comparison (⬆️ 289 · 💬 34)
3. ...

Look at what the engagement numbers are doing there. They are the answer's evidence trail. An article 400 developers upvoted and 57 argued about carries different weight than a vendor benchmark nobody read, and the skill uses that weighting explicitly.

How the skill searches

The interesting part of daily-dev-ask is the set of decisions about how to search. They apply whether you use the skill or build something like it yourself.

Questions arrive in two shapes, so the skill runs two kinds of query. "pgvector HNSW" is a keyword lookup: you already know the vocabulary and want articles containing it. "how do I make my chatbot remember previous conversations" is different, because nobody wrote an article with that title. That one needs matching on meaning. Running both and merging the results beats picking one and hoping.

It searches in rounds rather than once. A first pass turns up tools and terms you didn't know to ask about, so the skill searches again for those: the libraries mentioned in the results, the synonyms practitioners use, the sub-questions the first answers raised. It stops when new searches stop returning new articles, which is also when a person stops researching.

Upvotes and comments are the ranking signal. This is the part generic search can't copy. An article a few hundred developers upvoted has been read by people who would know if it were wrong, and a long comment thread means the nuance is available. Someone in there ran it in production and said what broke. Recency breaks ties, because ecosystem advice goes stale faster than most content.

Every claim carries its article. The answer cites what it's built on, so you can disagree with the source rather than with the model. The most important rule is the negative one: if the corpus doesn't cover part of your question, the skill says so instead of filling the gap from memory. A search tool your agent can't hallucinate around is worth more than a smarter model with a vague one.

Answers stay small on purpose. Results are capped, and each one carries a title, summary, tags, read time, and engagement numbers. That is enough to rank and cite, without burning your context window on payload you'll never read.

If you'd rather wire this into your own agent than use the skill, those five rules are the whole design. The endpoints behind them are in the API reference.

When to still use web search

daily.dev is a developer content network, not an index of the entire web. Official API docs, GitHub issues for a specific bug, non-technical topics: keep web search for those. The setup that works is both tools with a clear routing rule, something like "technical questions about tools, practices, and ecosystem trends go to daily.dev; everything else goes to web search." Agents follow that kind of instruction well.

How much you get

Answering one question properly can take ten or fifteen searches. A free account is enough to try this and see whether you like the answers. It isn't enough for an agent that looks something up every time it's unsure.

That's the case for Plus: much higher rate limits, which is the difference between rationing your agent's curiosity and forgetting there was a limit.

Everything together

Five pages, five working tools:

1. Setup and first query: token, auth, and handing the API to your agent
2. Terminal CLI: dailydev, a small reader both you and your agent can use
3. Morning briefing: a scheduled agent that reads the landscape overnight
4. Bookmarks: local folders for the posts you save
5. Search replacement: this page

The pattern across all five: daily.dev's community engagement data is what your agent is missing. Upvotes and comment threads tell you what practitioners value, and now they are one Bearer token away.

• API reference: api.daily.dev/public/v1/docs/json
• Agent skills: github.com/dailydotdev/daily
• About the skill: daily.dev/agents/ask