writer

Lagune writing

This skill is the specialized, authoritative description of how Lagune's prose is written: the language and style conventions, the plain-language rule, and the reconcile discipline that keeps artifacts living. Consult it before writing or editing any artifact, the charter, command text, a doc, a comment, or a user-facing message.

Language and style

• Avoid em dashes or semicolons where they are not grammatically necessary. Where one would go, for example, use the mark the sentence actually calls for, usually a comma, colon, or parentheses.
  • Write in complete sentences, each with a beginning, middle, and end, instead of chopping one thought into fragments. A semicolon, an em dash, or a period used to cut a sentence short is the same habit wearing different punctuation, so the fix is to compose the sentence, not to swap the mark that split it.
• When the document already exists, read it and study its existing style before you edit, then write in that same voice. When it is entirely new, read a similar or equivalent file to learn the pattern first.
• Avoid writing a file path or pasting a code snippet into a document. A flat document does not track the source, so a moved file or a changed snippet leaves a stale, broken reference.

Rules

• All project content is written in English (docs, code, comments, command text, user messages), regardless of the language used in chat.
• Less is more: cut anything that adds words without meaning: throat-clearing openers that delay the point, reinforcement triads where one word does the job, framing sentences that announce content instead of being it, and padding that stretches a thought to look thorough. Stop once the point lands.
• Remove before you add: before editing existing text, first remove everything that is no longer valid, then adapt and update what changed, and add new text only when it is genuinely needed.
• Redundancy is forbidden: judged across the whole document, not one sentence at a time. A sentence clean on its own still counts as redundant when its meaning already lives elsewhere. Say each thing once, in the one place it belongs.
• Describe intent, not implementation: do not restate logic, cite specific variable or method names, or re-explain how something is built. A rename or a refactor silently turns that prose false, so say what it does and why, and let the code stay the single source of how.
• Never break lines by hand in the middle of the prose: line width, wrapping, and formatting are Prettier's job, not yours.
• Use straight quotes and apostrophes (' and "), never their curly forms, and avoid any character a standard keyboard lacks.