| name | tedge-config-plugin |
| description | Write a new thin-edge.io (tedge) configuration management plugin to extend tedge-agent's config management to a new configuration type or source. Use this whenever the user wants to manage a new kind of configuration through thin-edge — for example "write a tedge config plugin for nginx", "add a new config type to thin-edge", "extend tedge config management to handle my database settings", "create a config-plugin so the cloud can update my app.conf", or any request about supporting a custom config type, source, or service in tedge's config_snapshot / config_update operations. Produces an executable plugin that conforms to the tedge config-plugin spec (the list/get/prepare/set/verify/rollback contract), plus install and test instructions. |
Writing a thin-edge config management plugin
A config plugin is an executable that lets tedge-agent read and update a
configuration it doesn't natively understand, with validation, backup, service
reload, and rollback around each update.
Read the spec, then build to it
The canonical spec — subcommand contract, discovery/permissions model,
config_update workflow, and a complete lighttpd reference plugin to use as
your template — lives here:
https://thin-edge.github.io/thin-edge.io/extend/config-management
(raw Markdown: https://raw.githubusercontent.com/thin-edge/thin-edge.io/main/docs/src/extend/config-management.md)
Fetch it at the start of every task and build strictly against it — it is the
source of truth and may have changed since this skill was written. Pay close
attention to the subcommand interface and the exit-code discipline the agent
relies on to drive its state machine.
Workflow: Staged interview with research-informed follow-ups
Ask in stages, not all at once — each answer narrows the next questions. Research
before you ask, so your questions are informed and come with sensible defaults.
-
Stage 1: Identify the config type. Ask what service/application config to
manage (e.g. nginx, mosquitto, a custom app). This is the only essential
up-front input.
-
Initial research. Fetch the spec and review the reference plugin. Then
research this specific config type:
- File location(s).
- How to validate a config of this type — find the actual validator and
its exact invocation (e.g.
nginx -t) rather than guessing; some types
have none.
- How a new config is applied. Do not assume this means reloading a
service. thin-edge runs on IoT devices where a service manager may not even
be present, and many config types take effect by other means — re-reading
the file on next use, a signal (
SIGHUP), a CLI apply command, a file
watcher, or nothing at all. Research what's normal for this type so you can
propose a concrete default rather than asking blind.
-
Stage 2+: Targeted follow-ups. Ask only what research couldn't settle,
each with a suggested default inline. For the application mechanism:
- If the type is typically run as a managed service, propose a reload as the
default and ask which service manager runs it — do not assume systemd;
it's the most common but confirm (OpenRC, SysVinit, runit, or a plain
command are all possible on these devices).
- Otherwise, ask how the app is managed and how config takes effect — service
manager or not — offering the mechanism your research suggested.
Also confirm the validator command you found, and how to aggregate when config
spans multiple files (default: main file). Add stages only as gaps remain.
-
Generate the plugin. Adapt the reference plugin from the spec to the
answers, in the user's chosen language (default: POSIX shell).
-
Install and local-test instructions. Give steps to verify the plugin by
hand before trusting it remotely.
