AGENTS.md and rules
The commander's behavior is markdown in your project, not code in the binary, a short always-on core in AGENTS.md or CLAUDE.md, and skills.
Your AGENTS.md or CLAUDE.md
vx init writes the commander core into your project's AGENTS.md, or into its CLAUDE.md when the project has no AGENTS.md, inside a block it manages (the slot). The file is yours; only what sits between the markers is vexillum's.
This is the product's central design decision: the commander's intelligence is markdown, the binary is plumbing.
What goes where
| Where | Always loaded | Subject |
|---|---|---|
Slot (in AGENTS.md or CLAUDE.md) | yes | Role check, vocabulary, authority, tone, and one hard instruction: load the vexillum skill before any operational step. |
vexillum skill | on demand | Dispatching a soldier (always vx dispatch, never the commander's own subagent tool), choosing a model and effort, landing, shipping, striking, and the sentinel. |
models.json | read by vx models | The values for each model and effort profile. |
Splitting them keeps the always-on cost small: the commander pays for the detail only at the moment it dispatches, lands, ships or strikes. The risk of any on-demand design is that the model forgets to load the detail, which is why the slot carries that one instruction as a hard rule.
Choosing a model and effort
The choice is data in models.json: the commander runs vx models, reads each profile's when line, picks the one that fits and dispatches with --profile. Which profile fits a task is judgment, which stays in markdown; the model and effort values are yours to edit. vexillum validates the values but never picks them.
Editing and upgrading
- The slot is protected by a hash: if you edit inside it,
upgradeshows you the diff and does not overwrite it without--force. See The AGENTS.md slot. - The skills are refreshed by
upgradeand an edited one is reported, not replaced. See Skills. models.jsonis yours:initnever overwrites it andupgradenever touches it.