/atn-settings: choose your project's workflow settings

/atn-settings asks how AI agents should test, review and use git in your project and saves your answers as the project's workflow settings. Run it once after you install the setup, and again whenever a choice should change.

Workflow settings are grouped into four categories: testing, methodology, code review and gitflow. /atn-apply follows all four. /atn-todo-dequeue follows the testing, methodology and code review settings and takes its branch and commit naming from gitflow. /atn-mindmap and /atn-decompose follow the methodology when they write a specification.

Run /atn-settings

/atn-settings [category...]

Argument	Description
category	Optional, one or more of testing, methodology, code-review and gitflow. The skill asks about these categories only. Other words are ignored.

Without an argument, a first run goes through all four categories. A later run shows your settings and asks what to change.

/atn-settings gitflow testing

The skill saves setup files, so you need the owner or editor role in the project. Roles and permissions lists what each role can do.

What /atn-settings does

1. Reads the workflow settings your project has.
2. Looks at your local project without changing it: test frameworks and existing tests, end-to-end test tooling, continuous integration files, the git remote and default branch, whether gh or glab is installed, how existing tags are named and how recent commit messages are written.
3. Looks for sub-projects, which are nested git repositories and packages with their own manifest below the repository root. If it finds any, or your settings list some, it asks whether they get separate configurations.
4. Decides what to ask. A first run covers every project and every category. A run with category names covers those categories. Any other run shows a summary of the settings and asks which projects and which categories to change.
5. Asks the questions category by category, in the order testing, methodology, code review, gitflow. The recommended option comes first, with a one-line reason taken from what the skill found, such as the test framework in use.
6. Checks that the answers work together and asks again about a setting that conflicts with another.
7. Saves the settings and reports them.

Questions /atn-settings asks

The skill shows each choice as a short description. The default is the choice it recommends when your project gives no reason for another.

Testing questions

Question	Choices	Default
How thoroughly should agents test their changes?	No tests are written or run. Unit tests for new code. Unit and integration tests covering new and affected code, with edge and error cases.	Unit tests for new code
Should agents create end-to-end tests?	Do not create or run them. Create them for each change and run them. Create them and leave running them to continuous integration or a person.	Do not create or run them
How many attempts should agents make to fix failing tests before stopping?	3, 5, 10 or a number you type	5

Agents take the test commands from your project: its scripts, its README and its build files. When end-to-end tests are created and run, an agent may start the services the tests need, and afterwards it stops only the services it started. When tests keep failing after the last attempt, the agent stops work on that specification and the skill that started it asks you what to do.

The end-to-end question is asked only when agents write tests. The skill recommends creating and running end-to-end tests only when it found end-to-end tooling in the project.

Methodology question

Question	Choices	Default
In which order should tests and code be written?	The implementation first, then tests. Tests first, then the implementation (TDD).	The implementation first

With tests first, an agent writes failing tests, implements until they pass and then refactors. The skills that write specifications also add an ## Acceptance criteria section with testable criteria to a specification's content, wherever the criteria can be drawn from your answers.

Code review questions

Question	Choices	Default
When should the implemented work be reviewed?	No code review. Each specification right after it is implemented. One review of all implemented specifications at the end of the apply run. Both: each specification after it is implemented, and all of them together at the end.	One review at the end of the apply run
Which checks should the review run?	Any of four groups: spec conformance, correctness and security, quality and style, tests and docs	All four
How many automatic fix rounds should run for review findings before asking you?	1, 3 or 5	3

Spec conformance looks for what the specification asks for and the code lacks, and for behaviour that differs from it. A review that covers several specifications also checks that their code fits together where one calls or depends on another. Correctness and security looks for bugs, unhandled error cases and security problems. Quality and style compares the code with your project's conventions. Tests and docs checks that the tests your settings ask for exist and that the documentation is updated.

The second and third questions are asked only when a review runs. With testing set to no tests, the skill suggests leaving the tests and docs group off.

Gitflow questions

Question	Choices	Default
Which branches should agents create?	No new branches, work on the current branch. One new branch per apply run. One new branch per implemented specification.	One per apply run
Which branch should new branches start from?	The default branch the skill detected, main, master or develop where they exist, or a name you type	The detected default branch
When should agents commit?	Never, leaving the changes for you. After each implemented specification. Only after the code review approves the work. One commit at the end of the apply run.	After each implemented specification
Should agents create git tags?	No tags. A tag when the top specification of an apply run is completed. A version tag whose number is raised from the commit messages.	No tags
What text should every tag start with?	The prefix the skill detected in your tags, v, no prefix or text you type	The detected prefix, or v
What should happen at the end of an apply run?	Do not push. Push the branch. Push the branch and open a pull request.	Do not push
How should new branch names be built?	Keep the template you have, or type another	feature/<slug>
How should commit messages be built?	Keep the template you have, or type another	<type>(<scope>): <summary> [spec <spec_id>]

In a branch name, <slug> is built from the specification's title. The default commit message follows the Conventional Commits format, and the automatic version tag reads the kind of change from messages in that format: a feature raises the minor version, a fix the patch version and a breaking change the major version. If you choose version tags and a commit template in another format, the skill warns you. The skill recommends version tags when your existing tags follow semantic versioning, and a pull request only when the repository has a remote and gh (GitHub) or glab (GitLab) is installed.

The tag prefix is asked only when tags are created, the branch name template only when branches are created, and the commit message template only when agents commit. The page on /atn-apply describes what an apply run does with each of these choices.

Choices that depend on each other

Some answers rule out others. The skill leaves out a choice that cannot work with what you have chosen, and it tells you when it sets a value without asking.

When you choose	The skill
No tests	Sets the order to implementation first and end-to-end tests to off, without asking
No code review	Does not offer "commit only after the code review approves"
One branch per implemented specification	Sets commits to after each implemented specification, because each one is committed before the next branch is created
A repository with no git remote	Does not offer pushing or a pull request

A conflict can also come from a category you did not select, for example when you turn code review off while commits wait for its approval. The skill then names the project and the setting, asks that one question again and saves that category too.

Sub-project questions

When the repository holds nested repositories or packages, the skill lists them and asks how to configure them:

• "Separate configurations for these projects" keeps one configuration per listed sub-project, next to the configuration of the repository root.
• "Separate configurations, but remove some" then asks which sub-projects to remove.
• "Separate configurations, and add others" then asks for the extra paths.
• "One configuration for the whole repository" removes every sub-project configuration.

The root configuration applies to every file outside the sub-projects. A file inside a sub-project follows that sub-project's settings, and where sub-projects are nested the deepest one wins. Before each sub-project, the skill asks whether to configure it or to copy the answers of a project that is configured, with one copy option per such project. A copied answer that cannot work in the sub-project, such as pushing from a repository with no remote, is asked again.

A sub-project that is its own git repository runs its own gitflow during an apply run. The skill tells you when a choice in one project changes the behaviour of another.

Questions on a re-run

On a later run without arguments, the skill shows each project's settings in plain language and asks two questions: which projects to reconfigure, and which of the four categories. Projects and categories you leave out keep their saved values. A sub-project that is added in the run goes through all four categories.

What /atn-settings changes

The skill saves your choices to the settings files of your project's setup in Athenode: settings/SETTINGS.md, settings/testing.md, settings/methodology.md, settings/code-review.md and settings/gitflow.md. Each sub-project with its own configuration has a folder under settings/, named after its path, with its own four category files. Removing a sub-project deletes its folder. You can open the files in the web app as setup files.

The skill does not create or change any file in your repository, and it does not run a git command that changes the repository. The settings stay with the setup in Athenode, and the skills read them each time they run, so a change takes effect at the next run with no reinstall.

Every settings file has a ## Custom section for rules of your own, such as a required reviewer checklist or a command that must run before a commit. /atn-settings leaves that section as it is, and agents follow it together with the settings. You edit it in the web app or with /atn-manage.

The report

The skill ends with a report that lists:

• the chosen settings in plain language, per project and per category, with "same as the root" where a sub-project matches the root;
• the sub-projects added or removed;
• each value it corrected so that the settings work together, and why;
• a note when neither gh nor glab is installed, since a pull request needs one of them;
• a reminder that the ## Custom sections are untouched and that you can run the skill again at any time, with or without category names.