Automate one weekly task end to end: a worked example
Pick one recurring task, build it as a pipeline with two verification points, and measure the time it actually saves before trusting it.
The fastest way to find out whether agents actually help your team is to take one task you already do every week, build it as a small pipeline instead of a prompt, and run it for a month. Not a demo task — a real one with a real audience, so a bad output has a real cost and you're motivated to add the verification that catches it.
Pick a task with a clear definition of done
Good candidates are recurring, bounded, and checkable: weekly release notes from merged PRs, a dependency-update summary, an on-call handoff summary, a test-coverage report. Avoid tasks whose "done" is subjective — if you can't say in one sentence what a correct output looks like, you can't verify it, and an unverified weekly automation is just a weekly source of unreviewed output.
Design it as a pipeline, not a prompt
A pipeline has four parts: an input source, a skill that does the work, one or more verification points, and an output destination. Writing it as a single ad hoc prompt each week means re-deriving the instructions every time and never accumulating the fixes from last week's mistakes — the same "prompts are disposable, skills compound" argument from earlier in this series.
Worked example: weekly release notes
Input: merged PRs since the last run.
gh pr list --state merged --search "merged:>=2026-09-13" \
--json number,title,author,url,mergedAt
Skill: a release-notes skill that takes that JSON, groups PRs by label (feature, fix, chore), and drafts a changelog entry in your house style. Output: a draft, not an auto-post — at least for the first few weeks.
Where verification goes
Two checkpoints, as in the figure. First, coverage: does the draft mention every PR in the input, or did the skill silently drop one it didn't know how to categorize? This is a simple diff check, not a judgment call — count PR numbers mentioned in the draft against PR numbers in the input, and fail loud if they don't match. Second, tone and format: does it read like your changelog, not like a bullet-point dump of commit messages? This one is closer to a judgment call, so a lightweight review pass — a second agent, or a human skim — belongs here instead of in code.
Measure it
Time yourself doing the task manually for one week before automating it, and time how long you spend reviewing the automated draft for the following few weeks. If review time approaches the manual time, the pipeline isn't earning its keep yet — the skill needs more of the house-style detail baked in, not a better prompt each week.
Try it today
- Write down, in one sentence, what "correct" looks like for one task you already do weekly.
- Pull the raw input programmatically (an API call, a
ghcommand, a query) rather than by hand. - Write a skill for the drafting step, not a one-off prompt.
- Add one coverage check that fails loud rather than silently dropping items.
- Run it for real for one week before automating the "post" step.
Where this breaks
A pipeline built around one week's data shape breaks the first time the input looks different — a PR with no label, an empty week, a merge with no linked issue. Build for the edge case you'll hit, which is usually "nothing to report," before you build for the common case. And measuring time saved only works if you're honest about review time; skimming a draft and assuming it's fine is not verification, it's the same failure mode this whole series has been warning about.
Next, and last in this series: is AI actually helping your team — the metrics that tell you whether this pipeline, and everything else in these thirty notes, was worth doing.