Who Writes the Rules the AI Follows?

In a way, writing this article feels like the old saying "cutting off one's nose to spite one's face." Complete documentation automation certainly feels like (another trite old saying) "another nail in the coffin." Hmmm, are there any other trite sayings that are appropriate? Oh, yeah, it may be "a blessing in disguise." But is full automation a replacement for an experienced documentarian?

The article in question is from Sleekplan, and it describes using Claude Skills, Claude Code, and Cowork to automate release notes from end to end. Pull from git history, PRs, and issue trackers. Synthesize. Draft. Route for human review. Publish. Repeat on a schedule. The workflow is real and it works. I've read it twice.

The second reading is where it gets interesting.

Here's what the article actually describes, beneath the workflow diagrams. Someone has to write the SKILL.md — the file that encodes how your team writes release notes, what tone is appropriate for which audience, how commit types map to changelog categories, and what a breaking change looks like in your specific product. Someone has to write the CLAUDE.md that documents your philosophy and style. Someone has to build the VALIDATION.md — the preflight checklist that flags problems before anything publishes. Someone has to curate the PATTERNS.md with examples of releases that actually got it right.

These aren't configuration files. They are documentation artifacts, written by someone who understands documentation systems well enough to encode decades of judgment into a format an AI can follow.

Now add the compliance layer.

If your company operates in RegTech, healthcare tech, financial services, or any regulated vertical, your release notes are not a courtesy to your users. They are evidence. SOC 2 Type II has a change management control - CC8.1 - that requires documented processes for system changes. HIPAA requires audit trails. FDA-regulated software operates under 21 CFR Part 11. Financial services regulators want version history that maps changes to business impact, with breaking changes surfaced and security updates handled with documented urgency.

The Sleekplan workflow actually gets this right. Their example output has explicit sections for Added, Changed, Fixed, and Security. Their validation rules require breaking changes at the top with migration notes. Their multi-stage review - Claude drafts, human edits, engineering signs off, then publishes - creates an approval chain that looks very good in an audit.

But someone has to design that chain for your specific compliance requirements. Someone has to know that "Security: bumped OpenSSL" means something very different to a SOC 2 auditor than it does to an end user, and that both audiences need to see it written differently. Someone has to define what "breaking" means in your product and make sure the AI flags it correctly every time.

That's not automation. That's documentation architecture. The automation runs on top of it.

The nail in the coffin turns out to be a foundation, not a lid.