Generated at build time from src/core/config.ts and README.md

Configuration

Top-level keys

`capabilities`

Type	Default
array of capability ids: crg, daemon, skills, agents, cli-tool, master-prompt	required

The capabilities agemon reconciles in this repository. An empty list or an unknown id is an error.

`skill_groups`

Type	Default
string: comma-separated group ids, or all or none	interactive prompt per group, or essentials-only when non-interactive

The skill groups to install, as with –skill-groups; the flag wins when both are given.

`custom_skill_groups`

Type	Default
table of group id to custom group table	no project-defined groups

Project-defined skill groups. A group id is lower-case letters, digits and ‘-’ (at most 40 characters), not all or none, and not a built-in group id.

`conflict_decisions`

Type	Default
table of resource id to decision: keep, replace, skip	every conflict needs a decision in the run

What to do with a rule file that holds your own rules where agemon would write a pointer.

`known_capabilities`

Type	Default
array of capability ids: crg, daemon, skills, agents, cli-tool, master-prompt	the capabilities agemon had before this key existed

The capabilities the agemon that wrote the file knew about, so a capability added in a later release is offered once.

Custom skill group tables

`label`

Type	Default
string, one line, at most 80 characters	required

The name shown when agemon asks which groups to install.

`skills`

Type	Default
array of 1 to 50 skill entries	required

The skills in the group, each a local or a GitHub source.

Custom skill entries

`source`

Type	Default
string: “./<path>” or “github:<owner>/<repository>”	required

A directory in this repository (the skill’s name is the directory name), or a GitHub repository.

`ref`

Type	Default
string: a full 40-character commit sha	required

The commit to fetch; branches, tags and short shas are refused. Only for GitHub sources.

`skill`

Type	Default
string: a skill name	required

The skill to take from skills/<skill>/ in the repository. Only for GitHub sources.

`agemon.toml`

The first successful run writes agemon.toml at the repository root; commit it so teammates and CI reconcile the same way. It accepts exactly these keys. An unknown key, an unknown capability id, or an empty capabilities list is an error, never a silent fallback:

capabilities = ["crg", "daemon", "skills", "agents", "cli-tool", "master-prompt"]
known_capabilities = ["crg", "daemon", "skills", "agents", "cli-tool", "master-prompt"]
skill_groups = "essentials,security"   # optional

[custom_skill_groups.house-style]      # optional — see Project-defined skill groups
label = "House style"
skills = [{ source = "./tools/skills/house-rules" }]

[conflict_decisions]                   # optional
"rule-file:CLAUDE.md" = "keep"         # keep | replace | skip

known_capabilities lists the capabilities the agemon that wrote the file knew about. When a later release adds a capability that existing repositories should get (so far only agents, and only when skills is listed), agemon includes it in the run and then adds it to capabilities once, rewriting agemon.toml. All values are kept, but comments and layout are not; if anything like that would be lost, the original is saved under .agemon/backups/ and the message names the file. Each such rewrite keeps its own saved original; a later one never overwrites an earlier one. The rewrite happens only in an interactive or --yes run that did not roll back, and never with --dry-run, --only or agemon plan. To opt out, remove the capability from capabilities afterwards; because it is now in known_capabilities, agemon does not add it again. Older agemon releases reject a file with known_capabilities or agents, so upgrade agemon in CI before committing it. The rewrite is skipped while /.agemon/ is not git-ignored, and a full agemon nuke deletes .agemon/, including that saved original.

A conflict is a rule file that holds your own rules where agemon would write a pointer. It needs a decision. --yes never picks one for you, so record it under conflict_decisions:

keep and skip apply in any session;
replace applies with --yes (so a committed replace overwrites that pointer file in --yes runs; agemon backs up the original first), and is asked again in an interactive terminal;
without a decision, a non-interactive run exits 2 (see below).

Exit codes

Code	Meaning
`0`	Success, nothing to do, preview only (`--dry-run`, or a first run without consent), or you declined.
`1`	Error, or the apply failed and was rolled back.
`2`	Drift found, consent was missing (operations or conflicts pending in a non-interactive run), or the apply finished but verification found problems.
`130` / `143` / `129`	Interrupted by SIGINT / SIGTERM / SIGHUP (see Interrupted applies).

agemon status exits 2 when it finds a problem in a repository where agemon has state (a ledger or an interrupted apply). In a repository agemon never touched, it reports what it sees and exits 0. An invalid agemon.toml is always reported, and status then exits 2; inspect reports it too (configError in --json) and still exits 0.

If git ls-files cannot run (git missing, or “dubious ownership” in a CI container), status, inspect and install print could not check whether .agemon/ is tracked by git. This is a warning only, and it does not change the exit code.

Whether /.agemon/ is git-ignored is decided by git itself (git check-ignore --no-index .agemon/), so a later !.agemon rule in .gitignore counts as not ignored. Inside a repository where git cannot answer, agemon treats .agemon/ as not ignored: an interactive run asks before adding /.agemon/ to .gitignore, a non-interactive run without --yes stops, and the git error is printed as could not ask git whether .agemon/ is ignored: … (in inspect --json it is part of isolation.trackingCheckError).

Before installing code-review-graph or its daemon, agemon reads the repository’s own git configuration (.git/config, config.worktree, .gitmodules, and the same files of populated submodules) and checks every key against a short allowlist of settings that cannot name a program. If any key falls outside it, the install goes to a separate trust gate that lists every such key and value (secrets redacted):

interactively, you approve or decline that gate like any other;
--yes alone does not approve it: the operations are skipped with the keys listed, and the run exits 2;
--yes --trust-repo-git-config approves it for that run only (the keys are still printed). The flag is never read from agemon.toml or any file in the repository, so a repository cannot opt itself in; read the printed keys before you pass it.

More than 20 such keys, keys that cannot be shown safely, and a git configuration agemon cannot read are always skipped, with no override. On an existing install, status shows the keys as needing attention and exits 2, and a daemon unit written before these safeguards is reported until you run agemon nuke --only daemon, then agemon --only daemon.