One YAML persona, rendered for four coding agents

Personetta, an MIT-licensed Python CLI published on GitHub, renders a single layered YAML persona into native rules files for four coding agents: Cursor, GitHub Copilot, Claude Code and Cline. The tool installs each rendered persona in the location the target tool reads, and switches the active persona with one command.

At a glance

• Personas are assembled from reusable layers, a base role such as engineer or reviewer, then a language layer, then a task layer, merged under field-by-field strategies defined in merge-config.yaml.
• Each installation writes three files per tool, an always-on baseline, a router index of every persona and the full active recipe, with a local cache so switching never regenerates output.
• Installation targets each tool's native location, from ~/.cursor/rules/ to ~/Documents/Cline/Rules/, so a reviewer persona defined once does not have to be maintained as four hand-edited files.

Instruction files have become de facto configuration for coding agents, and the formats have diverged faster than teams can maintain them by hand. Treating a persona as a compiled artifact rather than a text file appears to be the more durable answer, since the composition layer survives when a vendor changes its rules directory. The risk is the one every abstraction carries: the tool must track four moving targets, and it likely lags whichever one changes first.

personetta install '*' --format claude writes every recipe into ~/.claude/rules/

Installation runs through pip install personetta, with pipx offered for an isolated CLI, and Python 3.11 or newer is required. The scripts directory ships convenience installers that handle PATH setup and verification: Setup-Personetta.ps1 for Windows and install-personetta.sh for Linux and macOS.

Rendered output goes to the directory each tool reads: ~/.cursor/rules/, ~/.copilot/instructions/, ~/.claude/rules/ and ~/Documents/Cline/Rules/. Install and remove both accept wildcards, so patterns such as 'test-*' or '*python*' address a batch of recipes, and personetta list shows the available roles, which cover design, implement, review and test work per language.

Switching personas uses personetta set-active with a recipe name and a format, for example set-active review-python --format claude, and personetta current prints whichever recipe is active for a given tool. Recipes are pre-generated and cached, so activation does not trigger a rebuild.

Recipes compose base roles, language layers and overrides under rules set in merge-config.yaml

Reusable role layers live in data/base, covering foundational roles such as engineer, reviewer and tester, while data/language_specific holds language and framework layers. data/recipes defines the composition itself: which layers apply, in what order, and with what overrides. Field-by-field merge strategies and conflict rules sit in data/config/merge-config.yaml.

Every YAML file is checked against JSON Schemas kept in data/schemas. The generator in src/generator loads, validates, composes and renders each recipe through per-tool formatters, then installs three files for the target tool: an always-on baseline, a router index listing every persona, and the full active recipe, alongside a local cache. The personetta recipe command prints one composed recipe for a chosen format.

The project reports 1,641 passing tests and caps source files at 400 lines

The project reports 1,641 passing tests spread across unit, integration and quality suites. Quality guards run inside pytest and enforce a cyclomatic complexity ceiling of 10, a function limit of 25 lines and a file limit of 400 lines, along with method and import count caps and workspace-convention checks.

Packaging guards build a real wheel and check that every recipe ships inside it. The codebase is linted with ruff and type-checked with mypy, and CI runs on every push. On the user side, personetta verify checks install health, covering version, PATH and recipe data, and personetta validate runs the schema check across all YAML files.

Formats beyond the current four The CLI accepts cursor, copilot, claude and cline as format values, and the repository names no other targets nor a timeline for adding them. Documentation covers quick start, user guide, core concepts, recipe authoring, CLI reference, architecture, contributing and troubleshooting. The project is credited to Edward Fry.