For agents
Use MCP to inspect and ask, the CLI to verify, and a repository checkout to change a git-managed ontology. Default to leaving a pull request for review.
Use the right interface
- MCP
- Ask data questions, inspect project and schema state, and triage issues. MCP does not return or edit ontology files.
- Repository
- Read and edit the ontology, then open a pull request. Follow
cassis/AGENTS.mdin the checkout. - CLI
- Pull, format, validate, test, run evals, and confirm publication. Use the CLI reference for exact behavior.
- Web app
- Inspect evidence and versions. Edit only when the project is app-managed.
The capability matrix distinguishes what is technically possible from the supported workflow.
Authenticate safely
Any compatible interactive MCP client can use browser OAuth. Headless agents, the CLI, and CI use an API key that acts as the person who created it.
Read CASSIS_API_KEY from the environment. Never print it or put it in a prompt, file, commit, issue, or pull request. If it is missing, stop and report that instead of asking someone to paste it into chat.
Read in this order
- How the curation loop works.
- Curate a git-managed project.
- Capability matrix.
- The relevant MCP, CLI, or ontology schema reference.
Machine-readable navigation is at /llms.txt. Every page also has /raw/<path>.md; for example, /curate/agent is available at /raw/curate/agent.md.
Stop at the authorized boundary
Default to a pull request. Merge only when the repository owner explicitly authorizes it after required checks pass. A merge is not proof of publication: confirm the live version with get_project_status or cassis status. Resolve the issue only after that version contains the fix. Once it does, propose the resolve and name the issue id: closing the loop is the last step of the work, not an optional extra.
Never publish from the app or run ontology upload against a repository the GitHub App already syncs.
Start a session
Use before assigning ontology work.