Kyogre
Writes a post from the day’s commits, grades its own work, and rewrites until it passes.
Kyogre turns a day of commits into a blog post without me in the loop. At 11 PM it collects everything I pushed that day, pulls the diffs, and asks Claude which of it is actually a story — an architectural decision, a debugging session, a performance win, a failure worth admitting — and throws away the typo fixes and dependency bumps. It writes the draft, scores it from 0 to 10 against the writers I want to sound less unlike, and rewrites it up to three times until it clears a 7. Then it opens a pull request on this portfolio. Most of the writing here arrived that way, and every Sunday the standards it grades against get rewritten too.
Python 3.12 · Claude CLI · GitHub API · launchd · uvWhat it does
Commits in, stories out
It collects the day’s commits across every repo I pushed to and fetches the diffs, so the draft is written from what the code actually did rather than from commit subject lines.
It grades its own writing
Every draft is scored 0-10 the moment it exists. Below 7 it gets rewritten with the critique attached, up to three iterations. Nothing under a 7 is ever published.
Judged against real writers
The scoring rubric is built from technical writers worth imitating — Emil Kowalski, Josh W. Comeau, Dan Abramov, Julia Evans, Kent C. Dodds, Martin Fowler, Simon Willison — one for depth, one for clarity, one for accessibility.
The standards evolve weekly
On Sunday it reads what those authors published recently, reviews the week’s successful rewrites, and updates its own quality standards. Next week’s posts are graded against the tighter bar.
It learns from its rewrites
When a rewrite pushes a draft over the line, the change that worked is extracted and saved as a pattern, then folded back into the prompts.
It ships a pull request
The output is not a file in a folder somewhere. It opens a PR on the portfolio repo with the post and frontmatter, so the last decision — publish or not — is still a human one.
How it works
What gets published
Architectural decisions, debugging sessions, performance work, patterns worth stealing, and failures with a lesson attached. Not typos, README edits, dependency bumps or trivial refactors — most of a day’s commits are correctly thrown away.
Zero manual overhead
Generation, evaluation, rewriting and the weekly standards update all run on schedule with no input from me. The only work left is reading the PR — and the honest failure mode is that it stays silent on a quiet day, which took a while to tell apart from it being broken.
Every chapter is a part of my journey. Thanks for being here! ♡