Skip to content
Agentmart
Submit a tool

config-versioning

Language/framework-agnostic guidance for designing config systems that stay backward compatible across code changes, and for writing config parsers that…

Skill by threeal

IndexedMIT★ 1
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/threeal-config-versioning

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Language/framework-agnostic guidance for designing config systems that stay backward compatible across code changes, and for writing config parsers that anticipate future versions instead of hardcoding the current one. TRIGGER - about to design a config file/schema, add persisted settings/state, or write/modify config-loading or config-migration logic. SKIP - validating config values against business rules unrelated to version compatibility.

Use cases: design, writing

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/config-versioning

What's inside

Skill name
config-versioning
Description
Language/framework-agnostic guidance for designing config systems that stay backward compatible across code changes, and for writing config parsers that anticipate future versions instead of hardcoding the current one. TRIGGER - about to design a config file/schema, add persisted settings/state, or write/modify config-loading or config-migration logic. SKIP - validating config values against business rules unrelated to version compatibility.
License
MIT
Instructions
41 lines in SKILL.md · view on GitHub

Files (1)

  • SKILL.md

SKILL.md (first lines)

## Suggest Versioning When Designing a Config System

When implementing a config system — a file, a schema, any persisted state that outlives a release — suggest an explicit version field as the mechanism for backward compatibility. Offer it; whether to adopt it is the user's call, not a mandate.
Why: persisted config isn't disposable, it's state the user already invested in, so prefer keeping old configs working over forcing a reset whenever the code changes. An explicit version marker lets parsing code know up front which shape it's holding, instead of guessing from which fields happen to be present.

## Never Parse Versions With a Static Equality Check

Even when only one version exists, write the loader as an open dispatch over version, not an assertion against a single supported value.
Why: this encodes that future versions are expected, so adding one means adding a case rather than editing a condition.

Incorrect:

```
if config.version != CURRENT_VERSION:
    raise Error("unsupported config version")
parse_current(config)
```

Correct:

```
match config.version:
    case "1":
        parse_v1(config)
    case "2":
        parse_v2(config)
    case _:
        raise Error(f"unsupported config version: {config.version}")
```

## Handle Missing Data Per Field, Not All-or-Nothing

An older config may not carry everything the current code expects. When a version-specific parser hits data it can't get, resolve it per field, in rough order of preference:

- fall back to a sensible default
- derive it from other values that are present
- refuse — only when the data is genuinely required and unrecoverable

Incompatibility is usually partial: one field may block one piece of data while the rest of the config stays perfectly usable. Whether that surfaces as a warning, an error, a log line, or is absorbed silently depends on how critical that field is — decide per field rather than failing the whole parse over one of them.

From threeal/.claude, MIT.

More from threeal/.claude

Signals

Stars
1
Forks
0
Open issues
0
Last commit (this folder)
Sep 21, 2026 (1 month ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from threeal

Cite this page

config-versioning skill. Agent Mart. https://agentmart.dev/skills/threeal-config-versioning (last updated 2026-10-24)