Curate a git-managed project

Work in the project’s checkout. Your agent needs the Cassis CLI and the Cassis MCP server; the repository needs a publisher, the GitHub App or a CI job.

For a new working folder, set up your coding agent once. Continue the steps below in the same agent conversation so it can use the evidence and decisions already discussed.

Each step shows what to ask your agent, what it does, and the commands behind it. Start from an issue you chose to fix in triage; with no issue behind the change, such as a new metric the business just agreed, start at step 2. For an app-managed project, follow the web app workflow.

1. Read the issue’s evidence

Show me what Cassis proposes for the active customer issue and the evidence behind it.

Commands: over MCP, get_issue and get_issue_evidence; from the CLI, cassis issues show and cassis issues evidence.

An issue with several occurrences lists each one the same way; read them all before deciding.

2. Agree the rule, then write it

The asker’s reply is evidence, not a decision. Here the owner confirms the rule: customers with at least one delivered order placed in the last 90 days. For this historical dataset, measure the window from its latest order purchase timestamp.

The owner confirmed that proposed rule. Apply the fix on a new branch and show me the changes.

The agent creates the branch context/define-active-customers (branch names starting with cassis/ are reserved for Cassis) and writes one file:

name: active_customers
display_name: Active customers
description: Customers with at least one delivered order placed in the last 90
  days of this dataset. Use the latest order purchase timestamp as the reference
  date. Count people by CUSTOMER_UNIQUE_ID; CUSTOMER_ID changes with every order.
domain_path: marketplace/measuring-sales
expression: COUNT(DISTINCT "CUSTOMER_UNIQUE_ID")
filters: STALLORA.ORDERS.ORDER_STATUS = 'delivered'
  AND STALLORA.ORDERS.ORDER_PURCHASE_TIMESTAMP >= DATEADD(day, -90,
  (SELECT MAX(ORDER_PURCHASE_TIMESTAMP) FROM STALLORA.ORDERS))
  (requires JOIN CUSTOMERS.CUSTOMER_ID = ORDERS.CUSTOMER_ID)
synonyms:
- active customer count
- currently active customers
table_name: CUSTOMERS
table_schema: STALLORA
unit: customers

Commands: none from Cassis; the file follows the metrics format.

When the evidence shows missing data instead, as for the refund rate, no rule fixes it: the data has to reach the context first (source changes).

3. Test the change

Check the context, test it with "How many customers are currently active?", run the eval cases, and show me the SQL.

SELECT COUNT(DISTINCT c.CUSTOMER_UNIQUE_ID) AS active_customers
FROM STALLORA.CUSTOMERS c
JOIN STALLORA.ORDERS o ON o.CUSTOMER_ID = c.CUSTOMER_ID
WHERE o.ORDER_STATUS = 'delivered'
  AND o.ORDER_PURCHASE_TIMESTAMP >= DATEADD(
    day, -90,
    (SELECT MAX(ORDER_PURCHASE_TIMESTAMP) FROM STALLORA.ORDERS)
  )

Commands: cassis context check, cassis context fmt, cassis context test, cassis eval run.

A passing check means the files are valid, not that the rule is right. Read the SQL: it should count distinct CUSTOMER_UNIQUE_ID values for delivered orders placed in the 90 days ending at the dataset’s latest order purchase timestamp. The test question rewords the original, so a pass is not an echo, and the eval cases catch regressions. Nothing here publishes.

4. Open the pull request

The Resolves <issue-id> line in the description is what lets the GitHub App close the issue once the fix is published.

Open a pull request for this fix with the issue, evidence and test results.

Commands: Git, your host’s pull request tool, and cassis issues show for the Resolves line.

A teammate reviews and merges it; your repository’s permissions and required checks are the approval gate.

5. After merge

Publishing is automatic: the GitHub App imports the merged commit, or your default-branch CI job runs cassis context upload. With the App, the Resolves line then closes the issue on its own. With a CI publisher, the issue stays open until someone resolves it. Either way, confirm the new version is live:

The pull request is merged. Check that the fix is published and verify the active-customers answer in a new conversation. If it checks out, resolve the issue if it is still open.

Commands: cassis status, ask_question over MCP, then update_issue_status over MCP or cassis issues resolve --published (editor or admin). cassis status --watch waits for the publish of the local HEAD, so run it from a checkout of the merged commit.

Once the owner validates the new answer’s SQL, save it as an eval case so a later change cannot break it. If the change makes answers worse, roll it back.

Hand over the whole task

To hand over the investigation, change and tests together, name the issue: