Add Augment (Auggie) as a supported agent
TL;DR: Add Augment/Auggie as a full agent target. It has a fixed, always-read config (.augment/settings.json) for both MCP and hooks, so it fits the existing targets/definitions/*.ts pattern. Already implemented and validated on a branch.
What it does
| Aspect |
Augment |
| Config dir |
.augment |
| MCP file |
.augment/settings.json (JSON, shared) under mcpServers |
| Hooks file |
.augment/settings.json (same file) under hooks, Claude schema |
| User scope |
~/.augment/settings.json |
| Skills |
native .agents/skills/ (no symlink) |
| Subagents |
not supported |
| Env-ref syntax |
${VAR} (same as Claude) |
Why it's not a skills-only case (cf. Pi, #78 / #25)
The bar from the Pi discussion: an agent earns a full definition only if it has a well-known, fixed config path the tool always reads. Otherwise .agents/skills/ already covers it with zero code.
|
Pi (rejected) |
Augment |
| Fixed MCP config path |
no |
yes (~/.augment/settings.json, always read) |
| Hooks |
no |
yes (Claude schema, same file) |
| Needs more than skills |
no |
yes |
Skills are already handled natively, so this request is specifically about MCP + hooks.
Two implementation notes
1. Merge-safety. settings.json also holds sibling keys (model, indexingAllowDirs, hooks). The writer merges mcpServers into the existing file without clobbering them. This is the same shared: true reconcile path already used by OpenCode and Codex.
2. Explicit transport type. Auggie requires type: "stdio" for command servers and type: "http" for URL servers (verified against the CLI).
The adapter itself is a small definition reusing existing helpers (httpServer, envRecord, serializeClaudeHooks), plus wiring in registry.ts / paths.ts, tests, and doc updates.
Validation
auggie mcp list reads the generated .augment/settings.json natively (stdio + http).- Re-running install is merge-safe and idempotent: sibling keys and user-added servers are preserved.
- Full check suite passes, including new tests.
Ask
Would you accept a PR for this? Happy to match any conventions I've missed (naming, docs surfaces, QA via skills/dotagents-qa).
Add Augment (Auggie) as a supported agent
TL;DR: Add Augment/Auggie as a full agent target. It has a fixed, always-read config (
.augment/settings.json) for both MCP and hooks, so it fits the existingtargets/definitions/*.tspattern. Already implemented and validated on a branch.What it does
.augment.augment/settings.json(JSON, shared) undermcpServers.augment/settings.json(same file) underhooks, Claude schema~/.augment/settings.json.agents/skills/(no symlink)${VAR}(same as Claude)Why it's not a skills-only case (cf. Pi, #78 / #25)
The bar from the Pi discussion: an agent earns a full definition only if it has a well-known, fixed config path the tool always reads. Otherwise
.agents/skills/already covers it with zero code.~/.augment/settings.json, always read)Skills are already handled natively, so this request is specifically about MCP + hooks.
Two implementation notes
1. Merge-safety.
settings.jsonalso holds sibling keys (model,indexingAllowDirs,hooks). The writer mergesmcpServersinto the existing file without clobbering them. This is the sameshared: truereconcile path already used by OpenCode and Codex.2. Explicit transport
type. Auggie requirestype: "stdio"for command servers andtype: "http"for URL servers (verified against the CLI).The adapter itself is a small definition reusing existing helpers (
httpServer,envRecord,serializeClaudeHooks), plus wiring inregistry.ts/paths.ts, tests, and doc updates.Validation
auggie mcp listreads the generated.augment/settings.jsonnatively (stdio + http).Ask
Would you accept a PR for this? Happy to match any conventions I've missed (naming, docs surfaces, QA via
skills/dotagents-qa).