/atn-settings

/atn-settings configures the workflow settings that /atn-mindmap, /atn-decompose and /atn-apply follow: how your project is tested, which methodology it uses, how code is reviewed and how git is handled. The settings are stored in the settings/ files of your agent setup on the Athenode server (see Setup files). The skill talks to you in your own language, but the settings it saves are always written in English.

First run and re-runs

1. First run. A freshly installed setup is marked initialized: false. Run /atn-settings without arguments and it walks you through all four categories.
2. Choose categories. Pass one or more category names — testing, methodology, code-review, gitflow — to configure only those, for example /atn-settings gitflow testing. This works on the first run too. Other words are ignored.
3. Re-runs. Run without names on an initialised setup, it first shows your sub-project list so you can add or remove projects, then a plain-language summary of each project's current settings, and asks which projects and which categories you want to change. Newly added projects go through all four categories. When you pass category names and your repository has sub-projects, the skill asks which projects to reconfigure.
4. Recommendations from your repository. Before asking anything, the skill looks through your repository without changing it — your test setup, git remote, tags, package manifests and similar — and recommends answers based on what it finds.
5. Server-side only. Your answers are written to the settings/ files on the server through the Athenode MCP server. Nothing is written to your local repository.
6. Marked as initialised last. The final write marks the setup as initialised and records the list of sub-projects. It happens only after every other write succeeded.
7. Your own rules are kept. Each file's ## Custom section is left untouched, so project-specific rules you add there survive every re-run.

Categories

The categories are always asked in the same order: testing → methodology → code review → gitflow. For each question, the recommended option comes first, with a short reason.

Testing

How much to test: no tests, unit tests for new code (the default), or full unit and integration tests for new and affected code. It also asks whether end-to-end tests should be created and run, created only, or skipped, and how many attempts are made at fixing failing tests before giving up.

Methodology

Whether tests or code come first: test-after (the default, code first) or TDD (failing tests first). With TDD, specifications also get an acceptance criteria section.

Code review

When the work is reviewed: no review, per specification (right after each one is implemented), per batch (once, at the end of the run; the default), or both. It also asks which check groups to enable — spec conformance, correctness and security, quality and style, tests and docs — and how many automatic fix attempts are made for review findings.

Gitflow

The branch strategy (work on the current branch, one branch per apply run, or one per specification), the base branch, the commit strategy, tagging, what happens after an apply run (leave the changes, push, or push and open a pull request), and the templates for branch names and commit messages.

How answers constrain each other

Some answers change which options are offered later:

• No tests: TDD is hidden and test-after is used, end-to-end tests are skipped, and turning off the tests-and-docs review checks is suggested.
• No review: the "commit after review approval" option is hidden, and no check groups or fix attempts are asked for.
• One branch per specification: commits are made per specification too.
• No git remote: the push options are hidden.
• Re-runs: if a saved value now conflicts with a new answer, the skill explains why and asks for it again, even when its category wasn't selected.

Sub-projects

Some repositories hold several sub-projects that need their own settings. The skill settles them first, before asking anything else.

1. Detection. The skill looks for nested git repositories and package manifests below the root, such as package.json, pom.xml, build.gradle, pyproject.toml, Cargo.toml and go.mod. Build and dependency folders such as node_modules are ignored.
2. One or separate configurations. The first question shows the list and asks whether to use one configuration for the whole repository or separate configurations for these projects. You can remove entries or add others at this point. When nothing is found and no sub-projects exist yet, the whole repository gets one configuration and this question is skipped.
3. The root comes first. With separate configurations, the root is configured first, as a project of its own. Its settings apply to every file outside the sub-projects. Each sub-project follows in turn.
4. Every project gets every question. Each project goes through all four categories, with recommendations based on what the skill finds in that project's own folder.
5. Copy instead of answering again. Before each project after the first, you can configure it or copy the answers of a project you have already configured.
6. Checks across projects. Some settings affect other projects too, for example when one project uses one branch per specification, reviews in every project wait for each other. When projects conflict, the skill explains the problem and offers a correction.
7. Full copies. Each sub-project keeps a full copy of every settings file. There are no partial overrides.
8. Removal. When you remove a sub-project, its settings folder is deleted.

What's next

• Built-in skills — the skills that follow these settings
• Setup files — where the settings are stored and how to edit them
• Getting started — set up Athenode and run your first skill