Onyx User Documentation
Traveler-facing documentation for the Onyx platform. This library contains guides, how-tos, and reference material that help Travelers navigate and use the application.
Structure
| Directory | Purpose |
|---|---|
getting-started/ | Onboarding guides for new Travelers |
adventures/ | Managing Adventures — launching, configuring, stopping |
foundry/ | Foundry VTT-specific guides (versions, modules, worlds) |
billing/ | Billing, wallets, statements, and pricing |
account/ | Account settings, profile, authentication |
assets/ | Images, screenshots, and diagrams referenced by docs |
Writing Guidelines
- Audience: Travelers (end users), not developers. Avoid technical jargon unless explaining a concept.
- Tone: Friendly, concise, and direct. Match the RJ personality — helpful without being patronizing.
- Format: Each document should have a clear title (
# Title), a one-sentence summary, and numbered steps for procedural content. - Images: Place screenshots in
assets/and reference them with relative paths:. Name files descriptively (e.g.,foundry-update-button.png). - File naming: Use lowercase kebab-case (e.g.,
update-foundry-version.md). - Cross-references: Link between docs using relative paths.
When to Update
User documentation must be updated whenever:
- A new Traveler-facing feature is added
- An existing workflow changes (new buttons, different steps, renamed options)
- A new environment variable or configuration option becomes user-visible
- A feature is removed or deprecated
For Agents
When working on a ticket that adds or modifies Traveler-facing functionality:
- Check if existing docs in this repo cover the affected feature
- If yes, update the relevant doc to reflect the changes
- If no, create a new doc in the appropriate directory
- Add screenshots to
assets/where they would help (agents without browser access should leave a<!-- TODO: screenshot needed -->placeholder) - Commit changes to this repo on the same feature branch as the code changes
Building / Serving
These are static Markdown files. They can be served directly, rendered by the Next.js frontend, or published to a docs site in the future.