Settings
Your way of working is a file in your repository.
Methods, models and versions live in .aktum/. The settings screens edit those files, through a change you review.
01 · Method
Your method, not ours.
Aktum reads the framework already in your repository: Spec Kit, Superpowers, OpenSpec, Kiro, or none. Replace one skill with one file, or write your own method and bind it to a phase.
.aktum/workspace.yaml
Roles, the default decider, signoff rules, how the builder is allowed to behave, whether work lands in a worktree or a branch.
.aktum/methods/
Your own method text, bound to a phase by name. Declared in the policy or found by its filename.
.aktum/skill-overrides/
One file replaces one skill Aktum ships, and the run reads yours instead. The rest keep working.
.aktum/instructions/
The standing instructions for drafting and generation, edited in the studio and committed here. Aktum's own contract stays locked above yours and is shown, not hidden.
.aktum/models.yml
Named model tiers, assigned per phase. Two or three of them on the review phase run blind and in parallel, then are revealed together.
.aktum/schema/
Nine JSON Schemas, generated from the code and committed beside your config, so your editor completes and checks your own governance file.
02 · Models
Named model tiers, per phase.
Each tier names an engine, a model and a key. Keys stay on your sidecar or are stored encrypted in Aktum, and can be tested with a real call.
03 · Versions
Upgrades are proposals, never silent.
Each workspace pins its versions. The versions page shows how far behind each pin is, and one action proposes the upgrade to every workspace that is behind.
A setting is a change you can review.
A change arrives as a pull request on GitHub, or as a commit when the repository is on your own machines. A broken workspace file is refused with the reason, and the last good settings stay.