Organic Growth of AI Writing Teams and Content Integrity

In my previous article, I wrote that "the environment gets a little smarter every time a problem occurs." The experience of cultivating skills and agents with Claude Code and systematizing my writing environment was fresh and exciting.

Two months have passed since then. The systematization cycle has continued, with the number of agents growing to five and skills to eleven. I have written 42 articles using this environment.

One day, I audited the entire system and found 32 contradictions. The parts that were supposed to have become smarter were telling each other different things.

The Big Picture of the Evolved System

In 63 days, the .claude/ directory has taken on the following structure:

.claude/
├── agents/ (5)        # editor, essay-reviewer, fact-checker, zenn-drafter, devto-translator
├── skills/ (11)       # writing-team, zenn-writer, publish-article, schedule-publish, ...
├── refs/ (3)          # writing-standards, translation-rules, schedule-schema
└── rules/ (1)         # content-integrity

scripts/
├── publish.py          # Dev.to cross-posting
├── scheduled_publish.py # Automatic scheduled posting
└── tests/ (8 files)    # 147 tests, 86% coverage

When writing a single article, this system operates as follows:

1. Writing: The zenn-writer skill provides tone and style guidelines. You can also entrust the draft to the zenn-drafter agent.
2. Review: The editor (structure/code quality) and essay-reviewer (logic/tone) evaluate the article from their respective perspectives. The fact-checker verifies factual claims.
3. Publishing: The publish-article skill presents a pre-publication checklist, and schedule-publish determines the timing.
4. Cross-posting: The devto-translator agent translates the Japanese article into English and posts it to Dev.to. publish.py handles the cross-posting via API.

Each component has its own rules. zenn-writer has a character limit for titles. The editor has a blocklist for AI slop (empty, clichéd expressions). devto-translator has specific formatting rules for translation. Each embodies the "optimal judgment for its own scope."

None of this was planned from the start. It grew to this point through a repeating cycle: write an article -> encounter a problem -> systematize. It was the result of the growth pattern I described in my previous work continuing unabated for two months.

32 Contradictions Found All at Once

The trigger was a simple desire to "reorganize the writing team." Before creating a new orchestrator, I wanted to understand the current state, so I ran three investigations in parallel using Claude Code's sub-agent functionality: an audit of styles/tones, an audit of translation/publishing flows, and a gap analysis.

The results were unexpected. 32 issues emerged at once.

Take the character limit for titles, for example. zenn-writer said "under 50 characters," zenn-drafter said "under 60 characters," and zenn-format said "50-60 characters." Three components were saying slightly different things.

The blocklist for "AI slop" (empty, clichéd expressions) was even worse. It was copy-pasted with slight variations into three different places: editor, zenn-drafter, and zenn-writer. In some places, "groundbreaking" was banned, while in others, it wasn't listed at all.

Three components claimed responsibility for translation: the translate-article skill, the devto-translator agent, and the publish-article skill. Most interestingly, translate-article had a note in its own description saying, "For end-to-end, the devto-translator agent is recommended." It was self-negating its own existence.

Why does this happen? Incremental construction creates local optimization. Each component is optimized for the "context at the time of creation." Skills created in February reflect February's judgments, while agents created in March reflect March's insights. However, there was no mechanism to guarantee overall consistency. The same structure as "technical debt" in software development was occurring in the knowledge layer of AI agents.

Summarizing the audit results in numbers looks like this:

Metric	Before (Pre-audit)	After (Post-redesign)
Contradictory rules	12 (character limits, AI slop list, emotional language policy, etc.)	0 (consolidated as masters in refs/)
Rule duplication	8 (AI slop copy-pasted in 3 places, etc.)	1 per item
Ambiguous component ownership	4 (3 parties claiming translation, etc.)	1 owner each
Shared references (refs/)	0	3 (writing-standards, translation-rules, schedule-schema)
ADR (Architecture Decision Records)	0	2 (Content Integrity, Orchestration)

Out of the 32 issues, 12 contradictions, 8 duplications, and 4 ambiguities in responsibility were at the core. The rest were derivative inconsistencies resulting from these.

Tools Themselves Can Introduce Bias

Among the 32 issues, the one that gave me the most to think about was the catchify skill.

catchify was a skill designed to rewrite the beginning of an article to be more dramatic and the headings to be more emotional. I created it in February as a "tool for making things catchy" and actually used it for a few articles.

The problem was that the mere existence of this tool created pressure to use it, as it felt "a waste not to." After finishing an article straightforwardly, I felt like I was cutting corners if I didn't run it through catchify. The tool's very presence was biasing the author's judgment.

This is a problem of organization and workflow as much as it is a software problem. When you introduce a code review tool, there's an atmosphere that every PR requires a review. When you add a step to a CI pipeline, you become resistant to removing it. Tools don't just "increase options"; they increase the cost of the "choice not to use them."

I abolished catchify. With no tool, there is no bias.

Content Integrity — A Principle That Resolved Contradictions

Abolishing catchify was merely a symptomatic treatment. What I needed were criteria for judging "what is okay to automate."

This is where the principle of "Content Integrity" was born. It was sparked by my own feeling that "I want to express my thoughts honestly." This isn't to say I want to deny SEO optimization itself. Choosing words for titles or optimizing tags increases the probability of reaching readers without changing the content. I found that to be rational.

The problem was optimization that changes the content itself. Rewriting the beginning for "search snippets." Making headings "emotional." These process the author's thinking for the sake of distribution.

From this, the boundary between Content and Distribution became clear.

Layer	Example	Principle
Content	Structure, logic, opening style, headings	Follow the author's thinking. Do not change for optimization
Distribution	Word choice in titles, tags, emoji, posting timing	May be optimized without changing content

I recorded this principle as an ADR (Architecture Decision Record) and configured it to be automatically loaded in every session as a rule file.

As a result, catchify was abolished. The seo-optimizer had its content-rewriting features removed and was limited strictly to titles, tags, and emoji. The scoring axis of schedule-publish was renamed from "Search Magnet" to "Discoverability" (Can interested readers find it?).

Many of the 32 contradictions became clear when viewed against this principle. Rather than crushing them individually through refactoring, the principle provided a basis for judgment, allowing me to redesign the system in a consistent direction.

Maintaining Consistency through Structural Patterns

Principles alone cannot prevent the recurrence of contradictions. The structure also had to change.

Centralization in refs/ — I aggregated AI slop lists, tone rules, translation rules, and schedule schemas into a single location (.claude/refs/), ensuring each component only holds reference pointers. The AI slop list that had been copy-pasted in three places now exists as one master copy with three references. Updating the master copy propagates the changes throughout the entire system.

ADR-First — Record decisions before changing the system. For the Content Integrity principle, I first wrote ADR-0001 to document the rationale and scope of impact, and only then began the abolition of catchify and the modifications to seo-optimizer. Without the recorded rationale, it would be impossible to understand six months later "why catchify was removed."

Unique Assignment of Responsibilities — Translation is handled only by devto-translator, and SEO is handled only by seo-optimizer. One owner for one concern. Components like translate-article, which "negated its own existence," were signs of overlapping responsibilities.

Interruptions Improved the Design

The most interesting part was the process of redesigning itself.

I proceeded with the redesign through a dialogue with Claude Code. I would convey the policy, and Claude Code would plan and execute it. The project started with the plan to "build an orchestrator," but I interrupted the process three times before implementation.

"Wouldn't it become unorganic if the content of each part is contradictory or redundant?"

Without this, I would have proceeded with the orchestrator while still holding onto the contradictions.

"Shouldn't we create an ADR?"

Without this, the reasoning behind the decisions would have been lost.

"SEO itself is fine. It's changing the content that is the problem."

Without this, I might have completely abolished SEO optimization.

While there is a lot of buzz around letting AI agents plan and execute autonomously, in this case at least, human intervention improved the quality of the design. Autonomous execution is efficient, but fundamental reassessments come from outside the loop.

Conclusion

The conclusion of my previous article was that "the environment gets a little smarter every time a problem occurs."

Two months later, I realized that smarter components can contradict each other. Individual components optimized in stages do not possess consistency as a whole. This is not limited to AI agent knowledge layers; it is the fate of every system that grows organically.

And what resolved those contradictions was not individual refactoring, but the principle of Content Integrity. "Content is decided by the author's thinking. Distribution optimizes without changing the content." This single sentence became the standard for deciding which of the 32 contradictions to keep and which to discard.

Organic growth requires periodic inventory and principles that serve as the foundation for judgment.