Skip to content
XADEN

Developer Guide

Add Xaden to a repository

Put Xaden beneath a repository you already have, without changing its build, its tests, its documentation or its CI. The result is one pull request that your team reviews.

Before you start

  • Xaden is installed (Install Xaden).
  • You work in a clone of the repository, and it has at least one commit or is empty.

Adopt the repository

cd ~/code/shop
xaden adopt
  • xaden adopt: reads the repository and reports its stack, test runner, linters, CI system and git hooks. Then it prints exactly which files it would create or touch and asks once.

On a yes it works on a new branch, chore/adopt-xaden, in its own folder next to the repository (shop-adopt-xaden), so nothing lands on your default branch. When it is done, push the branch and open the pull request. If gh is installed, Xaden offers to do both.

Check that it worked: in the new folder, xaden check ends with OK: all checks passed, or with a warning that names every skipped check.

Look first, change nothing

xaden adopt --scan
xaden adopt --plan
  • xaden adopt --scan: reports what the repository has and changes no file. It also lists rules in an existing AGENTS.md or CLAUDE.md that contradict xaden/RULES.md, with file and line. You decide what to do about them.
  • xaden adopt --plan: prints the exact diff and the list of files that would be created or changed, and writes nothing.

What Xaden cannot recognise it says so, and it never guesses a command. Name one yourself with --check test="make verify". Without a terminal (a script, a CI job) xaden adopt stops after the plan and prints the command that applies it: xaden adopt --yes.

What it adds, and nothing else

  • A visible folder xaden/ with xaden.conf (the pinned Xaden version and checksum, the mode of the checks and the commands Xaden runs), RULES.md (the rules for assistants, generated from the pinned version: do not edit), requirements/, personas/, security-reviews/, baselines/, an optional prompts/ and footprint.txt. It is plain Markdown plus one settings file.
  • A short marked block in AGENTS.md. Text you wrote there stays untouched.
  • Slash commands for the assistants your team uses, one file for each prompt and nothing else: Claude Code .claude/commands/<name>.md, GitHub Copilot .github/prompts/<name>.prompt.md, Mistral Vibe and Codex CLI .agents/skills/<name>/SKILL.md (one skill that both read). Xaden offers an assistant when it finds a file or folder of its own (.claude/, .github/copilot-instructions.md or .github/prompts/, .vibe/, .codex/); --assistants claude,copilot,vibe,codex answers in advance. A file of the same name that exists already stays as it is.
  • For Claude Code users, CLAUDE.md with the single line @AGENTS.md, or that line added to an existing CLAUDE.md that lacks it. Xaden pre-selects Claude when it finds CLAUDE.md or .claude/ and asks you to confirm; --assistants claude answers in advance.
  • A separate workflow, .github/workflows/xaden.yml, in its own commit. It installs the pinned Xaden version and verifies its checksum. Your existing workflows are not edited. --skip-ci leaves it out.
  • Xaden’s checks in your git hooks, chained into the hook manager you have (see Hooks and CI that do not fit).

Your README.md, docs/, scripts/, CHANGELOG.md and build files are never changed.

Your own tools keep running

The scan maps the commands it finds (npm test, make lint, pytest, ruff check . and similar) to check.test, check.lint and check.typecheck in xaden/xaden.conf, and xaden check runs them. Xaden’s own language presets stay unused.

Existing findings never block your team. When the plan is applied, Xaden runs your check commands once and records what they report. How strict the checks are from then on is explained in Check modes and baselines.

Hooks and CI that do not fit

Xaden chains into husky, plain git hooks, pre-commit and lefthook, and keeps what your hooks already do. It never sets core.hooksPath over a manager. husky hooks are files in the repository, so that step is its own commit. The others live inside .git, so each teammate runs xaden setup once after cloning.

A hook manager or CI system outside this list stops the run with exit code 4 and a manual step. Adopt without that part with --skip-hooks or --skip-ci.

Take it out again

xaden remove
  • xaden remove: deletes xaden/ and undoes exactly the paths listed in xaden/footprint.txt. Review the result with git status, then commit.

xaden ignore-list prints xaden/, AGENTS.md and, when present, CLAUDE.md, one per line, for .dockerignore, .npmignore and archive excludes.

A project with its own copy of the tooling

A project created with xaden create --classic (it has a .scaffold/ folder) moves to this layout with the same command. Its requirements, personas and reviews move into xaden/, the copied files you did not edit are removed, and the ones you edited stay and are listed.

Working with assistants afterwards

Claude Code, GitHub Copilot and Mistral Vibe users get a slash command for each prompt (/kickoff, /feature, /bugfix and so on), and Codex CLI users a skill they start with $kickoff, $feature and so on. Each one only tells the assistant to run xaden prompt <name>; a file of the same name that exists already stays as it is. Other assistants run xaden prompt kickoff, xaden prompt feature and so on to print the task prompt. A prompt of the same name in xaden/prompts/ replaces the default for all of them. Copilot prompt files work in VS Code, and Vibe reads project skills only from a folder you marked as trusted.

Next

Check modes and baselines, then Kick off with your assistant.

These pages describe Xaden v0.3.0, released 2026-10-17.