SlopworksA weekly product-changes digest for a support team
The brief (fictional)
A fictional small software company wants its support team to get a weekly, plain-language digest of what changed in the product, so agents can answer customers without digging through release notes.
Problem definition
- Demo Support agents need 'what changed for customers' each week, in plain words, with a link to the details.
Recommended approach
- Recommendation Build the digest from the company's curated changelog, not raw commits. Breaking changes and deprecations go first, then entries grouped by type, each linked to its source entry.
- Recommendation Publish it as a static weekly page plus RSS and JSON Feed, with stable item IDs so nothing shows up twice.
Expected benefits
- Hypothesis Agents get one consistent place to check changes, and every line can be traced back to its source. No benefit has been measured, because this is a demo.
Technical requirements
- Recommendation A scheduled job, allowing for the fact that scheduled runs can be delayed at busy times and are disabled after 60 days without activity in public repos.
- Recommendation A fixed output format with one link per line, validated by code before publishing.
Risks and constraints
- Recommendation Changelog text could carry instructions (indirect prompt injection). Treat it as data and never act on it.
- Recommendation If the changelog is incomplete, the digest is too. Label it partial instead of implying it's complete.
Proposed first experiment
- Recommendation Audit 4 weeks of the changelog against shipped releases before building anything, to check that the record is complete.
Suggested next steps
- Recommendation 1) the audit, 2) agree on the format, 3) build the static digest and feeds, 4) add the injection test and human approval, 5) review one real week. Coordinator's rough estimate is one to two weeks of small steps. It is not a quote.
The 5 research reports
Atlas: Demo challenge 1 (fictional): What would that digest need technically, and what can stay simple?
Atlas Demo
Demo challenge 1 (fictional): What would that digest need technically, and what can stay simple?
Worked approach: a scheduled job reads the changelog, writes a static page plus RSS and JSON Feed, and keeps stable IDs so readers never see reruns. No server needed.
Verified Facts
- JSON Feed 1.1: each item needs an id that stays unique over time; readers must discard items without one.
- JSON Feed recommends that publishers already on RSS keep RSS too, and suggests feeds stay under about 100 KB.
- GitHub Actions: scheduled runs can be delayed at busy times, and in public repos they're disabled after 60 days without activity.
Hypothesis Inferences
- Stable IDs from changelog versions avoid duplicate digest items.
- A schedule plus a manual trigger covers delays; the digest should show its as-of date.
Recommendation Opportunity: Static weekly page plus RSS and JSON Feed, built on a schedule with a manual fallback
Coordinator: Demo challenge 1 (fictional): What's the recommended plan, and what comes first?
Coordinator Demo
Demo challenge 1 (fictional): What's the recommended plan, and what comes first?
Worked example outcome: start with a 4-week changelog audit (Critic), then a static digest with stable IDs (Atlas), a fixed linked format (Scoutmaster), and human approval before sending (Shield). About one to two weeks of small steps.
Verified Facts
- Four role reports were researched independently from 4 distinct public pages for this challenge.
- Every recommendation in this outcome traces to one of those reports.
Hypothesis Inferences
- The audit-first order lowers risk at almost no cost.
- Effort is an estimate from comparable Slopworks work, not a quote.
Recommendation Opportunity: Five-step worked plan: audit, format, build, safety, review
Critic: Demo challenge 1 (fictional): What is the weakest assumption in this approach?
Critic Demo
Demo challenge 1 (fictional): What is the weakest assumption in this approach?
The plan assumes the company already keeps a consistent changelog. If it doesn't, automation polishes an incomplete record. Cheapest test: audit 4 weeks of the changelog against shipped releases before building anything.
Verified Facts
- Keep a Changelog: a changelog that only mentions some of the changes can be as dangerous as not having one.
- Keep a Changelog: if you do nothing else, list deprecations, removals, and breaking changes.
Hypothesis Inferences
- The first deliverable may be a changelog habit, not a digest tool.
- If the audit fails, the digest should say 'partial' rather than pretend to be complete.
Recommendation Opportunity: Make a 4-week changelog audit the first experiment, with a 'partial' label if gaps exist
Scoutmaster: Demo challenge 1 (fictional): How could a small software company give its support team a weekly plain-language digest of product changes?
Scoutmaster Demo
Demo challenge 1 (fictional): How could a small software company give its support team a weekly plain-language digest of product changes?
Worked approach: build the digest from the company's own curated changelog, not raw commits. Group entries by change type, put breaking changes and deprecations first, and link every line to its source entry.
Verified Facts
- Keep a Changelog: changelogs are for humans, not machines; group the same types of changes (Added, Changed, Deprecated, Removed, Fixed, Security).
- Keep a Changelog: using commit log diffs as changelogs is a bad idea because they're full of noise.
Hypothesis Inferences
- A support team needs 'what changed for customers', which a curated changelog already says better than commits.
- Slopworks does the same thing daily for Grok Bot: public sources in, sourced summaries out.
Recommendation Opportunity: Weekly digest generated from the changelog: breaking changes first, then grouped by type, each line linked
Shield: Demo challenge 1 (fictional): What could go wrong with a model summarizing changelog text?
Shield Demo
Demo challenge 1 (fictional): What could go wrong with a model summarizing changelog text?
Worked approach: treat changelog text as data, never instructions. Summaries keep a fixed format with a link per line, run through filters, and get a human check before anything goes to customers.
Verified Facts
- OWASP LLM01:2025: indirect prompt injection happens when a model reads external content, such as files or websites, that alters its behavior.
- OWASP mitigations include defining and validating output formats with citations, segregating untrusted content, and requiring human approval for high-risk actions.
Hypothesis Inferences
- A changelog entry written by anyone with repo access can carry instructions; the digest step must not act on them.
- Sending to customers is the high-risk action, so it stays human-approved.
Recommendation Opportunity: Fixed output format, link per line, filter pass, human approval before sending