/atn:server-init: document a server in the SSH gateway

/atn:server-init documents one connection of the SSH gateway: your AI agent inspects the host read-only, writes the connection's description, adds every service that runs there and, if you want them, a health check for each. Run it after you create a connection for a host, or when a host's documentation is out of date and you want it rebuilt or completed.

The SSH gateway is the part of Athenode through which your AI agent runs commands and transfers files on your SSH hosts, each action approved by you or by a rule you set. A connection is one SSH host in the SSH gateway, with its login, its host key and its rules. The skill changes nothing on the host.

Run /atn:server-init

/atn:server-init [<connection-name>]

Argument	Description
<connection-name>	Optional. The name of the connection to document. Without it, the skill lists the connections and asks which one to document.

/atn:server-init web-shop-prod

Before you run it:

• Create the connection in the web UI and trust its host key. The skill cannot create connections, and it stops when the connection's status is anything other than OK.
• Give your AI tool the gateway module of the Athenode MCP server, which athenode init offers when it asks "Which modules should the Athenode MCP server give your AI tools?".
• On Athenode Pro, writing the description and the services needs the owner role in the connection's project, and a connection in the personal credential mode needs your personal credentials. The gateway on Athenode Pro describes both.

The skill works by the same rules as /atn:ssh-gateway: through the gateway tools only, with a reason on every action.

What /atn:server-init does

1. Finds the connection and reads its current description and services.
2. Asks how to treat existing documentation, if the connection has any.
3. Asks whether the services get health checks, before it inspects anything.
4. Inspects the host with read-only commands, grouped by topic, each with a timeout and the session label "server init" followed by the connection's name.
5. Sorts what it found into services and host-wide facts, and shows you the planned services, one line each, and an outline of the description. It waits until you agree or correct the plan.
6. Writes the connection's description.
7. Adds the services, each with its description.
8. Writes, tests and saves a health check for each service that gets one, and runs each new check once.
9. Reads the connection back and checks that the description is there, every planned service exists and every check is healthy.
10. Tells you what belongs in documentation kept elsewhere, such as an infrastructure repository, a hosts table or your plugin files, and adds it if you agree.

What the skill inspects

Topic	What the agent reads
Host	Host name, operating system, architecture, processors, memory, disks and mounts, free space, swap
Network	Addresses, routes, listening ports and the processes behind them, WireGuard peers without their keys, /etc/hosts
Firewall	The nftables ruleset, or the ufw or iptables rules
Access	The SSH server's settings, the comments and options of authorised keys without the keys, users with a login shell, sudoers files
Containers	Containers with image, status and ports, Compose projects with their files, networks, volumes, health checks and memory limits
systemd and cron	Running services that are not part of the system, units under /etc/systemd/system, timers, /etc/cron.d and root's crontab
Web	The Caddy, nginx or Traefik configuration: domains, upstreams and TLS
Operations	Backups, monitoring agents, log shipping and maintenance scripts in /usr/local/sbin

The agent also inspects anything you named as important, and follows leads, such as the variable names in a Compose project's .env or a script that a timer calls, until it understands each thing that runs. It never prints environment files, keys, tokens or passwords. It records their paths and the names of the variables only.

Every inspection command is an action of the gateway. In the confirm mode each one waits for your approval in Live, unless an allow rule matches it. Approvals and rules explains the modes and the rules.

Services and the description

A service is something that runs and can be checked: a container or one product's group of containers, a daemon, a timer or cron job, a firewall or rules loader. Everything else goes into the description, or into the service it belongs to: host facts, networks and access, the firewall policy, Compose projects, how deploys happen, storage, rules, procedures and pitfalls.

Health checks the skill writes

Each check is a read-only sh command that exits with 0 when the service is healthy and prints one short line per thing it checks, so that a failed run explains itself.

Kind of service	What the check tests
Containers	That each of the product's containers is running and, where it has a health check of its own, healthy
An endpoint	That the local listener answers with the expected HTTP code, not a 5xx or no answer
A daemon	That the unit is active, with a sign that it works: a listening port, a loaded firewall table, a fresh state file
A timer	That the timer is active, its last run succeeded and its last trigger is younger than its period plus a margin
A cron job	That what the job writes is fresh

Before it saves a check, the agent runs the command once as it is and once against a name that does not exist, to see that it fails. The intervals it sets are 60 to 120 seconds for production containers, 300 seconds for daemons and 3,600 seconds for timers, with a timeout of 20 to 60 seconds and the default failure threshold of 2. Services and health checks gives the ranges a check accepts.

Questions /atn:server-init asks

When	What you are shown	Options
You gave no connection name, or the name matches none or several	The connections	The connection to document
The connection already has a description or services	The existing documentation	Rebuild everything, which replaces or removes the old services, or only fill the gaps, which keeps what is there and adds what is missing
Before the inspection	"Should the services get health checks (a command the gateway runs on the host on an interval; exit 0 = healthy)?"	"Yes, for every service (Recommended)", "Only for the services I pick (I'll choose after seeing the list)" or "No, descriptions only"
After the inspection	The planned services and the outline of the description	Agree, or correct the plan
After the inspection, if you chose to pick the services	The planned services	The services that get a health check
At the end, if the host belongs to infrastructure with documentation of its own	What should be added there	Add it, or leave it

Creating a health check needs your approval in Live, like a command.

What /atn:server-init changes

Where	What changes
The host	Nothing. The agent runs inspection commands only: no restarts, no package installs, no file writes, no image pulls, no clean-ups.
The connection's description	Written as a whole, up to 4,000 characters: a first paragraph on what the host is (provider, operating system, architecture, public and VPN addresses, role, production or not, related repositories), then sections such as Networks and access, Firewall, SSH, Compose projects, Deploy, Storage and Pitfalls. It describes the current state only, in English.
Services	One per thing that runs, with a short, stable name of up to 100 characters and a description of up to 1,000 characters: what it is, image or binary, domains and ports, networks, configuration and data paths, its own health check, the deploy or reload command and its pitfalls. A service that does not fit is split in two. When you chose to rebuild, the old services are changed or removed.
Health checks	One per service that you chose to check, saved with its command, interval and timeout.
History	One entry per inspection command and check run, under the session label "server init" followed by the connection's name.

The agent talks to you in your language and writes the description and the services in English.

The report

The report covers:

• the connection, and whether the run was a first documentation, a rebuild or a filling of gaps;
• the sections of the description and its length;
• a table of the services, with what each one is, whether it has a check and at what interval, and its last health;
• the checks that are not healthy, with their output;
• what was skipped, by your choice or because the host did not allow it;
• anything left for you, such as documentation elsewhere to update.