Working with a coding agent
llms.txtlists every page for an agent
For someone who hands SQL Yodeler's setup to a coding agent, and keeps approvals and applies for people.
Works
- One prompt that sets SQL Yodeler up in a repository and opens a pull request, and stops short of applying, approving or merging
yodel mcp: read-only tools for status, plan, lint and drift- JSON Schemas for the
--jsonoutput of each command - llms.txt and a prompt on each task page
Differs
By database
- A project owns ClickHouse databases (
yodel create <dir> --clickhouse --database <name>). - A rebuild keeps the old table until
yodel cleanupdrops it, and lint flags mutations and rebuilds (ch-mutation,ch-rebuild).
- A project owns Postgres schemas (
yodel create <dir> --postgres --schema <name>). - Roles stay the environment's: the schema declares the policies and grants that name them.
By forge
- The writer's secrets are secrets of a GitHub environment limited to
main. - The plan comment and the drift issue use the job's own token.
- The writer's variables are protected and scoped to the environment; the readers' are not protected.
- The plan comment and the drift issue need
GITLAB_TOKEN, and each drift watch runs from a pipeline schedule you create.
- Secrets belong to the repository, with no environments, so limit who can push branches.
- Jobs need a runner with the
dockerlabel, and a job gets no OIDC token for cloud roles.
First step
Hand the agent this prompt:
Set up SQL Yodeler in this repository.Read https://intentius.io/sql-yodeler/llms.txt first, thenhttps://intentius.io/sql-yodeler/agents/ and follow it.Open a pull request with the result.Never run `yodel apply` against a shared environment, never run `chant approve`, `yodel approve` or `yodel override`, never edit the `chant/lifecycle` branch or `.chant/allowed_signers`, never merge; approvals and applies belong to people.Proof
No scenario claim runs what this room describes. Claims status lists every claim.
