/athenode-init

/athenode-init configures the workflow settings that /mindmap-specification, /decompose-specification and /apply-specification 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 /athenode-init 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 /athenode-init 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 a compact summary of your current settings, per category and per sub-project, then asks which categories you want to change. Managing sub-projects is offered on every re-run.
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 CLI. 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), TDD (failing tests first) or BDD (behaviour scenarios first). With TDD, specifications also get an acceptance criteria section; with BDD, they get Given/When/Then scenarios.

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 and BDD are 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.

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. Confirmation. You confirm the list: use it as is, remove some entries, add others, or have no sub-projects. This step is skipped when nothing is found and no sub-projects exist yet.
3. Values. Each sub-project either uses the root values or is customised, in which case the root values are recommended. New sub-projects go through all four categories; existing ones only through the categories selected in this run.
4. Full copies. Each sub-project keeps a full copy of every settings file. There are no partial overrides.
5. 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