Build your own morning briefing

Staying current is a job you never applied for. New releases, breaking changes, framework drama, and the one comment thread where someone who ran it in production tells you what really happened. All of it is out there every morning, scattered across dozens of tabs you don't have time to open.

So don't open them. Here we build a morning briefing agent: a scheduled job that reads the dev landscape overnight through the daily.dev API and gives you a short brief before your first coffee. Instead of a list of links you get a proper briefing, with a verdict on what deserves your time and why.

It builds on the setup and terminal CLI pages.

What goes into a good briefing

A useful morning brief answers three questions:

What happened that affects my stack? Personalized signal, not general news.
What is the community talking about? The discussions, not only the headlines.
What can I skip? The hardest question, and the most valuable one.

The daily.dev API has an endpoint for each:

Question	Endpoint	Why it works
What affects me?	`GET /feeds/foryou`	Ranked by your tags, sources, and reading history
What's the debate?	`GET /feeds/discussed?period=1`	Sorted by comment activity in the last day
What's the nuance?	`GET /posts/{id}/comments`	Real practitioners disagreeing in public

The third row is what makes this work. Headlines tell you what shipped. Comment threads tell you whether it survives contact with production. A briefing built on web search has no access to that.

Step 1: Gather the raw material

No new tooling needed. The CLI already covers all three questions, and --json on each command gives you the raw API response to hand to a model:

mkdir -p input
pnpm dailydev feed -n 15 --json > input/foryou.json
pnpm dailydev discussed -n 10 --json > input/discussed.json
pnpm dailydev comments <post-id> --json > input/thread.json

The first two are one call each. The third takes a post id, so run it for the two or three discussions that deserve the tokens, meaning the ones with the highest numComments in discussed.json. Picking those ids is a job for your agent, which already knows how to run the CLI.

Request budget: 4 or 5 calls per run. Once a day, that barely touches the free tier.

One decision before you feed the threads in. --json gives you comments exactly as the API returns them: HTML, permalinks, award counts, nested children and all. If you send several threads at once, trimming each comment down to its text, upvotes, and author keeps your context window small.

Step 2: The briefing prompt

This is where raw JSON turns into a brief. Feed the files in input/ to your LLM of choice with a prompt like this one. It is the editorial policy of your briefing, so change it until it fits you:

You are my morning dev briefing editor. Input: JSON with my personalized
daily.dev feed (foryou), the most-discussed posts of the last 24h
(discussed), and comment threads for the hottest discussions (threads).

Write a briefing I can read in under 4 minutes:

1. TOP STORY: the single most consequential item for someone with my
   interests (infer them from the foryou tags). Two sentences on what
   happened and one on why I should care.

2. WORTH YOUR TIME: 3-4 more items. One line each: what it is + the
   engagement signal (upvotes/comments) as evidence.

3. THE DEBATE: pick the most interesting comment thread. Summarize the
   disagreement in 2-3 sentences. Quote the single sharpest comment.

4. SAFE TO SKIP: 2-3 things that look big but aren't (hype with weak
   engagement, rehashes, vendor noise). One dismissive line each.

Rules: every claim links to its post URL. Use upvotes/comments to weight
credibility. Don't editorialize beyond what the data supports. If
nothing qualifies for a section, say so instead of padding.

The "SAFE TO SKIP" section only works because of the engagement data. A post with breathless framing and 4 upvotes is a very different thing from one with 340 upvotes and a 60-comment thread, and your agent can see the difference.

Step 3: Schedule it

With Claude Code (or any agentic CLI) and cron, gather first, then let the agent write the brief:

# crontab -e, weekdays at 7:00
0 7 * * 1-5 cd ~/dailydev-cli && \
  pnpm dailydev feed -n 15 --json > input/foryou.json && \
  pnpm dailydev discussed -n 10 --json > input/discussed.json && \
  claude -p "Read input/*.json and write my morning briefing per briefing-prompt.md. For the hottest discussions, pull the threads yourself with 'pnpm dailydev comments <id> --json'. Save it to briefs/$(date +\%F).md" >> cron.log 2>&1

If you'd rather not depend on your laptop being awake, the same two steps run in any scheduled runner: GitHub Actions or GitLab CI on a schedule trigger, a systemd timer or launchd job, a Fly.io or Railway cron process, or Cloudflare Workers cron triggers. All they need is your DAILY_DEV_TOKEN as a secret plus whatever credentials your model uses.

Delivery is up to you:

commit the brief to a repo
post it to a Slack or Discord webhook
email it through whatever provider you already use
leave it in a file your shell prints when you open a terminal

What a run looks like

☀️ Briefing for Tuesday, Sep 9

TOP STORY: Postgres 18 shipped with async I/O on by default. If you run Postgres under heavy read loads this is the most meaningful default change in years; early comments report 15 to 30% throughput gains on NVMe.

WORTH YOUR TIME

TypeScript 6.0 beta breaks decorator metadata, and the migration thread is already at 💬41

...

THE DEBATE: "We migrated off Kubernetes" (▲198, 💬63). The thread splits between "you never needed it" and platform engineers pointing out the team replaced k8s with... a homegrown k8s. Sharpest take: "You didn't leave Kubernetes, you left your understanding of it."

SAFE TO SKIP: The "AI will replace SREs" post doing the rounds. 6 upvotes, zero comments from anyone operating at scale.

How much you get

A briefing costs four or five requests a run. That is small, except it runs every morning, and on a free account that adds up to most of what you can spend in a month.

Plus comes with much higher rate limits, so the briefing stops competing with everything else you build.

What's next

Your briefing tells you what to read. Next comes what you meant to read: giving your saved posts the structure a flat list can't, with folders that live on your own machine.

Next: Organize your daily.dev bookmarks: a local store, a multi-verb command, and a reading list with some shape to it.

Previous: Read daily.dev from your terminal
API reference: api.daily.dev/public/v1/docs/json
Example repo: github.com/dailydotdev/dd-cli-example