Regixo docs
Data catalog · engineer

Work with your agent

Most people now run Regixo by talking to the coding agent already open in their project. That changes what you do: you stop being the one who types the commands, and become the one who says what they want and checks the result. This page is the human half of the contract — the same one Regixo hands the agent when it runs regixo skill.

The agent’s copy of this page Everything below is what regixo skill tells your agent, written for you instead. Same rules, same order. If you want to read exactly what your agent was told, run it — it prints in plain markdown, and it is the source these words come from.
say

“Read Regixo’s operating playbook, then set it up for this project.”

Show the commandHide the commandShow the sentenceHide the sentence
run
$ regixo skill

Which tool you’re using

There is no plugin, no extension and no integration. Regixo is an ordinary command-line tool in your project. Your agent runs regixo … in the same shell you would — that is the whole mechanism, and it is why the list below is open-ended:

If it can run regixo help, it can operate Regixo. That is the only requirement, and we would rather say so plainly than imply a partnership that does not exist.

Don’t confuse this with the MCP server A separate, optional surface lets an assistant read your catalog and answer questions about it over MCP. That one does take a one-time registration, and it is read-only by construction — it cannot scan, correct a flag, or change the record, because no write tool exists to call. You do not need it to use Regixo. See Use an AI agent.

Your job now: specify, then verify

Two things move to you when an agent does the typing.

1 · Say what you want, not how to do it

State the goal. The agent reads Regixo’s own manifest (regixo help --json — every command, flag, env var and error code, as data) and picks the command. You do not need to know which one, and you should not have to tell it.

2 · Check the result against something Regixo says — not against the agent’s summary

An agent’s own summary of its work is not evidence. Regixo gives you honest, checkable signals; look at those instead.

How to check your agent did it right

Four signals, and none of them requires trusting the agent’s account of itself. They are the same four things regixo skill tells the agent it must report honestly — so if its summary and these disagree, believe these.

The coverage line — it names what is missing
A source that was not reached is missing from the map. This is the failure that hides: the counts still print, they are just quietly too low. So regixo status does not make you infer it — it ends on the coverage line, and the bad case names the source:
example output
  coverage:  all 2 source(s) reached
  coverage: ⚠ 1/2 sources reached — the map EXCLUDES stripe (fix: regixo doctor)
For a source-by-source view — reachability and last-scan age, one line each — regixo sources.
The counts — datasets, and columns that look like personal data
Compare them to what you expect from your own estate. A missing source shows up here first. The dashboard’s coverage meter says the same thing (“10 of 10 sources reached”).
The stamp — DRAFT means draft
A record Regixo drafted is a DRAFT. It is not official until a person signs it, and no agent can change that. If anything claims otherwise, it is wrong.
The label — suggested is not confirmed
A description or glossary term your agent wrote lands as suggested — one it drafted with its own model renders as “suggested · AI-drafted”. It is a proposal, not a settled fact, until a person confirms it.

A personal-data correction (regixo classify set) is different, and worth knowing: a flag is a mechanical fact, so there is no suggested state for one — it takes effect immediately. That is not a legal call and it is fully reversible; regixo classify list shows every override, which is exactly the set worth auditing.

One more: row counts are the database’s own estimates, never a COUNT(*). Regixo presents them as estimates and so should your agent.

The catch-all check
say

“Summarise what Regixo has connected and scanned, and what’s still missing.”

Show the commandHide the commandShow the sentenceHide the sentence
run
$ regixo status

The two lines your agent must never cross

These are not settings, and they are not politeness. Both are enforced in Regixo itself, and both are written into the playbook the agent reads.

A mechanical fact is something Regixo could in principle read: whether a column holds personal data, which datasets a flow connects, what a table is for. Your agent may set these — and its work is labelled as suggested until you agree.

A legal field is a judgment only a person may make and sign: purpose, lawful basis, retention, transfers, and the recipients of personal data. Regixo suggests these; a human on the compliance team confirms them.

So these commands carry no sentence anywhere in these docs. They are yours:

CommandWhy it is a person’s
regixo verifyIt signs and seals the record under a named human’s identity
regixo dora exportIt seals the register for a regulator under that same signature
regixo describe confirmA confirmation records a person’s decision, attributed to them
regixo glossary confirmSame — the human check that promotes a suggestion
regixo annotate set … --confirmIt marks a legal field legally confirmed
If your agent offers to sign or confirm, it is wrong The playbook tells it to stop and say why: draft the value if that helps, leave it as a suggestion, and tell you exactly which command makes it yours. An automated path that confirms a legal field is a bug in Regixo, not a shortcut your agent found.

2 · It never asks you to paste a secret into the chat

A password, token or API key never goes into the chat, a connector file, or regixo.yml. It lives in your project’s local .env (git-ignored); Regixo’s config stores only the env-var name.

The reason is concrete, not ceremonial: a secret pasted into a chat is sent to the model and kept in the transcript on disk.

So your agent does everything it legitimately can and stops at the secret. An account identifier, host, port, database, warehouse, role, project id or key-file path is not a secret — it fills those in. Then it leaves the token’s slot marked, tells you what it filled in and what it deliberately did not, and points you at the exact line in .env.

A placeholder is the correct answer, not a failure

If your agent leaves <PASTE-YOUR-TOKEN-HERE> in .env and hands back to you — that is it working. Never ask it to replace the placeholder for you, and if you offer it the secret anyway it is told not to write it down.

regixo test, regixo start and regixo doctor answer SECRET_PLACEHOLDER_UNREPLACED while the placeholder is still there. That error is a checkpoint, not a failure. It means it is your turn.

There is a third line, which you will never have to act on: your agent may read the schema, never the data (Hard Rule #2). Regixo’s scanner reads table names, column names, types, owners and lineage — it does not read, store or send row values, and the playbook tells the agent not to SELECT rows to “check” a classification either, because a sampled value in a transcript is a leak.

When your agent stops and waits — and why that is right

The playbook names the moments an agent must hand back. None of them is a failure, and knowing them means you will not push it past a line it is right to hold.

See it end to end

Running Regixo by talking follows one engineer from an empty project to a forwarded draft — every step said, not typed, with what the agent runs and what you check at each turn.