How to use this page
A checklist to run through before committing edits. An item that doesn't pass is something to fix, not a style preference, and the agent linter runs the same list as an automated pass.
Links
Run through these before saving any block that contains links.
No "see X" or "details below" framing
Bad: "Details on the [payment page](page:N)" or "see [the documents page](page:N)".
Good: "by [the payment rules](page:N)", "required [documents](page:N) 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 text
Bad: "under ["Visa rules"](page:N)".
Good: "under [the visa rules](page:N)".
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 links
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 jumps
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 footers
Bad: a footer line tacked onto a page, such as "Back to [Eutropius](page:N)."
Good: weave the link into the opening prose on the noun it names, "English-edition breakdowns of [Eutropius](page:N)'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, and bodies that restate what the platform already keeps. Run through these whenever creating, splitting, or extending blocks.
No barren home: surface sub-pages with home blocks
Bad: a wiki whose entire content lives in sub-pages, with a front page that says nothing.
Good: give the front page direct child blocks that orient the reader and link the key pages.
What breaks: a wiki opens on its front page, and that page renders its own child blocks; child pages only get their own URL and are not stitched into it. So a wiki whose content sits only in sub-pages renders an empty-looking front page: 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 blocks on the front page it is empty too.
No tombstone blocks: delete outright, the history keeps the record
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 body
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 block
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 several 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 subtopics
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, which is the same tree damage arriving from the other side.
No outline navigation duplicated in prose
Bad: a body that lists its own sections ("Below: linking, structure, content"), or a count of what the page holds ("four page types: A, B, C, D") when those items are the blocks that follow.
Good: trust the outline. The rendered headings and the contents rail beside them already show what this page holds. Use body text to set context (what the topic is, why it matters), not to narrate the table of contents.
Child pages are the opposite case: neither the breadcrumbs nor the contents rail lists one, so a link in a body is its only path in, and cutting that link as navigation strands the page.
What breaks: the duplicated list goes stale the moment a section is renamed or moved, and it trains readers to expect prose summaries of structure they could see at a glance. A count is the sharpest form of it: nobody edits a sentence to fix arithmetic.
The test is where the sentence gets its truth from. If it comes from the tree of this page, the sentence goes: the reader already sees that tree, and it changes without asking the sentence. If it comes from the subject, the platform, the product or the rule itself, the sentence stays, even when today its number matches the tree. "The three laws of robotics" stays, because there are three of them whatever this wiki does, and so does "names are capped at 30 characters". "Six common mistakes" goes: today six, tomorrow ten, and the month after they are two sections.
No oversized bullets that should be h3 children
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 list that outgrew the name above it
Bad: a home block called "Working on a task" whose list has reached a dozen links, the last four of them about writing code, testing it and cutting a release.
Good: cut the list where the subject changes and name each part, so the outline gains a row rather than the body gaining a line.
What breaks: a list only grows because the subject under it grew, and the title stops covering what it holds. The reader who scans the outline sees one row where two subjects live, and the items that arrived last are the ones nobody is looking for under that name. The count is the signal, not how long an item runs: the rule against oversized bullets fires when one item swells into an essay, this one fires with every item still a single line. Cut where the topic changes rather than promoting every item to its own node, and leave each part enough to carry a claim, or the repair trades one overloaded row for a row of headings thinner than themselves. Growth is a symptom of branching, so branch the tree, never widen the title until it covers everything.
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.
No page grown past one reading
Bad: a page whose body runs past roughly two thousand tokens, or whose outline runs past a couple of dozen rows, carrying sections that share nothing but a parent.
Good: promote a section a reader could open cold to a page of its own; cut a page whose sections only make sense in sequence.
What breaks: past that size the reader scrolls instead of reading, and the per-page contents stops being a map and becomes a second document. The test is whether a section could be opened cold, and promoting one is not free: nothing in the chrome lists a page, so a promoted section stops being met by a reader scrolling the parent and is reachable only through a link somebody writes into it.
No catalogue tables: one node per entity
Bad: a table listing the members of a set, one row per entity, with columns for their properties.
Good: one node per entity, with the properties in its body. Keep tables for summaries and comparisons, where the point is reading across rows.
What breaks: a row is not addressable. It has no anchor to link at, it is indexed as part of one large block rather than on its own, and editing any entity rewrites the whole table in history. The moment one entity earns a paragraph, the table has to be dismantled anyway.
Prose form
Faults in how the writing reads on the page, where the tree is not what went wrong.
No unearned em-dash
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.
This rule is about English prose. In some languages the dash is required by grammar rather than chosen for effect: Russian puts one between subject and predicate when there is no copula, as in «Вики — первичный источник». Such a dash is spelling, not style, and this rule never removes it.
No one-line paragraphs that should be a list
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.