Triage issues
The workflow guides take one issue to a fix. Triage comes first: go through the queue and decide which issues deserve a fix, which to dismiss, and which to leave open.
Open the queue
Issues from chats with Cassis and submitted feedback appear once Cassis analyzes them; failing evals and dbt changes file theirs directly. With a connected assistant, only the questions, replies and feedback sent to Cassis are available for analysis. The queue is ranked by priority, then impact.
In a git-managed project:
List the open Cassis issues and recommend, for each, whether to fix it, dismiss it, or leave it open.3 open issues.
| Issue | Recommendation |
|---|---|
| No agreed definition of “active customer” unreliable_answer | Fix: the owner of customer reporting can decide the rule |
| Slack question on active customers stopped on the same term | Dismiss as duplicate of the first |
| Refund rate: no data records a refund no_answer | Leave open: no returns data in the warehouse yet |
Want me to dismiss the duplicate?
Agent runs: list_issues (MCP); get_issue_evidence (MCP)
Agent: 3 open issues. No agreed definition of "active customer" (unreliable_answer): fix, the owner of customer reporting can decide the rule. Slack question on active customers stopped on the same term: dismiss as duplicate of the first. Refund rate, no data records a refund (no_answer): leave open, no returns data in the warehouse yet. Want me to dismiss the duplicate?
Commands: over MCP, list_issues and get_issue_evidence; from the CLI, cassis issues list and cassis issues evidence. If people asked questions since the last analysis, cassis issues analyze (editor or admin) runs it now.
In an app-managed project:
Open Review for the project. If people asked questions since the last analysis, choose Analyze conversations (editor or admin) to run it now.
Reach, in Review and as reach_count over MCP, counts the chat answers that used an affected table in the last 30 days: how exposed the issue is, not how many answers were wrong.
Decide, issue by issue
Read every occurrence first: the question, what went wrong, the diagnosis, and any correction the asker gave. Then, for the queue above:
- Fix
- “Active customer” has no agreed definition. A definition is missing and its owner can decide it, so take it through the Git or app workflow.
- Dismiss
- The Slack question is the same gap: dismiss it as a duplicate. The other reasons are invalid (the evidence is wrong), irrelevant (not a context matter) and declined (you choose not to act). The history stays.
- Leave open
- “Refund rate” has no data behind it. Leave it open until the warehouse has a returns table and someone adds it to the context (source changes).
When the evidence allows several meanings, the owner of that definition decides; permission to edit a domain does not make someone its owner. An execution failure, such as a timeout, needs a connection or query fix rather than a context change.
Record a dismissal
In a git-managed project:
Dismiss the Slack issue as a duplicate of the active customer one.Commands: update_issue_status over MCP with status: dismissed and reason: duplicate, or cassis issues dismiss <issue-id> --reason duplicate (editor or admin). The other reasons are invalid, irrelevant and declined.
In an app-managed project:
In the issue, choose Dismiss, then Duplicate (editor or admin), and add a note if the reason alone does not say enough.
After the fix
Each workflow guide ends by closing its issue once the published version carries the fix. A resolved issue reopens if new evidence shows up against a later version. A dismissed issue stays dismissed and flags the recurrence.