Newsletter

Drafts a weekly newsletter from the week's merged Changes, Releases and blog posts, and queues it for human approval. It never sends.

Name	newsletter
Category	Scheduled
Enabled by default	Yes
Budget	up to $2.00 per run, 30 turns
Catalog	v0.2.0
Used in	Release

What it does

Subscribers get a short, accurate weekly account of what changed in the Product and why it matters to them. The newsletter role is accountable for a draft that is correct against the source, readable in two minutes, and ready for a human to approve and send.

Step by step:

1. Collect everything since the last issue: Releases published, merged Changes with user-visible effect, blog posts, and docs pages added.
2. Drop internal-only Changes (refactors, CI, dependency bumps without user effect) unless they fix something users noticed.
3. Group items into sections: new in this Release, improvements, fixes, from the blog, and what is coming next if the roadmap is public.
4. Write each item as one or two sentences about the user's benefit, with a link to the Release notes, docs page or post.
5. Check every version number, date and claim against its source, and every link for a 200 response.
6. Write a subject line under 60 characters and a preview line under 100.
7. Save the draft to the newsletter drafts folder and open a pull request or queue entry for approval, tagging the marketing team.
8. Finish with exactly one verdict: DRAFTED (a draft awaits approval) or SKIPPED (nothing user-visible happened this week, stated with the list of what was reviewed).

When it runs

• On a schedule, 0 14 * * 4. Every Thursday at 14:00 UTC.

What it reads

Source	What it uses it for
release-notes	Release notes for every Release published since the last issue.
repo	Merged pull requests and their linked issues since the last issue.
blog	Blog posts published since the last issue.
product-docs	External product docs, for accurate links.
previous-report	The last newsletter, so items are not repeated.

What it produces

• A newsletter draft with subject, preview line and sections, in the drafts folder.
• A pull request or approval queue entry assigned to the marketing team.

How it proves it

Every run attaches this evidence to its AgentWorkflowRun step.

Evidence	What it shows	Required
Document	The newsletter draft as it would be sent.	Yes
Report	Source check listing each item, its source link and link status.	Yes

Success criteria

A run succeeds only when every statement holds.

• A draft exists for every week with user-visible changes.
• Every item links to a source, and every link returns a 200 response.
• Every version number and date matches its Release.
• No item repeats one from the previous issue.
• The draft reads in under two minutes (about 400 words).
• Nothing is sent without a recorded human approval.

Guardrails

• Never send, schedule or publish the newsletter. A human sends it.
• Never include unreleased features, security incidents under embargo, or customer names without permission.
• Never import or email subscriber lists.
• Never invent metrics, quotes or testimonials.
• Never merge the draft pull request.

Permissions

Deny wins over allow.

Tools allowed	Read, Grep, Glob, Write, Edit, WebFetch, Bash(git checkout -b:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*), Bash(gh pr create:*), Bash(gh release list:*), Bash(gh release view:*), Bash(gh pr list:*)
Tools denied	Bash(git push --force:*), Bash(gh pr merge:*), Bash(curl -X POST:*), Bash(kubectl:*)
Git scopes	contents:read, contents:write, pull_requests:write
Cluster verbs	None
Network	allowlist
Egress allowlist	api.github.com, github.com
May merge its own pull requests	No

When it hands off to a human

It dead-letters the work to @platform/marketing if it has not finished after 1h, or as soon as any of these is true:

• A week's items include a security fix whose advisory is not yet public.
• Sources disagree about what a Release contains.
• The draft has not been approved within 3 days.

Verdicts

Every run ends with exactly one of these verdicts:

• DRAFTED
• SKIPPED

Opinions

Opinions are the org’s editable guidance for this role. Each one can be edited or switched off in the Infrared UI; an edited opinion is marked as the org’s own.

Length and structure

length · origin catalog

About 400 words, at most five sections, at most four items per section. Lead with the single most useful change of the week.

Voice

voice · origin catalog

Plain, specific and active. Say what the reader can now do. No emoji, no exclamation marks, no superlatives.

What is newsworthy

what-counts · origin catalog

User-visible features, fixes users reported, performance improvements of 10 percent or more, and breaking changes with a migration path. Internal work only when it explains a visible change.

Approval

approval · origin catalog

Every issue needs one approval from the marketing team before sending. The approver owns the send.