The Layout Skill Wasn't Thrown Away: One QA Chassis Shared by Three Writers

I almost deleted the layout Skill

When three Writers produced inconsistent output, the first thing I did was stuff rules into the prompts. What font size for the WeChat article, how many lines per paragraph on Xiaohongshu, how to level blog headings — each written out separately. The pages got tidy fast, but the system got harder and harder to change.

The same mobile rule was copied three times. Change the width once and I had to go sync three prompts. Worse, the Writers started using "improving the layout" as cover to rewrite sentences, add slogans, even change the original conclusion.

Adding more rules only tangled writing and engineering tighter. The problem wasn't that one Writer wrote badly — it was that I'd made it responsible for expression, conversion and acceptance all at once.

Three layers, each owning a different verb

In the end I split the chain into Writer, Formatter and Layout Gate.

The Writer owns "choosing and expressing"

The Writer takes the source, the fact table, the target reader, the platform and the point-of-view boundary, and outputs well-structured Markdown.

It can decide whether to lead with the case or the concept, and keep a tone that fits the platform. But it doesn't decide the final CSS, doesn't hard-code font sizes, and doesn't operate publishing accounts directly.

The Formatter owns "mapping and converting"

The Formatter stably maps Markdown elements to the target platform's HTML or page components.

What tag an h2 maps to, how a code block is handled, how an image carries alt text, how a long link wraps — these are conversion rules. The same input, under the same version of the Formatter, should produce the same structure as much as possible.

The Layout Gate owns "finding and reporting"

The Layout Gate is read-only QA. It doesn't rewrite the whole text just to make the page pass, and it doesn't hold publishing permission.

Its output isn't "already optimized" — it's a list of problems, which must state:

• What the faulty element is.
• Which page or node it's on.
• Which rule it violates.
• Whether the risk is readability, semantics, copyright or publishing.
• Whether to fix it back at the Writer, the Formatter or the asset layer.

This lets a failure be sent back to the right station, instead of handing every problem to the writer to redo.

The input contract matters more than "consistent style"

The three Writers can express differently, but the structure they hand to the Formatter must have a minimum agreement.

The minimal Markdown contract I require includes:

• Only one article title.
• Heading levels don't skip.
• Images must have a purpose note and alt text.
• Code blocks mark the language or are explicitly plain text.
• Link text explains where it's going.
• No page-specific font sizes and colors in the body.
• Quotes and the author's judgments aren't mixed into ordinary paragraphs.

This contract doesn't dictate how long each paragraph must be, and doesn't require every article to have the same "conclusion, risk, next step." It constrains the structure the machine needs to understand, without taking over the author's narrative.

How one overstep happens

Say the original wrote:

This step only confirms whether a draft exists; it can't prove the article was broadcast.

An overstepping layout prompt might, in the name of "stronger reach," rewrite it as:

Truly professional automation never chases speed — it reshapes the content-growth loop.

The page may look more like marketing, but the key information is gone. The layout layer did the content layer's job, and left no reason for the change.

A correct Formatter should only convert the original sentence into a quote style; if the sentence is too long or unclear, the Layout Gate reports the problem, and the Writer decides whether to change it.

How I do mobile acceptance now

A desktop page looking fine doesn't mean the published version is readable. The Layout Gate has to check at least once at a narrow viewport close to a real phone. I often use 390 × 844 as the review window, but it's just one representative size, not a substitute for other devices.

The focus isn't "does it look nice" — it's observable problems:

1. Whether the page has horizontal scroll.
2. Whether long English, URLs and code overflow.
3. Whether the heading fills the entire first screen.
4. Whether the body is small enough to need zooming.
5. Whether images are cropped of key information.
6. Whether tap targets overlap.
7. Whether a fixed bottom bar blocks the body.
8. Whether there's a jarring break between a dark image and the light body.

If the QA can only return "overall premium, clear hierarchy," it hasn't become an engineering check yet.

Why QA doesn't auto-fix by default

Auto-fixing is tempting, but it makes the problem's source disappear.

For instance, an image too wide on mobile could come from three causes: wrong asset dimensions, HTML missing a responsive attribute, or a fixed width in the page CSS. If the Layout Gate edits the CSS directly, it may mask the real asset-contract problem.

So I split the action in two:

1. QA is read-only, outputting a clearly located problem.
2. A person or a fix tool chooses, based on the problem, to change the text, the converter, the asset or the style.

Then re-run the same checks. That way every fix traces back to a clear rule, instead of accumulating random patches.

After three Writers share one chassis, what should change

Success isn't three articles looking identical. On the contrary, I want to see:

• The WeChat article still suited to continuous reading.
• Xiaohongshu still organized around an image-and-text rhythm.
• The blog still keeping full explanation and citations.
• None of the three with heading jumps or horizontal overflow.
• Consistent image-source, alt-text and link rules.
• Changing one layout rule means editing one place.

Varied expression and unified engineering don't conflict. The conflict usually comes from writing two kinds of rules into the same role.

When migrating an old system, don't redo every Writer at once

A safer order is:

1. Pick one finished article as a fixed sample.
2. Save the original Markdown, the old HTML and real phone screenshots.
3. Remove the specific visual and publishing instructions from the Writer.
4. Hand structure conversion to one Formatter.
5. Let the Layout Gate read-only compare the new and old results.
6. Confirm no semantic change, then connect the second Writer.

If the page gets uglier, first locate which layer first produced the difference. Don't stuff all the old rules back into the Writer, and don't overwrite content again with "unified style."

The layout Skill wasn't deleted in the end — it just stepped out of the writing seat. The Writer decides what to say, the Formatter handles conversion, the Layout Gate points out where the page is wrong. Once the three are separate, expression can differ while the baseline stays the same.