Agent stack build plans · № 3 · part 5

The prompts

Five stages, pasted into Hermes in order. Replace the [bracketed] bits; don’t skip stage 2 — an intern that can’t prove it checked the archive will happily re-report Tuesday.

Stages 1–3 run in a normal interactive session, over a few days. Stage 4 only happens once the hand-runs bore you — boredom is the signal the loop works. Stage 5 puts human eyes on the output before the cron runs without you.

You are my research intern for one beat: [YOUR BEAT — e.g. "the solid-state battery industry"].

Your output is a morning report in markdown, saved to ~/research-intern/reports/YYYY-MM-DD.md, with exactly these sections: "New since yesterday" (each item one or two sentences, every item with a source link), "Steady state" (expected events, confirmations, nothing-happened notes), "Seen before, skipped" (a one-line count of deduplicated items, with one or two examples), and "Housekeeping" (sources checked, scraper skills used, number of Portal tool calls this run, and a source-check line confirming every scraper returned data).

Standing rules:
- Hard cap: at most [25] web_search/web_extract/x_search calls per run. If you hit the cap, say so in Housekeeping and stop searching rather than thinning quality silently.
- Respect paywalls, robots.txt, rate limits, and site terms of service. Never work around access controls. If a paywalled outlet reports something important, cite the headline and say "no access" — I'll decide whether to subscribe.
- Prefer primary sources (filings, papers, official data) over aggregators.
- Nothing goes in the report without a source link.

Save this entire briefing as a skill named research-intern (category: research) using skill_manage, so /research-intern runs it in any future session. Ask for my approval on the skill write. Then add one line to MEMORY.md noting the beat and the reports directory — keep it to one line; MEMORY.md is small and I want the rest of it free.

Run /research-intern now, with one extra requirement for this shakedown run: before writing the report, show me your dedupe pass explicitly. That means (a) the session_search queries you ran against past conversations, and (b) the grep you ran over ~/research-intern/reports/, and (c) which candidate items you dropped as already-covered and why. The archive is empty today, so everything will be new — I'm checking the mechanism, not the result. From tomorrow, do this pass silently and surface only the "Seen before, skipped" line.

New standing rule, and add it to the research-intern skill: when a source in our beat resists web_extract — a PDF report, a CSV download, a JavaScript-heavy or badly structured page, an API with rate limits — do not give up on it and do not hammer it. Instead, propose a scraper skill: create ~/.hermes/skills/scrapers/[source-name]/ with a SKILL.md and a scripts/ directory, where the script fetches and parses that one source politely (identify yourself, honor robots.txt and rate limits, back off on errors). Walk me through the script before you save it — I expect skills.write_approval to prompt me.

Two hard rules: never write a scraper for a source that is paywalled or forbids automated access, and every scraper script must end by printing a source-check line ("rows: N" or "pages: N") so the morning report can prove the scraper still works. When a scraper starts returning empty, flag it in Housekeeping as broken — a silent zero is worse than an error.

Create a cron job with the cronjob tool: every weekday at 07:15 local time, run /research-intern and deliver the finished report to me on Telegram. The job's instruction should invoke the skill, not restate the briefing — the skill is the single source of truth. Confirm the job exists and show me what "hermes cron list" reports. One more standing rule for scheduled runs: if a run errors, or hits the Portal call cap, or any scraper returns empty, the Telegram message must lead with that instead of burying it — an intern that fails loudly gets fixed; one that fails quietly gets a month of my trust it doesn't deserve.

Before this cron earns unattended mornings, I want people who know the beat to judge a real report.

Connect the twocents MCP server at https://twocents.page/mcp (Hermes can connect to any MCP server; restart the session so the tools load). Render today's report as a self-contained sample-report.html — clean, readable, sources as links — then call share_page with its full contents and give me the review link. I'll send it to two or three people who follow [YOUR BEAT]. They pin notes directly on the page, no login: wrong emphasis, missed source, a section that reads as padding.

When I say the notes are in, call get_feedback with the room id, show me each note, and apply the ones I approve — to the research-intern skill and the briefing, not just to this one report. The point is that tomorrow's report is better, not that today's gets patched.

Why the feedback stage is load-bearing

You are about to stop reading this report critically — that’s the whole point of automating it, and it’s also the risk. Whether the emphasis is right, whether a section is quietly padding, whether the intern is over-indexed on X chatter — someone who follows the beat sees that in ninety seconds, and after week two, you won’t. Stage 5 wires Hermes to our MCP server so that judgment lands as pinned notes on the actual artifact, and gets folded into the skill that generates every future report. It’s the same loop that reviewed this page.