Configurability

Everything ships as files in your repo — markdown agents, markdown skills, JSON config. Change what you need, from CLI commands to source-level edits. The parts that make verification work are fixed by design.

#CLI-supported settings

Settings the CLI manages for you. Change them with commands or ana.json edits — both survive ana init.

Remove any field with ana config delete <field> — useful for clearing overrides and reverting to detected defaults.

Surface management

If the scan missed a surface, add it manually with its path and commands:

ana config set surfaces.api.path "apps/api"
ana config set surfaces.api.commands.test "cd apps/api && pnpm test"
ana config set surfaces.api.commands.build "cd apps/api && pnpm build"

If the scan detected a false surface — an example app, a template package — remove it:

ana config delete surfaces.example-app

On re-init, the scan refreshes detected surfaces: new workspace packages with deployment indicators are added, and packages that no longer exist are silently dropped. Surfaces you added manually are preserved — but if the path doesn't exist on disk, init prints a warning. Surfaces you deleted manually stay deleted unless the scan re-detects them.

The path, language, and framework fields on each surface are machine-managed — ana config set blocks writes to these fields because incorrect values would cause agents to misidentify your stack. Override commands freely; leave detection fields to the scan.

What ana.json looks like

{
  "branchPrefix": "feature/",
  "coAuthor": "Ana <build@anatomia.dev>",
  "artifactBranch": "main",
  "commands": {
    "build": "pnpm run build",
    "test": "pnpm test -- --run",
    "lint": "pnpm run lint"
  },
  "custom": { "teamId": "anatomia" }
}

User fields (branchPrefix, coAuthor, artifactBranch, commands, custom) are yours. Machine fields (anaVersion, lastScanAt, language, framework) refresh on ana init. Unknown top-level keys you add are preserved across re-init.

#Edit the files

The system is markdown in your repo. You own it.

Skill rules

Every skill has four sections. Detected refreshes on init. Rules, Gotchas, Examples are yours — preserved across re-init. The next pipeline run picks up changes through Plan's Build Brief.

Create a custom skill

# Create a domain-specific skill
mkdir -p .claude/skills/billing
cat > .claude/skills/billing/SKILL.md << 'EOF'
---
name: billing
description: "Stripe integration, subscription lifecycle, webhook handling."
---
# Billing

## Rules
- Always verify webhook signatures before processing
- Use idempotency keys on all payment mutations

## Gotchas
## Examples
EOF

Wire a skill to an agent

Each agent declares which skills it loads in frontmatter. Plan loads [coding-standards, testing-standards]. Build loads [git-workflow]. Verify loads [testing-standards, coding-standards]. Add your skill to the agent that should know about it:

# .claude/agents/ana-plan.md
---
name: ana-plan
model: opus[1m]
skills: [coding-standards, testing-standards, billing]
---

Context files

project-context.md (architecture, domain vocabulary) and design-principles.md (how your team defines "good") in .ana/context/. Edit freely. Think, Plan, and Learn read them on every startup. Copied wholesale on re-init — your edits are always safe.

Agent templates

The six agent files in .claude/agents/ are yours to edit. Adjust Verify's disposition, add constraints to Build, modify Think's scoping process. Copied on ana init, not symlinked — edits persist across re-init.

#Going further

It's open source. Everything below works but isn't governed by the CLI — no validation, no re-init behavior. You're editing the engine directly.

Add a custom agent

Drop a markdown file in .claude/agents/. Claude Code picks it up. A security reviewer, a migration planner, a domain expert — any role that doesn't need pipeline integration.

# A reviewer that focuses on your API surface
$ claude --agent api-reviewer

# A migration helper for your specific ORM
$ claude --agent drizzle-migrator

Custom agents run outside the pipeline. They can read ana.json, load skills via frontmatter, and use any Claude Code tool — but they don't produce pipeline artifacts or proof chain entries. To gate work between stages, invoke your custom agent manually between Plan and Build (or any two stages). It can read .ana/plans/active/{slug}/ to inspect the spec and contract.

Store team config in ana.json

The custom namespace accepts arbitrary data and survives re-init. Nothing reads it automatically — the namespace is a convention for your own integrations. A custom agent that reads custom.slackChannel to post notifications, or custom.reviewers to tag PR reviewers — the config is there, the integration is yours to build.

{
  "custom": {
    "teamId": "anatomia",
    "slackChannel": "#eng-proofs",
    "reviewers": ["@rsmith"],
    "maxBuildMinutes": 120
  }
}

CI/CD scripting

ana config is scriptable. Set up a repo without interactive prompts:

# CI setup script
ana init --yes
ana config set branchPrefix "ci/"
ana config set coAuthor "Ana <build@anatomia.dev>"
ana config set custom.environment "staging"
ana agents model --all sonnet

Fork the CLI

The nuclear option. Anatomia is MIT-licensed. Fork to change artifact formats, contract schemas, the proof chain entry structure, or the agent independence rules. If you're doing this, you're building your own verification system on top of the engine.

#What survives re-init

Updating the CLI (npm update anatomia-cli) changes the binary only. Your installed agents, skills, and config don't change until you choose to run ana init again. When you do:

#What's fixed

Load-bearing opinions. Fixed because changing them breaks the verification guarantee.

• Five pipeline stages — Think, Plan, Build, Verify, Learn.
• Agent independence — session isolation. Verify can't read the build report.
• Contract format — YAML with typed assertions and matchers.
• Proof seal — SHA-256 hashes of every artifact.
• Artifact structure — the save commands validate format.

These constraints are what make the proof chain trustworthy. Every customization above works because these five things don't change.