# Curate a git-managed project

The repository is the editing surface: read the evidence, change the ontology, prove the behavior, review the pull request, and confirm publication before closing the issue.

\[Illustration: An agent reads a detected issue over MCP, fixes the ontology files in the repository checkout, verifies it with the CLI, and opens a pull request. An authorized merge publishes a new version, and the agent marks the issue resolved.\]

Before starting, the project needs a [connected repository](/build/git-connect/), the [Cassis CLI](/build/cli/), and access to the issue through the Review screen or [MCP](/reference/mcp/issues/). For an app-managed project, use [Curate in the web app](/curate/web-app/).

## 1\. Read the issue

Choose the prioritized open issue, then read every occurrence. Check the question, symptom, diagnosis, and any correction the user supplied. Use the full source evidence when the right fix is not obvious.

An `ontology_gap` needs a definition or relationship. `missing_data` usually means modeling another source table. Do not rewrite a description when the data itself is absent.

## 2\. Change the ontology

Create a normal feature branch and edit the files under `cassis/`. Follow the generated `cassis/AGENTS.md` modeling guide; use the [ontology schema](/reference/schema/) for exact fields.

```bash
git switch -c ontology/fix-top-seller-ranking
```

Make the smallest change that fixes the underlying rule for every relevant question, not a special case for one prompt.

## 3\. Prove the change

```bash
cassis ontology fmt
cassis ontology check
cassis ontology test -q "the question that was failing"
cassis eval run
```

Formatting keeps the diff readable, validation catches an invalid tree, the question probe checks the intended fix, and evals catch regressions. If the question should become a regression case, include the candidate SQL and its business assumptions for a domain owner to approve.

## 4\. Open the pull request

The pull request should name the issue, quote the decisive evidence, explain the ontology change, and include the verification results. The recommended default is independent approval: an agent opens or updates the pull request and stops.

## 5\. Resolve the issue

Merging is not the last step. After merge, the GitHub App or default-branch CI job publishes the ontology. Confirm the published version, then resolve the issue that started the work:

-   After a GitHub App import, use `get_project_status` or `cassis status --watch` to match the published commit.
-   After a CLI upload, check the job and use `get_project_status` or plain `cassis status`.
-   Then `cassis issues resolve <id>`, or `update_issue_status` over MCP.

An agent that made the fix proposes the resolve and names the issue id; an editor or admin confirms it, because that is the role the status change requires. An issue nobody resolves stays in the triage queue and reads as a gap that was never fixed.

`update_issue_status` records an outcome; it does not change the ontology. Resolve only after the published version contains the fix. Dismiss issues you deliberately will not act on, and leave uncertain ones open.

## Give the task to an agent

**Prompt for an agent: Take one detected issue to a pull request**

Safe default: open the pull request and stop.

```text
Goal: fix one Cassis issue at its root cause and leave a verified pull request.

Read:
- https://docs.getcassis.com/raw/curate/agent.md
- https://docs.getcassis.com/raw/reference/mcp/issues.md
- https://docs.getcassis.com/raw/reference/cli/ontology.md
- cassis/AGENTS.md in this checkout

Do:
1. Select the prioritized open ontology_gap issue, then read every occurrence and any needed source evidence.
2. Create a feature branch and make the smallest ontology change that fixes the underlying rule.
3. Run cassis ontology fmt, cassis ontology check, cassis ontology test for the failing question, and cassis eval run. Fix failures.
4. Propose a regression case with candidate SQL and its business assumptions when appropriate; do not approve it yourself.
5. Open a pull request naming the issue, evidence, change, and verification results.
6. If the pull request merges while you are still on the task, confirm the published version contains the fix and propose resolving the issue by id. If it does not merge, end by naming the issue id still to resolve once the fix is published.

Stop at the pull request unless the repository owner explicitly authorized merge after required checks. Never publish from the web app. Leave the issue open until the merged change is confirmed in the published version, then propose the resolve instead of leaving it open silently.
```

A repository owner can explicitly authorize an agent to merge, wait for publication, and resolve the issue. Enforce that authority with repository permissions, required checks, and credential scope; Cassis does not add a separate human-approval gate.