# Config Registry

Manages a schema-validated registry of named configuration entries for workers.

- Repository: https://github.com/iii-hq/iii (18876 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add iii-hq/iii --skill configuration -g -a claude-code -y`
Codex: `npx skills add iii-hq/iii --skill configuration -g -a codex -y`
Cursor: `npx skills add iii-hq/iii --skill configuration -g -a cursor -y`
Gemini CLI: `npx skills add iii-hq/iii --skill configuration -g -a gemini-cli -y`

## Description

Schema-validated, reactive registry for named configuration entries, the runtime configuration surface used by engine and Compose workers.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# configuration

The `configuration` worker is a server-side registry of named entries. Every entry has an id (e.g. `iii-stream`, `billing-service`), a human-readable name and description, a JSON Schema describing the value shape, and a JSON value validated against that schema. Workers call `configuration::register` once at startup to declare their schema and `configuration::set` to publish values; consumers call `configuration::get` / `configuration::list` to read and bind a `configuration` trigger to react to changes without polling.

The default `fs` adapter persists one YAML file per id under `./config` and watches the directory for external edits, so manual edits surface as `configuration:updated` events. The `bridge` adapter delegates to a remote engine. The worker is engine-owned and may be configured at `engine.workers.configuration`.

A per-id TTL (off by default) cleans up entries whose last subscriber trigger has unregistered, scoped to the lifecycle of ephemeral workers that come and go without an explicit teardown step.

## When to Use

- A worker needs a typed, observable configuration surface other workers can read and validate against.
- Two workers need to agree on the same configuration values without one polling the other or hardcoding a path on disk.
- An operator should be able to edit a single YAML file (or the remote control plane) and have the change propagate to every subscriber without a worker restart.
- A worker comes and goes (sandboxes, ephemeral consumers) and its configuration should be cleaned up automatically when no one is left subscribing.

## Boundaries

The rest: https://github.com/iii-hq/iii/blob/HEAD/engine/src/workers/configuration/skills/SKILL.md