# 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](/ask/mcp/).

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.

```text
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**

```bash
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](#deploy-cassis-to-your-team). An issue is not required to complete the guide. [Investigate any unresolved error](/ask/answers/) 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.

```text
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**

```bash
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.

```text
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](/curate/agent/).

```bash
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](/curate/branches/). 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 →](/start/rollout/)**