For an agent. From https://sessions.bensbites.com/newsletter-pipeline/. The prompts are Ben's, as he typed them. Anything marked "Ben:" is his setup; use the person's own tools where they differ.
Saved links become a draft in the person's newsletter tool on the morning of each send, picked and sorted the way their past issues were. The person edits the draft. The pipeline never publishes or sends.
Does: every saved link lands in a table, with the text behind it: the linked page's title and first text, the quoted post, the post it replied to.
No prompt: Ben already had this. Keep every save. Never delete.
Does: tells the picker when, what, and what good looks like.
Sections are exactly:
intro: the theme or cluster of the window, Ben's own work, or his own take.
feed: tools, blog posts, videos, podcasts, workflows, tips, skills, use cases, big model news, new lab features.
afters: people's takes, opinions, memes, funny/satire, visually interesting AI demos.
not_used: not selected, including personal-interest saves: things to build, visual interactions to copy, inspiration, business, watching how developers work.
Ben's prompt for the sections:
which section does it go in?
- is it intro worthy. these are generally topics that showed up as a cluster or theme, sometimes its just stuff im working on and building, or my take on something.
- is it 'feed' - name is potentially changing. essentially tools that look interesting, blog posts, videos, podcasts, workflows, tips, skills, use cases, big model news, new features from labs etc.
- afters. people's takes. opinions, meme's, funny/satire and visually interesting ai demos.
i do often save some things which are just for my personal interest - maybe something to try building, a visual interaction i'd like to copy or try out. sometimes inspiration / business stuff.
Does: one call to a large model with every save in the window, the sections, and two past issues as examples. For each save: a section or "not used", one line on why, and a one-line draft with its source link for the picks.
Setup: Ben: Mon and Wed 19:00 a preview, Tue and Thu 06:00 the draft.
How Ben got here: a small model scoring one save at a time got about half of his picks, and more context per save did not help. A bake-off on the past issues: one large model reading the whole week with two past issues as examples beat every per-save setup and was the simplest. Test the choice the same way.
Ben's prompt:
and should we look at something other than jev (jev is multimodal btw), or alongside it like an open source model - glm 5.3 flash? other?
you must understand exactly what i'm trying to do here and the kind of system i want. how do we get it. simplest setup possible but super efficient and accurate. it can improve over time still.
Does: one page with every save in the window, its section and reason. The person can change the section, add a note, and see a history. Every change is a new row in an edits table. Nothing is deleted. Undo is a new row.
Views Ben had made: List (grouped by section), Board (a column per section), Triage (list plus a detail panel). Offer versions; let the person pick.
Ben's prompt:
my idea is to have a view in our site that lets me see what was categorised as what, probably a quick list view of all the items like linear, with the tags. /emil-prototype a few versions
Does: on the morning of each send, the schedule runs the pick again with the person's edits in, and creates one unpublished draft in the newsletter tool through its drafts API, signed in as the person. Placeholders in brackets for what the person writes ([Title], [Intro], [Sponsor], [Headlines]). One line per pick with its source link. If the stored draft was deleted, make a new one. Never touch a published or scheduled post.
After the send: compare what went out with what the pipeline picked and what the person edited. Write a suggested change to the picker's instructions or examples. A change only goes in if the person says yes and it passes the test on past issues.
Optional: a second model checks each draft line against its source and flags a line it can't back up. Ben uses Jev for this. The line stays; only the flag is added.
Ben's prompt for the build:
orchestrate gpt 6.1 sol high subagents to split this work up. do everything, verify it.
# My bookmarks write the first draft: build this For an agent. From https://sessions.bensbites.com/newsletter-pipeline/. The prompts are Ben's, as he typed them. Anything marked "Ben:" is his setup; use the person's own tools where they differ. ## Goal Saved links become a draft in the person's newsletter tool on the morning of each send, picked and sorted the way their past issues were. The person edits the draft. The pipeline never publishes or sends. ## You need - Saved links landing somewhere on a schedule, with the text behind each link. Ben: X bookmarks, pulled by a local script every 15 minutes. Simpler: connect X to Executor or to a Grok Bot and have it do the same. - Past issues with their send dates. Ben: 78 issues of Ben's Bites, from the Substack archive. - A database. Ben: Supabase. - A model that can read a whole week of saves in one call. Ben: GPT-6.1 Sol through OpenRouter. - A newsletter tool with a drafts API. Ben: Substack. - Somewhere for a schedule to run. Ben: his Mac, with launchd. If it is off, nothing runs. ## Parts, in build order ### 1. Saves come in Does: every saved link lands in a table, with the text behind it: the linked page's title and first text, the quoted post, the post it replied to. No prompt: Ben already had this. Keep every save. Never delete. ### 2. The rules Does: tells the picker when, what, and what good looks like. - When: each issue takes every save since the last send. Ben: Tuesday's issue = everything since Thursday's send. Read the last send time from the archive. No overlap. - What: the sections, in the person's words. Put them in the picker's instructions. Ben's, as the model gets them: ``` Sections are exactly: intro: the theme or cluster of the window, Ben's own work, or his own take. feed: tools, blog posts, videos, podcasts, workflows, tips, skills, use cases, big model news, new lab features. afters: people's takes, opinions, memes, funny/satire, visually interesting AI demos. not_used: not selected, including personal-interest saves: things to build, visual interactions to copy, inspiration, business, watching how developers work. ``` - What good looks like: for each past issue, match the saves in its window against what ran, and in which section. A save counts as used if the same story ran through a different link. This is the test for every model choice: give it an old week's saves, count how many of the stories that ran it picks. Ben's prompt for the sections: > which section does it go in? > - is it intro worthy. these are generally topics that showed up as a cluster or theme, sometimes its just stuff im working on and building, or my take on something. > - is it 'feed' - name is potentially changing. essentially tools that look interesting, blog posts, videos, podcasts, workflows, tips, skills, use cases, big model news, new features from labs etc. > - afters. people's takes. opinions, meme's, funny/satire and visually interesting ai demos. > > i do often save some things which are just for my personal interest - maybe something to try building, a visual interaction i'd like to copy or try out. sometimes inspiration / business stuff. ### 3. The weekly pick Does: one call to a large model with every save in the window, the sections, and two past issues as examples. For each save: a section or "not used", one line on why, and a one-line draft with its source link for the picks. Setup: Ben: Mon and Wed 19:00 a preview, Tue and Thu 06:00 the draft. How Ben got here: a small model scoring one save at a time got about half of his picks, and more context per save did not help. A bake-off on the past issues: one large model reading the whole week with two past issues as examples beat every per-save setup and was the simplest. Test the choice the same way. Ben's prompt: > and should we look at something other than jev (jev is multimodal btw), or alongside it like an open source model - glm 5.3 flash? other? > > you must understand exactly what i'm trying to do here and the kind of system i want. how do we get it. simplest setup possible but super efficient and accurate. it can improve over time still. ### 4. The review page Does: one page with every save in the window, its section and reason. The person can change the section, add a note, and see a history. Every change is a new row in an edits table. Nothing is deleted. Undo is a new row. Views Ben had made: List (grouped by section), Board (a column per section), Triage (list plus a detail panel). Offer versions; let the person pick. Ben's prompt: > my idea is to have a view in our site that lets me see what was categorised as what, probably a quick list view of all the items like linear, with the tags. /emil-prototype a few versions ### 5. The draft, and after the send Does: on the morning of each send, the schedule runs the pick again with the person's edits in, and creates one unpublished draft in the newsletter tool through its drafts API, signed in as the person. Placeholders in brackets for what the person writes ([Title], [Intro], [Sponsor], [Headlines]). One line per pick with its source link. If the stored draft was deleted, make a new one. Never touch a published or scheduled post. After the send: compare what went out with what the pipeline picked and what the person edited. Write a suggested change to the picker's instructions or examples. A change only goes in if the person says yes and it passes the test on past issues. Optional: a second model checks each draft line against its source and flags a line it can't back up. Ben uses Jev for this. The line stays; only the flag is added. Ben's prompt for the build: > orchestrate gpt 6.1 sol high subagents to split this work up. do everything, verify it. ## Rules Ben set - Never publish or send. Draft only. - Test on past issues first. Report how many of the stories that actually ran would have been picked. - Never delete an edit. Undo is a new line. - The loop suggests. The person says yes. - Simplest setup possible.