Issues commands

These commands work on the same queue as the Review page and the MCP issue tools. Like the other project-bound commands, the project id comes from cassis/project.yml in the checkout, CASSIS_PROJECT_ID, or --project.

issues list

Lists the project’s issues, most important first: priority (P1 to P3, then unranked), then impact, then reach, then how the issue was found (dbt findings first), then recurrence. One line per issue, in aligned columns: its id, impact, occurrence count, origin (conversation, eval, or dbt), reach, status, context domain, and title. The id is what the other issues commands take.

# The open triage queue is the default
cassis issues list

# Include open, resolved, and dismissed issues
cassis issues list --status all

# Narrow by impact or cause
cassis issues list --impact wrong_answer --cause ontology_gap

# Triage one context domain at a time (`sales` also covers `sales/pipeline`)
cassis issues list --domain sales

# Raw JSON
cassis issues list --json

Filters

--status (open, the default; resolved; dismissed; all), --impact (wrong_answer, at_risk, unreliable_answer, no_answer, inefficient), --cause (ontology_gap, missing_data), --domain (a context domain path, which covers the domains nested under it). All optional and combinable. at_risk is the impact of issues filed from dbt changes.

Reach

reach 12 counts the chat answers that used any of the issue’s context tables in the last 30 days, each answer once. It says how much the issue touches, not how many answers were wrong. reach - means not measured: the issue names no table of the context, for instance data not added yet.

Output

One line per issue, or the full records with --json, which carry origin, reach_count, reach_window_days, and detected_by.

issues show

Shows one issue in full: its diagnosis, suggested action, whether a fix proposal exists, status history, and the occurrences behind it. It also prints the issue’s reach (not measured when it names no table of the context), its evidence (removed from dbt, an AI review suggestion, user feedback, a failed eval, or the chat analysis), and for an issue filed from a dbt change, its origin: the model, column, commit, and pull request. Each occurrence’s id feeds issues evidence. A dismissed issue includes its reason and optional detail. An applied fix that is not published yet is shown as awaiting publication.

cassis issues show 019f0000-0000-7000-8000-0000000000e1

An open issue also prints a PR mention: line, Resolves <id>. Paste it into the pull request description. With the connected GitHub App, the matching issue closes after successful publication (see below). A closed issue prints Resolved via: instead: how it was closed (by a person, an applied fix proposal, a merged fix branch, or a PR mention) and the pull request it came through when there was one. --json carries the same as resolved_via and resolved_ref.

issues evidence

Prints the evidence behind one occurrence, joined back from its source: the generated SQL and its results, the agent’s process log, and either the user’s rating (a chat) or the judge’s verdict (an eval failure). Read it when the extracted fields are not enough to judge an issue.

cassis issues evidence 019f0000-0000-7000-8000-0000000000e1 019f0000-0000-7000-8000-0000000000c1

issues analyze

Analyzes the project’s chats with Cassis that nobody has analyzed yet and turns what went wrong into issues. This is the same pass as the Review page’s “Analyze conversations” button, started on demand instead of waiting for the nightly one. It runs on Cassis’s workers; by default the command waits and prints the run’s summary. Ctrl-C requests cancellation and preserves occurrences already extracted. Needs cassis-cli 1.7.

# Refresh the queue, then read it
cassis issues analyze
cassis issues list --status open

# Start it and come back later
cassis issues analyze --no-wait

# Raw JSON for a pipeline step
cassis issues analyze --json | jq .run.status

Nothing new

When every conversation is already analyzed the command is a no-op that exits 0, so a scheduled job re-running it on a quiet project stays green.

Waiting

--wait (default) or --no-wait, --poll-interval, --timeout. The run keeps going server-side if the CLI stops waiting; Ctrl-C cancels it and exits 130.

Exit codes

0 when the run completes (or there was nothing to analyze), 1 when it fails or is cancelled, 3 on transport errors, on an analysis already in flight, or on --timeout.

Role

Editor or admin, like the Review page button.

issues resolve, dismiss, reopen

Set the issue’s status: resolve once the context change that fixes it is published, dismiss for issues you deliberately will not act on, reopen to put a resolved or dismissed issue back in the queue. Status changes require the editor or admin role.

With the connected GitHub App, put Resolves <id> in the PR description to close the matching issue after successful publication. Check the published version and issue status after merge. Other providers and custom CI publishers need explicit resolve or their own automation.

cassis issues resolve 019f0000-0000-7000-8000-0000000000e1 --published
cassis issues dismiss 019f0000-0000-7000-8000-0000000000e1 --reason duplicate --detail "Covered by the billing issue"
cassis issues reopen 019f0000-0000-7000-8000-0000000000e1

dismiss requires one of four reasons: invalid, irrelevant, duplicate, or declined. Add --detail when the reason alone does not preserve enough context. resolve asks you to confirm that the fix is already published; pass --published explicitly in a non-interactive command.

Exit 1 when the issue or occurrence does not exist in the project; nothing is changed.