config-user

name	config-user
description	Operate the `config` admin tool — inspect, edit, get, set config files for sibling scripts in the collection. Trigger when the user wants to view or change a script's configuration, reset to defaults, or learn the foundation pattern (each script reads its own config; config is the user-facing front-end).

config-user skill

1. Design principles

config follows the four collection principles — educational, functional, decentralized, simple — specialised:

• Educational. config is a thin shell over the filesystem: a store is a directory, a parameter is a file. Reading bin/config end-to-end teaches the flat-file config model.
• Functional. Every subcommand is a pure transformation: read a file, write a file, list a directory, sync via SSH. State lives in $XDG_CONFIG_HOME/<script>/.
• Decentralized. No central config server. Each account holds its own stores; config sync is a symmetric pull/push between peers.
• Simple. config calls only account at runtime. Sibling scripts read their own files directly and never delegate config lookup to config.

2. The model

Each script in the collection reads its own config files directly under $XDG_CONFIG_HOME/<script>/. config is the user-facing admin tool that manages those files — it does not sit in any other script's runtime path.

A store is a flat directory of key/value parameters:

$XDG_CONFIG_HOME/config/<store>/
    <param>          # one file per parameter
    <sub>/<param>    # nested

A parameter is identified by a hierarchical id: <store>/<sub>/<param>. Plugins under libexec/config/<plugin> extend the surface (e.g. config account resolves account-derived defaults).

3. Workflow recipes

1. Show every existing store.

   config stores
   

2. Create a new store.

   config init bitcoin
   

3. Set a parameter from the shell.

   echo mainnet | config set bitcoin/network
   

4. Read a parameter.

   config get bitcoin/network
   

5. Edit a parameter in $EDITOR.

   config edit bitcoin/network
   

6. List every parameter under a store.

   config ls bitcoin
   

7. Sync stores between accounts.

   config sync [e-mail]
   config push bitcoin [e-mail]
   config pull bitcoin [e-mail]
   

8. Render a parameter as a QR code (offline transfer).

   config qr bitcoin/seed
   

9. Generate a random parameter (e.g. for a secret).

   config gen bitcoin/api-token
   

4. Guardrails

1. Don't store secret material in config. Use secret for that. config parameters are plaintext on disk.
2. config sync over SSH is unauthenticated at the filesystem layer. It relies on account online <peer> — the trust comes from the SSH key registered in account insert. If you don't trust the peer, don't sync to them.
3. Don't write a sibling script that calls config get <store>/<param> at runtime. That re-introduces the → config cycle FEAT-026 removed. Read your own $XDG_CONFIG_HOME/<self>/ files directly.
4. config -f (force) on pull / push overrides conflict resolution. Use only when you've inspected the diff and know which side wins.
5. config destroy <store> is permanent. No undo; it rm -rf's the store directory. Take a backup if uncertain.

5. Where to read more

• man config — full reference (synopsis, every subcommand, environment, files, exit status).
• docs/config.md — the CLI contract doc per FEAT-004 (semver-pinned 1.0.0).
• This package's CLAUDE.md — developer-side conventions, the no-shared-lib policy, intentional duplications.