For agents
Choose the route for your task: answer a question, investigate evidence, or change the context. Use the capability matrix to select an interface.
Use the right interface
- MCP
- Ask data questions, record conversation feedback with its source, inspect project and schema state, and triage issues. MCP does not return or edit context files.
- Repository
- Read and edit the context, 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 to access Cassis services. A personal key acts as its creator; a gateway key requires the configured end-user identity. When the MCP server’s instructions say the key is scoped to one project, omit project_id and skip list_projects.
Read CASSIS_API_KEY from the environment. Never print it or put it in a prompt, file, commit, issue, or pull request. If a required key is missing, report which Cassis operation needs it. Continue local work that does not use Cassis services, such as preparing context changes from supplied files. Never ask someone to paste a key into chat.
Read for the task
- Answer a question: read asking over MCP, ask_question and feedback. Continue clarifications in the same chat. Finish with the answer, a requested clarification or a specific limitation; record concrete corrections with their source.
- Investigate a problem: read issue investigation and the issue tools. Inspect source-schema evidence when needed. End with a supported diagnosis or the missing business decision, without assuming permission to edit.
- Change the context: read the Git procedure, the checkout’s
cassis/AGENTS.mdand evals. Use expansion to cover another business area, or the bootstrap kit to assemble a first context from local sources. Keep modeling doctrine in the local guide. Leave a verified pull request unless further actions are authorized.
Machine-readable navigation is at /llms.txt. Guide and reference pages also have /raw/<path>.md; for example, /curate/agent is available at /raw/curate/agent.md. The home is /raw/index.md. The filterable changelog has no raw copy.
Stop at the authorized boundary
Before editing, read the checkout’s publishing configuration. For a bound Cassis project, check its live status when access is available. A null git_sync means no GitHub App binding; a custom CI publisher may still own publication. If access is unavailable, continue with a local draft. Establish the publishing workflow and check live state before publication.
For context changes, default to a pull request. Merge only when the repository owner explicitly authorizes it after required checks pass. With the connected GitHub App, PR mentions resolve after successful publication. Other CI publishers need explicit closure or their own automation. A merge is not proof of publication, so confirm the live version with get_project_status or cassis status.
Never publish from the app or run context upload against a repository the GitHub App already syncs.
For an issue fix, verify the answer in a new conversation after publication before resolving any still-open issue.
Start a session
For work connected to a Cassis project, configure the coding agent once. Local bootstrap and expansion can start from your files without a Cassis account. Describe the change you need and provide its business sources:
Drafts and checks a change for review.