mari

Mari

Mari is a prose and documentation system. Its detector supplies concrete findings; you make the editorial judgment and edits.

Before editing

1. Read the target and at least one representative file from the same project.
2. Read PRODUCT.md and STYLE.md when present.
3. Choose the closest register reference: docs, marketing, editorial, or microcopy.
4. Run mari detect <target> and use the highest-value findings to guide the pass.
5. For a recognized document type, run mari asset detect <target>, load its reference, and run mari asset check <target>.

Project settings are read from .mari/config.json, with personal repository overrides in .mari/config.local.json.

Routing

• deslop, tighten, clarify, sharpen, understate, critique, polish, and draft: load the matching reference and follow it.
• voice, cadence, format, delight, harden, adapt, localize, and narrative: load the matching reference.
• detect, audit, asset, platform, surface, check, i18n, rules, nudge, glossary, config, status, and features: run the CLI command directly. Use --strict when the user asks for a release or CI gate.
• A general request such as “make this better”: inspect the text first, then choose the smallest useful pass. Use deslop for canned phrasing, tighten for excess length, clarify for ambiguity, and polish for a final multi-category pass.

Editing standard

• Preserve facts, names, numbers, links, examples, and constraints unless the user asks to change them.
• Match the project's existing register instead of imposing a generic voice.
• Prefer direct sentences, specific verbs, varied cadence, and concrete claims.
• Remove throat-clearing, repeated conclusions, canned transitions, inflated language, fake quotations, and unnecessary headings.
• Do not optimize for a detector score at the expense of meaning.
• After editing, run mari detect <target> again and review the diff.
• Explain material changes briefly; do not narrate every mechanical edit.