[ AxiomCore · Documentation ]
AI coding agents
Give an AI coding agent current AxiomCore docs, exact tool versions, a small task and checks it can run.
Give an AI coding agent what you would give a new teammate: current tool versions, the relevant contract, a small goal and a way to check the result. Require it to report what it actually ran separately from what it assumed.
1. Point the agent at the right documentation
| Resource | Use |
|---|---|
/llms.txt | Reading paths and the full page index |
/agents.json | Structured index: canonical URLs, page types, test versions where a page declares them, and redirects from old URLs |
/docs/<page>.mdx | Plain Markdown for one page, with code, tables, status notes and Mermaid source |
/llms-full.txt | The complete public corpus, when broader context is needed |
| Support and availability | Capability, framework, target and distribution limits |
For example, /docs/database/contracts.mdx is the text version of the
database contracts page. Use canonical pages; old URLs may redirect after a
reorganization.
2. Inspect the project before changing it
axiom --version
axiom doctor --json --strictHave the agent read project instructions, manifests, existing source and dependency locks. Decide whether the task is existing-code integration, Acore authoring, a database change or a deployment. Do not let it infer installed host or SDK support from a syntax example.
3. Give it checks with machine-readable output
| Command | What it returns |
|---|---|
axiom check <file> --json | A validation report, including on failure |
axiom explain <file> | The expanded backend contract as JSON |
axiom explain --schema | The machine-readable declaration catalog |
axiom diff <old> <new> --format semantic | Semantic changes between two sources |
axiom inspect overview <dir> --format json | Discovered application facts and verification state |
axiom ui context <source> | Compact, compiler-checked context for an Acore UI module (Acore UI is Alpha) |
axiom ui ai-check --base <revision> <source> <proposed> | Validates a proposed UI replacement without writing it |
The <command> --help output of the installed CLI and the exact language
reference are the authority for flags and syntax. Do not let the agent invent
flags or API names.
For Acore UI projects, the semantic service (a preview) lets an MCP client find nodes, discover legal edits and apply compiler-checked changes with a receipt, instead of rewriting files.
4. Make the task concrete
A useful task states the outcome, the files the agent owns, the exact target, constraints, a verification command and the expected result:
Add optional task notes to this local SQLite task application.
Read its manifests, schema, backend models, and frontend first.
Use the database migration and typed persistence guides.
Preserve existing titles and endpoint identities.
Check the contract and test create, read, and restart persistence.
Report the exact tool versions, commands, observed results, and limitations.
Do not publish or change a remote database.5. Verify the change
- Review the semantic diff and dependency locks. A code edit is not a verified contract change.
- Run one successful request plus the relevant validation, authorization and failure cases.
- For database work, check migration risk and history on a disposable target first.
- Use the Inspector for application relationships and change impact.
- Keep credentials and private contracts out of prompts, screenshots and logs.
A compile check, a mock, a browser simulation and a real persisted application prove different things. Ask the agent to state which one ran. A Coming soon product has no supported runnable workflow, even if a model suggests one.