Daily News Digest Automation

SkillProductivity

Create an automation that reads a list of public RSS and Atom feeds on a schedule - daily by default - keeps what is new and matches the configured topics, and has an agent write a short digest of it. It needs no credentials: the feeds are public URLs and the conversation is started with no secrets and no MCP servers.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Daily News Digest Automation skill

What this skill tells your AI

The instructions your AI receives, as published by openhands/extensions in skills/news-digest/SKILL.md and read by ahel’s review.

Create a cron automation that turns a list of feeds into something worth reading: a few hundred words a day on what happened in the topics you care about, with a link under each item.

It connects to nothing. There is no token to issue, no account to link, no OAuth screen. That makes it the automation to run first - it exercises the schedule, the conversation, the model and the run log end to end while nothing of yours is at stake, and it is useful in its own right afterwards.

The script is deterministic: the schedule, the once-a-day claim, fetching, parsing, the freshness window, and remembering what has already been covered are all Python. The LLM is invoked only for the part that is judgement - reading the shortlist and writing something that is not just the headlines pasted back. When nothing new matches, no conversation is started at all, so a quiet day costs no tokens.


Prerequisites

None. That is the point.

The runtime needs outbound HTTPS to the feed hosts, which it already has if it can reach the model. Nothing is read from Settings -> Secrets, and nothing needs to be added there.


Setup Workflow

Follow these steps in order.

Step 1 - Collect the feeds

Ask: "Which feeds should the digest read? (One RSS or Atom URL per line. Press Enter for a general technology set.)"

Default:

https://news.ycombinator.com/rss
https://feeds.arstechnica.com/arstechnica/index
https://www.theverge.com/rss/index.xml

Check each one before accepting it, because a URL that returns a web page rather than a feed is the most common setup mistake:

curl -sSL --max-time 20 -A "OpenHands-News-Digest/1.0" "{feed_url}" \
  | python3 -c "
import sys
from xml.etree import ElementTree
try:
    root = ElementTree.fromstring(sys.stdin.buffer.read())
except ElementTree.ParseError as exc:
    print('ERROR: not valid XML:', exc); raise SystemExit
name = root.tag.rsplit('}', 1)[-1]
items = [e for e in root.iter() if e.tag.rsplit('}', 1)[-1] in ('item', 'entry')]
print(f'OK: <{name}> with {len(items)} entries' if name.lower() in ('rss', 'feed', 'rdf')
      else f'ERROR: root element is <{name}>, which is not a feed')
"

Record every accepted URL into FEEDS = ["...", ...]. A feed that fails at runtime is reported and skipped, so one bad URL does not cost you the digest - but it is better to find out now.

Step 2 - Collect the topics

Ask: "What should the digest be about? (One topic per line, or comma separated. Press Enter for artificial intelligence, open source, developer tools. Leave it blank to summarise everything the feeds carry.)"

Record as TOPICS. Two things are worth telling the user:

  • The agent decides which stories are about them, reading each headline and excerpt. So write topics the way you would explain your interests to a colleague - artificial intelligence works even though almost every headline says AI, and a story about a company releasing its model weights counts as open source without using the phrase.
  • An empty list means "cover whatever is most significant". That is right for a handful of narrow feeds and vaguer for a firehose.

Step 3 - Collect the schedule

Ask: "When should the digest be written? (Press Enter for the default: every day at 08:00 UTC, 0 8 * * *.)"

Default: 0 8 * * *. Record as CRON_SCHEDULE, and the timezone as CRON_TIMEZONE (default UTC).

A schedule more frequent than daily is allowed and is not wasteful: work is keyed by UTC date, so extra runs stop at a state read once the day is done, and before that they cost one HTTP request per feed and no tokens. It is a reasonable way to say "write the digest as soon as there is anything to write".

Step 4 - Confirm the secret scope

Do not ask which secrets to forward. AGENT_SECRET_NAMES is empty and should stay empty: the conversation summarises text fetched from the open web, which is written by strangers, and a credential handed to it would make every feed on the list an instruction channel into the deployment's secret store.

If the user asks for a digest posted to Slack, Notion or a repository, that is a different automation - it needs that integration connected, and it should be built from the skill for it rather than by widening this one.

Step 5 - Generate the automation script

Read scripts/main.py from this skill's directory. Apply exactly two constant substitutions near the top of the file:

The script also reads a config.json shipped beside it, if there is one, over these constants. That is how the catalog entry (automations/catalog/news-digest/) configures an unmodified copy, since a declarative host cannot rewrite Python. This setup path substitutes the constants and ships no config.json, so the two never collide.

PlaceholderReplace with
FEEDS = [...]the list from Step 1
TOPICS = [...]the list from Step 2, or [] for no filter

LOOKBACK_HOURS (48) and MAX_ITEMS (50) are left alone unless the user asks. The lookback is deliberately wider than the schedule so a failed or missed run is recovered by the next one; the seen-list is what stops the overlap from repeating anything.

Use a safe string writer such as json.dumps(value) when inserting user-provided URLs or topics into Python string literals.

Write the customized script to a temporary build directory and validate it:

mkdir -p /tmp/news-digest-build
# write the customized main.py to /tmp/news-digest-build/main.py
python3 -m py_compile /tmp/news-digest-build/main.py && echo "Syntax OK"

Step 6 - Package and upload

Determine the Automation backend URL and auth from the <RUNTIME_SERVICES> block in your system context:

  • OPENHANDS_HOST: the Automation backend url_from_agent
  • Auth: X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY
tar -czf /tmp/news-digest.tar.gz -C /tmp/news-digest-build .

TARBALL_PATH=$(curl -s -X POST \
  "${OPENHANDS_HOST}/api/automation/v1/uploads?name=news-digest" \
  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY" \
  -H "Content-Type: application/gzip" \
  --data-binary @/tmp/news-digest.tar.gz \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['tarball_path'])")

echo "Uploaded: $TARBALL_PATH"

Step 7 - Register the automation

curl -s -X POST "${OPENHANDS_HOST}/api/automation/v1" \
  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"name\": \"Daily news digest\",
    \"trigger\": {\"type\": \"cron\", \"schedule\": \"{cron_schedule}\", \"timezone\": \"{cron_timezone}\"},
    \"tarball_path\": \"$TARBALL_PATH\",
    \"entrypoint\": \"python3 main.py\",
    \"timeout\": 900
  }" | python3 -m json.tool

Record the returned id.

Step 8 - Confirm

Tell the user:

Daily news digest is running!

  • Automation ID: {id}
  • Feeds: {url}, ... (one line each)
  • Topics: {topics} (or: no filter - everything the feeds carry)
  • Schedule: {cron_schedule} ({cron_timezone})
  • Credentials used: none
  • State file: ~/.openhands/workspaces/automation-state/news_digest_{id}.json

Each day it reads the feeds and writes the digest into the run's conversation and the run log. A day with nothing new produces nothing and costs nothing - the day stays open, so a later run picks up news published after this one.

Then offer to dispatch it once so they can read today's digest immediately:

curl -s -X POST "${OPENHANDS_HOST}/api/automation/v1/{id}/dispatch" \
  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY"

Runtime Behaviour (per run)

Each cron run executes main.py, which loads config.json if the catalog shipped one and then:

  1. Loads state (the automation service's KV store, or a local JSON file when the store is unavailable).
  2. Computes today's UTC date and stops immediately if it is already recorded - no feed is fetched, so an extra run inside a finished day costs one state read.
  3. Otherwise fetches every feed with a 20-second timeout and a 4 MB cap, and parses RSS 2.0, RSS 1.0/RDF and Atom by local element name. A feed that fails, is not XML, or is XML that is not a feed is recorded and skipped. The run fails only if every feed fails.
  4. Selects the stories: not already covered, and published within LOOKBACK_HOURS (undated stories are treated as current rather than dropped). The newest MAX_ITEMS survive. Subject is deliberately not a filter here.
  5. If none survive, records the check, says which stage emptied it, and leaves the day unclaimed so a later run can try again. No conversation, no tokens.
  6. Otherwise claims the day in state before the slow work, so an overlapping run cannot write the digest twice, then starts an OpenHands conversation with the stories and the topics in its prompt, an empty secrets payload and no MCP servers, working in {WORKSPACE_BASE}/news-digest/{date}. The agent decides which stories are relevant before it writes anything.
  7. When the conversation reaches idle, finished, error or stuck:
    • reads digest.md from the working directory, falling back to the agent's final message;
    • prints the digest into the run log and keeps its opening in state;
    • records the stories as covered only now, so a run that failed leaves them for the next one;
    • removes the working directory once the conversation is confirmed stopped.
  8. Prunes the task history to the last 14 days and the seen-list to 1000 fingerprints, both so the state document stays inside the KV store's 64 KB value limit.

How a story is recognised again

Two fingerprints per story: one over the feed's own identifier (guid/id), one over its link with the host lowercased, the fragment removed and campaign parameters stripped. A story counts as already covered if either matches. Both are needed - a feed whose links carry a per-fetch campaign tag is only recognisable by its identifier, and two publishers syndicating the same article agree on nothing but the link.


Additional Resources

  • references/state-schema.md - State JSON schema and the task lifecycle.
  • scripts/main.py - The complete automation script.

Troubleshooting

SymptomLikely causeFix
Every run says "Nothing new to digest"Nothing was published, or it was all covered alreadyThe run log now names which of the two it was; the digest covers what the topics miss only if the feeds carry it at all
The digest ignores a topic you care aboutThe feeds do not carry stories about itAdd a feed that does; the agent can only choose from what was fetched
A feed reports "not a feed"The URL serves a web page, not the feedFind the real feed URL - it is usually linked from the page as application/rss+xml
A feed reports an HTTP 403The host blocks unknown readersUse a different feed for that source; this automation sends no credentials by design
The digest is thin and full of "Headlines"Those feeds carry titles onlyExpected for Hacker News and similar; add a feed that publishes summaries, such as Ars Technica
Nothing happens after a manual dispatchToday is already recorded in stateRead the previous run's log for the digest, or clear today's entry from the state document
A day was missed entirelyThe run failed, or the service was downThe next run covers it: the lookback window is 48 hours and failed runs deliberately remember nothing
Digest repeats a storyTwo feeds identify the same article differently, and neither the guid nor the canonical link matchedExpected occasionally; the prompt asks the agent to merge duplicate coverage it can see

Signals

GitHub stars
143
Forks
83
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
news-digest
Source
github.com/openhands/extensions