Best Practices

Treasury docs should make the system easier to operate. The goal is not to preserve every implementation detail; the goal is to give users and operators the shortest reliable path to the right action.

Keep workflow ownership clear

Every page should make it obvious what surface owns the workflow. If a task belongs in Discord, say so. If it belongs in the main site, point there. If it belongs to an internal operator path, describe the handoff instead of exposing internal mechanics as a public user action.

Use clear ownership language:

• "Use the Treasury Discord for support."
• "Use the main Treasury site for public entry."
• "Use this runbook when handling repeated operator work."

Do not invent public support channels

Treasury does not use public support email as the primary docs support path. Do not add support emails, blog links, public package names, or external product links unless Treasury actually owns that surface.

When a user needs help, link to the Treasury Discord.

Keep separate systems separate

Treasury has multiple systems that may work together, but docs should not blur their responsibilities. A transcript workflow, a Discord workflow, a support workflow, and an automation workflow may touch the same user journey while still having different owners and failure modes.

When documenting a workflow:

• Name the entry point.
• Name the expected output.
• Keep internal implementation details out of user-facing instructions unless they change user behavior.
• Avoid describing one system as if it owns another system's job.

Prefer direct actions

Docs should favor direct next steps over broad explanation. A reader should know what to click, where to ask, what to gather, or what to verify next.

Use short sections, concrete labels, and stable links. Avoid long generic platform language that could describe any SaaS product.

Write for repeated support use

Treasury docs are useful when support can link them during a real conversation. Write pages so they answer the next obvious question without requiring someone to explain the entire system again in Discord.

Good support-oriented pages include:

• Required context.
• Common mistakes.
• Expected screenshots or artifacts.
• Escalation path.
• A Discord link for unresolved issues.

Review before publishing

Before treating a page as ready, check that it:

• Does not mention unsupported Treasury channels.
• Does not point to inherited support, blog, package, or marketplace surfaces.
• Does not expose internal tooling as a public user requirement.
• Has a clear next step.
• Builds successfully in the docs app.