A checklist to run through before committing edits. The outline below is the list itself: every h3 is a checkable item. An item that doesn't pass is something to fix, not a style preference. The agent linter runs this list as an automated pass.
Links
Run through these before saving any block that contains links.
No "see X" or "details below" framingbefore-write
Bad: "Details on the payment page" or "see the documents page".
Good: "by the payment rules", "required documents include…".
What breaks: the bad form references the wiki's UI ("page", "section") instead of the topic. Readers don't know about pages, only about subjects. Anchor on the noun and weave the link into the sentence.
No quotation marks around link textbefore-write
Bad: "under "Visa rules"".
Good: "under the visa rules".
What breaks: quoting the title makes the link feel like a citation of a name. The link should weave into the sentence as a natural noun phrase, not stand off as a quoted artefact.
No publisher-anchored article linksbefore-write
Bad: "the fact-checker Raskrinkavanje refuted the claim".
Good: "the fact-checker Raskrinkavanje refuted the claim".
What breaks: when the URL points to a specific article, anchoring on the publisher name makes the link read as if it goes to a homepage. Anchoring on the verb makes it clear the link is to the piece itself.
No same-page block:N jumpsbefore-write
Bad: dropping a block:N inside the same page where the target lives.
Good: assume readers expect links to leave the page; restructure if a same-page jump feels needed.
What breaks: a same-page jump usually masks a deeper problem: "details below" framing, duplicated content, or a block that wants to be split. The reader clicks expecting elsewhere and lands two screens down on the same page; that's a small but real betrayal.
No "Back to X" navigation footersbefore-write
Bad: a footer line tacked onto a page, such as "Back to Eutropius."
Good: weave the link into the opening prose on the noun it names, "English-edition breakdowns of Eutropius's Breviarium", and drop the footer.
What breaks: the parent is already one click away through backlinks (the "pages here" panel), so the footer just duplicates navigation the reader already has. And any page may be printed or exported to a standalone document; on paper a "Back to X" line links nowhere and reads as stranded UI chrome. A link earns its place inside a sentence, anchored on the subject it points to, never as a navigation stub at the foot of the page.
Structure
Tree damage. Run through these whenever creating, splitting, or extending blocks.
No barren home: surface sub-pages with home blocksbefore-write
Bad: a wiki whose entire content lives in sub-pages, with a home that is only the wiki's intro markdown.
Good: give the home direct child blocks that orient the reader and link the key pages.
What breaks: the home body renders the wiki's own markdown plus its direct child blocks; child pages only get their own URL and are not stitched into the home body. So a wiki whose content sits only in sub-pages renders an empty-looking home — the content is one click away but invisible to a reader who lands there. The right-column table of contents lists the current page's blocks, so with no home blocks it is empty too.
No tombstone blocks: delete outright, the history keeps the recordbefore-write
Bad: leaving a block that documents its own obsolescence, "Moved: X now lives on the Y page", or "This stray block was created by mistake and is superseded, safe to delete in the next rebalance".
Good: once the content has a home elsewhere, delete the block in the same edit. If it moved, confirm it landed at the destination first, then remove the original.
What breaks: a "delete me later" note is clutter that outlives its promise, and every node edit is versioned, so the block's prior content stays in the audit trail rather than needing a farewell note. Parked on a visible page, usually the home where stray blocks collect, the tombstone interrupts the read for every visitor, and one that points at where the content "now lives" is one more line to go stale or mislead.
No as-of or last-checked dates in the bodybefore-write
Bad: stamping a body with its own currency, "[Checked 2026-04-05]", "Updated April 2026", or "as of Q2 the rate is …".
Good: state the fact without the stamp; the node's own updated_at, shown by the engine and returned by every read, already records when it last changed. Dates that belong to the subject stay: "founded in 1863", "the 2008 orthography reform", "married in March 2022".
What breaks: the stamp shadows metadata the platform already keeps, so it drifts the moment someone edits the body without touching it, and then it misreports how fresh the content is. The test is authorship versus subject: a date describing when the page was written or reviewed is edit metadata and comes out; a date that is part of what the topic is stays in.
No bold-prefix subtopics inside one blockbefore-write
Bad: a block whose body opens "Has agency. … Owns hygiene. … Defends the source. …".
Good: each bolded subtopic promoted to its own h3 child block.
What breaks: bold-prefix is fake h3. It hides four (or five) nodes inside one. get_outline shows one node, cross-links can only point at the whole block, history records every change as one diff, and splitting later is harder. Tree damage masquerading as style.
No flat h2-only outlines on pages with subtopicsbefore-write
Bad: a page with five h2 sections, zero h3 children, and each h2 body containing 3+ visually parallel ideas.
Good: each parallel idea promoted to its own h3 child block.
What breaks: the platform's default is h2/h3, deeper when the topic earns it. A flat outline almost always means subtopics are hiding inside blocks as bold-prefix paragraphs. See above.
No outline navigation duplicated in prosebefore-write
Bad: a body that lists its own sections ("Below: linking, structure, content") or a wiki intro that announces "here you'll find pages on X, Y, Z".
Good: trust the outline. Side nav, breadcrumbs, and the rendered headings already show the structure. Use body text to set context (what the topic is, why it matters), not to narrate the table of contents.
What breaks: the duplicated list goes stale the moment a section is renamed or moved. Worse, it trains readers to expect prose summaries of structure they could see at a glance.
No one-line paragraphs that should be a listbefore-write
Bad: a sequence of one-sentence paragraphs that share parallel structure.
The agent is the journalist.
The human is the editor-in-chief.
Both think; only one signs off.
Good: bullets, because the items are short and parallel.
- The agent is the journalist.
- The human is the editor-in-chief.
- Both think; only one signs off.
What breaks: parallel ideas in separate paragraphs read as sequential narrative steps. The reader has to reconstruct that they're a list. The bullet form carries "these belong together" visually for free.
No oversized bullets that should be h3 childrenbefore-write
Bad: a bulleted list where each item runs several sentences or paragraphs.
- First item. Long explanation. Multiple sentences with detail and caveats and examples.
- Second item. Same shape — a small essay inside a single bullet point.
- Third item. Same again.
Good: each item promoted to its own h3 child block.
What breaks: bullets are visual shorthand for short parallel items. Long items inside bullets lose addressability (no block:N to link at), readability (no clear visual separation), and history granularity (every edit shows up as "changed the list"). When a bullet wants to be a paragraph, it deserves a node.
No block thinner than its own title
Bad: a two-line heading above a single sentence that adds nothing the heading had not already said.
## The interface language can be switched, but answers are written in English anyway
Two options, English or Other.
Good: fold the fact into a neighbouring block as a sentence or a bullet, or give the body enough that opening it is worth the click.
What breaks: two rules combine into a trap. Title is the headline of the body asks the title to state the claim; One claim per block leaves the block holding exactly one. Follow both literally and the title swallows the content, so the body is left repeating its own heading in smaller type. The reader meets a heading larger than the thing it introduces and learns that the structure is decoration.
A one-sentence body is also the one-line paragraph antipattern promoted a level: as a node it costs an outline row and a screenful of whitespace on top of the original sin. The test is to cover the title and read the body alone. If the body still carries the claim, the block has earned its place; if it reads as a footnote to its own heading, merge it into the sibling it belongs with.
Punctuation
One mark, used too widely.
Avoid the em-dashbefore-write
Bad: "The agent, not the human, writes content — sometimes structurally," reaching for a dash where a comma or period belongs.
Good: "The agent, not the human, writes content. Sometimes structurally."
What breaks: the em-dash (—) is a rare mark, not default punctuation, and it has to be earned. Almost every pause, aside, listing, or explanation reads better with a comma, colon, period, or parentheses, so reach for those first and keep — for the seldom case where nothing else carries the meaning. A page sprinkled with dashes reads as if every clause is dramatic, and it is a tell of unedited machine prose. When you meet an existing em-dash while editing a page, rewrite it then.