# Build and publish your first context

Have your agent draft the context for your question. You review the definitions before publishing.

**Git-managed is the recommended default**: your coding agent edits files in a repository. Choose App-managed to edit in Cassis instead.

## 1\. Prepare your workspace

In a git-managed project:

Open your coding agent in an empty folder. Create an [API key](/setup/api-keys/) from your account menu; configure it privately when the agent asks.

**Prompt for an agent: Set up my Cassis project**

Configures this folder and coding agent for future context edits.

```text
Set up this folder to edit context for Cassis project <project name or URL>, using https://docs.getcassis.com/raw/build/cli.md.
Make the project's context, schema and Cassis modeling guide available to this coding agent. Confirm when the setup is ready.
```

**Commands behind this step**

The CLI reads `CASSIS_API_KEY` from the environment where it runs. [Authentication instructions](/build/cli/#authenticate) include a hidden terminal prompt; an agent started elsewhere needs the key in its own environment.

```bash
python3 -m venv .venv
source .venv/bin/activate
python -m pip install "cassis-cli~=3.1"
cassis version
# Only if this folder is not a repository:
git init
cassis projects list
cassis context pull --project <project-id>
cassis schema pull
```

Expect `cassis/project.yml`, `cassis/AGENTS.md` and `cassis/.schema.json`. Keep supporting documents outside `cassis/`; the CLI excludes the schema snapshot from Git.

Configure the agent to use the generated modeling guide for future edits. For Claude Code, a root `CLAUDE.md` can [import it](https://code.claude.com/docs/en/memory#import-additional-files) with `@cassis/AGENTS.md`. Use your agent’s project-instruction mechanism for other clients. Keep that configuration outside `cassis/` and confirm the guide is available before drafting.

In an app-managed project:

On **Schema**, select your first table and choose **Model with assistant**. Use one domain for the business area, then add the other table. Have your question and supporting documentation ready.

## 2\. Draft and review the context

Fill in your question, tables and existing source files.

In a git-managed project:

**Prompt for an agent: Draft my first context**

Creates a local draft for you to review before publication.

```text
Build the context needed to answer <your question>, using <your chosen tables> and <available source files>.
Ask me about missing business definitions. Check the draft and show me the changes before publishing.
```

**Commands behind this step**

```bash
cassis context fmt
cassis context check
git diff -- cassis
git status --short
```

Your agent also shows newly created files, which do not appear in `git diff` until staged. Format and check use the Cassis API; they do not publish the context. Structural checks do not confirm business meaning.

In an app-managed project:

Give the context Assistant your question, table names and supporting definitions or SQL. Ask it to propose the context and identify missing business rules. Inspect the proposal in **Unpublished changes**.

Check what each row represents, that the join does not multiply amounts, and that the calculation, filters and dates match your question.

## 3\. Publish the reviewed context

In a git-managed project:

**Prompt for an agent: Publish my reviewed context**

Publishes the reviewed context to your project.

```text
Publish this reviewed context using the project's publishing workflow, then confirm the new version is live.
```

**Commands behind publication**

For a new project without GitHub App or CI publication, the agent checks and commits the reviewed context, then uploads it. If publishing is already configured, use the [existing Git workflow](/curate/agent/).

```bash
cassis context fmt
cassis context check
git add -- cassis
git diff --cached -- cassis
git commit --only -m "Publish reviewed Cassis context" -- cassis
cassis context upload
cassis status --watch
```

The first upload publishes version 1. Each upload replaces the whole context with the committed files. A local repository is enough.

In an app-managed project:

In **Versions**, review the unpublished changes and choose **Publish**. Check that version 1 is published.

Your first published version is ready for [asking and checking your question](/start/first-questions/).