Style Cards | Elixion Docs

A style card records how your team writes code, so that agents working in Elixion, the platform for Engineering Intelligence™, follow the same conventions you do rather than a generic default.

Style cards are configured through the Elixion API today, at /api/v1/style-cards. This page is the reference for what a card holds.

Scope

A card belongs to a project, and it declares the level it applies at:

| Level | Meaning | |-------|---------| | user | An individual's preferences | | project | Conventions for the project the card belongs to | | task | A one-time override for a specific piece of work |

The project a card belongs to is set when the card is created. Updating a card changes its name, description, configuration, status and tags; it does not move the card to another project.

Several cards can be merged into one effective configuration, with a precedence order you supply. The merge reports any conflicts it resolved.

What a card configures

A card has six sections, plus per-language overrides and free-form custom rules.

Naming

Separate settings for variables, functions, classes, constants, files and the rest. Each one takes any of the same six values:

snake_case, camelCase, PascalCase, kebab-case, SCREAMING_SNAKE, hungarian.

Formatting

Indent style: two spaces, four spaces, or tabs.
Brace placement: same line or new line, with allman and k_and_r accepted as the equivalent names.
Line length, quote style, semicolons and trailing commas.

Documentation

Docstring style: google, numpy, sphinx, epytext or jsdoc.
Whether module, function, class, parameter and return documentation is required.
Whether type hints are required, and whether examples should be included.

Architecture

Error handling style, and whether logging is required, at which level.
Whether to use dependency injection, the factory pattern, the repository pattern and a service layer.
Whether to prefer composition over inheritance.
Size limits: maximum function length, class length, file length and number of parameters.

Testing

Framework, and the prefixes and suffixes used for test files, test functions and test classes.
Whether fixtures belong in a shared conftest, and which mocking library to use.
Minimum coverage, and whether to follow arrange, act, assert.

Communication

How the agent writes when it is not writing code: explanation verbosity, technical depth, tone, whether to use Markdown, and whether to include examples and alternatives.

Language overrides and custom rules

language_overrides lets one card carry different settings per language. custom_rules is a set of named rules in your own words, for anything the structured fields do not cover.

Predefined cards

Three cards ship as starting points:

| Card | What it sets | |------|--------------| | Python PEP8 Style | Standard Python style following PEP8 | | JavaScript Standard Style | JavaScript Standard style, no semicolons | | TypeScript Strict Style | TypeScript with strict type checking and semicolons |

You can dismiss a predefined card so it stops being offered to you.

Deriving a card from existing code

Rather than filling in every field, you can point the analyzer at a directory of code. It reports the naming, formatting, documentation, architecture and testing patterns it detected, with a confidence score for each, and returns a suggested configuration you can save as a card.

Working with cards

The API supports creating, listing (scoped to a project), reading, updating, duplicating and deleting a card, merging several into one configuration, and reading a card's metrics.