Skip to content
Raw Markdown

Ask, analyze and improve

Ask your first question, then a useful follow-up. A definition you clarify in conversation can become shared context for future questions.

1. Ask, then follow up

Ask your question in the Cassis web app’s Chat, or through your connected assistant.

Check the SQL’s join, calculation, filters and dates. Compare the result with a trusted query or report. On a DDL project, run the returned SQL with your own tools; a connected project can return the result directly.

Ask a useful follow-up to your own question. For example, if you asked “What was revenue last month?”, try “How much of that came from repeat customers?” The follow-up may need a definition your context does not yet contain.

Answer clarifications and correct wrong assumptions in the same conversation. Give the business rule and its source; if SQL fails, include the error. When using a connected assistant, ask it to send corrections and feedback to Cassis. Cassis can use what the assistant sends, not the rest of your assistant chat. Check the follow-up answer too.

2. Review what Cassis learned

In a git-managed project:

Prompt for an agent Analyze the chats with Cassis

Runs Cassis's project-wide analysis and shows its findings for review.

Ask Cassis to analyze the chats in this project. Show me the issues, their evidence and any proposed fixes so I can review them.
Commands behind analysis
cassis issues analyze
cassis issues list --status open
cassis issues show <issue-id>
cassis issues evidence <issue-id> <occurrence-id>

analyze uses the project bound to this folder and waits by default. Cassis selects its recorded chats for analysis; the agent retrieves issue and occurrence IDs from its responses. A fix proposal may arrive after analysis finishes. Starting analysis requires Editor or Admin.

In an app-managed project:

Open Review and choose Analyze conversations (Editor or Admin). Read any issues Cassis finds, their conversation evidence and the proposed fixes.

If your answers check out and Cassis finds no issue, you can move on. An issue is not required to complete the guide. Investigate any unresolved error before relying on the result.

3. Review and publish a change

If Cassis proposes a fix, review it against the conversation and your business definition. Confirm the proposal or explain what needs changing.

In a git-managed project:

Prompt for an agent Apply the reviewed proposal

Updates the local context and checks the affected answers before publication.

That proposal looks right. Apply it and check my first question and follow-up. Show me the changes and results before publishing.
Commands behind the correction
cassis context fmt
cassis context check
cassis context test -q "<your first question>"
cassis context test -q "<your follow-up>"
git diff -- cassis

These tests use the local draft without publishing it. With a DDL project, execute the generated SQL using your own tools to check the results.

Review the diff and test result, then publish:

Prompt for an agent Publish my reviewed context

Publishes the reviewed context to your project.

Publish this reviewed context using the project's publishing workflow, then confirm the new version is live.
Commands behind publication

For a new project without GitHub App or CI publication, the agent checks and commits the reviewed context, then uploads it. If publishing is already configured, use the existing Git workflow.

cassis context fmt
cassis context check
git add -- cassis
git diff --cached -- cassis
git commit --only -m "Publish reviewed Cassis context" -- cassis
cassis context upload
cassis status --watch

The first upload publishes version 1. Each upload replaces the whole context with the committed files. A local repository is enough.

In an app-managed project:

On the issue, choose Apply fix if the proposal matches the agreed rule. Otherwise, use Fix in chat to give the context Assistant the correction. Review Unpublished changes, then Publish.

To test an unpublished correction in Chat first, make it on a Cassis branch. A chat on main uses the published context.

Ask again in a new conversation and verify the answer. If the change addressed an issue, resolve it through your agent or in Review once the published fix checks out.

You can add or update a known definition directly, without creating an issue. Tell your coding agent or the context Assistant what should change and why. Review, check and publish the change in the same way.

Deploy Cassis to your team

You have a first working context. Put it to use with a small group around one business use case: choose the questions to support, decide how people will get answers, and use their feedback to improve the context.

Deploy Cassis to your team →