Author once, emit per tool

AmbyKit’s core design is author-once, emit-per-tool. There is exactly one neutral source of truth for the workflow — the templates and phase prompts. Per-tool emitters translate that source into each assistant’s native command/rules format. You never hand-maintain per-tool files; you edit the neutral source and run ambykit sync.

A single neutral source (src/templates + src/prompts) is translated by emitters into native files for Claude Code, GitHub Copilot (+ CLI), Cursor (+ CLI), OpenCode, and Antigravity (+ CLI).

One neutral source; per-tool emitters produce native files.

−

100%

+Fit

Close

This keeps the workflow consistent across every assistant a team uses, and makes adding a new tool a thin emitter rather than a fork of the whole workflow.

Non-destructive rules merge

Command files are AmbyKit’s alone and are overwritten. Rules files (AGENTS.md, the CLAUDE.md bridge, copilot-instructions.md, Cursor’s .mdc) may already contain your own instructions, so AmbyKit never overwrites them. It owns a single Markdown section that opens with ### AmbyKit usage and merges just that section into whatever file exists — preserving everything around it. The section carries a fingerprint so a hand-edited copy is detected and left untouched, an existing file is backed up to .amby/backups/ before any change (recover with ambykit restore), and re-running is idempotent. This is what makes AmbyKit safe to adopt in an existing (brownfield) project.