Community and help
You do not need to be a customer, a contributor, or an event-sourcing expert to ask for help. Cratis is an open community, and we are glad to help people who are evaluating the stack, building their first slice, debugging a running store, or trying to understand the model.
The place to start a conversation is the Cratis Discord community. Bring the question you have, even if it is not polished yet. In the help forum and the dedicated ask channel, Prompter, the community’s documentation assistant, answers first on its own, from these docs and with citations, and hands you to a human when the docs do not cover it. Elsewhere on the server, mention it or use /ask. Community help from people is best-effort.
Where to ask
Section titled “Where to ask”| When you need… | Start with… |
|---|---|
| A cited answer to a documentation question | Prompter on Discord |
| Help deciding whether Cratis fits your system | Cratis Discord |
| A second pair of eyes on an event model, projection, command, or slice | Cratis Discord |
| Help with a tutorial, sample, local setup, or first application | Cratis Discord |
| A reproducible bug in a product | The matching GitHub issue tracker |
| A feature request or design proposal | GitHub issues, with Discord for early discussion |
| Suggestions, rough edges, or documentation gaps | Feedback and suggestions |
| Private, dedicated, or commercial help | Work with us |
| To understand how dedicated help differs from community help | Professional help |
| A suspected vulnerability | Security, never a public issue |
| Contribution workflow, coding standards, or build setup | Contributing |
If you are not sure which product owns the problem, ask in Discord first. We can help route it to the right repository.
GitHub issue trackers
Section titled “GitHub issue trackers”Use issues when the work needs a durable record: reproducible bugs, feature requests, regression reports, or documentation fixes. For open-ended questions, Discord is usually better. Each client and tool has its own repository, so file the issue where the code lives:
| Area | Issue tracker |
|---|---|
| Chronicle kernel, .NET client, Workbench, and hosting | Chronicle issues |
| Chronicle TypeScript client | Chronicle.TypeScript issues |
| Chronicle Kotlin/Java client | Chronicle.Kotlin issues |
| Chronicle Elixir client | Chronicle.Elixir issues |
| Chronicle MCP server | Chronicle.Mcp issues |
| Arc for C#: commands, queries, proxy generation, validation, and backend/frontend integration | Arc issues |
| Arc for Kotlin and Java | Arc.Kotlin issues |
| React components, forms, dialogs, tables, styling, and Storybook | Components issues |
| AuthProxy | AuthProxy issues |
CLI commands, diagnostics, cratis ai, and cratis init | CLI issues |
dotnet new project templates | Templates issues |
| Cratis AI rules, skills, and plugins | AI issues |
| Fundamentals libraries and shared .NET/TypeScript helpers | Fundamentals issues |
| Documentation site, guides, examples, and broken links | Documentation issues |
How to get a useful answer
Section titled “How to get a useful answer”You can ask early. When you have the details, include the parts that make the problem reproducible:
- What you are trying to build or decide.
- Which product you are using: Chronicle, Arc, Components, CLI, Fundamentals, or the full stack.
- The package or Docker image versions, if you know them.
- The command, event, projection, query, component, or configuration involved.
- The expected behavior and what happened instead.
- Error messages, trimmed logs, screenshots, or a small repository when the problem depends on runtime behavior.
Remove connection strings, tokens, certificates, and personal or customer data from anything you post. Discord threads and GitHub issues are public.
Community expectations
Section titled “Community expectations”We want Cratis to be useful to people who are learning, evaluating, operating, and contributing. Be clear about what you need, assume good intent, and keep discussions respectful. The Code of Conduct applies to the community spaces and the repositories.
Start with the Cratis Discord community, then move durable bugs, proposals, and documentation changes into the relevant GitHub repository when the thread becomes actionable.