coferlandia-config-toolsmith

Analyzes repository configuration mechanisms and generates a static contract, standardized CLI, and agent documentation.

Updated Jun 11, 2026
One-click install
npx skills add https://github.com/coferlandia/coferlandia-skills --skill coferlandia-config-toolsmith-coferlandia
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: coferlandia-config-toolsmith
Source: https://github.com/coferlandia/coferlandia-skills/tree/main/skills/meta/coferlandia-config-toolsmith
Command: npx skills add https://github.com/coferlandia/coferlandia-skills --skill coferlandia-config-toolsmith-coferlandia

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Repositories often have fragmented configuration spread across environment variables, dotenv files, JSON, appsettings, and secret providers, making it unsafe for agents and developers to inspect or change settings. This Skill discovers those mechanisms, classifies every signal, and produces a deterministic operational facade without creating a shadow configuration store. ## Core Features & Use Cases - Discovery and classification: Inventories configuration sources, consumers, loaders, and secret providers, assigning each signal a disposition such as MANAGED, CANDIDATE, or OBSOLETE. - Static contract and deterministic generation: Validates a state-free contract and generates a standardized configuration CLI plus seven agent/developer documents, with drift checking and byte-identical regeneration. - Safe candidate lifecycle: Approves ambiguous fields only with explicit authority and fingerprint verification, regenerating the facade and docs before marking candidates implemented. - Use Case: Point it at a Python or .NET repository whose settings are scattered across .env files and appsettings; it produces a contract, a config CLI with plan/apply semantics, and a complete agent handbook while leaving native runtime resolution untouched. ## Quick Start Ask the agent to run coferlandia-config-toolsmith against your repository to analyze its configuration and generate the standardized config CLI and documentation.

Frequently Asked Questions about coferlandia-config-toolsmith

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I standardize configuration management in an existing repository?▼

Run the Config Toolsmith process against the target repository. It discovers configuration signals, classifies each one, builds a static contract at .coferlandia/config-toolsmith/contract.yaml, and deterministically generates a standardized config CLI plus agent documentation.

How do I generate a configuration CLI for a Python or .NET project?▼

Validate the contract, then run the deterministic CLI's generate command with the contract path, target root, and platform set to auto, python, dotnet, or fallback-python. Use --dry-run first to review every path the generator will write.

Does this create a new configuration store or change runtime resolution?▼

No. Native loaders, stores, and precedence remain the only runtime source of truth. The contract describes behavior and bindings only, and the application never reads it; the generated CLI operates against approved native targets.

What happens when a configuration field is ambiguous or cannot be classified?▼

The field is recorded as a candidate with evidence and a source fingerprint, and work continues. Approval requires explicit authority and a matching fingerprint; stale candidates are rejected and must be re-analyzed before promotion into the contract.

How are secrets handled by the generated configuration CLI?▼

Secret values never appear in the contract, docs, plans, logs, or command arguments. Writable secret fields must declare a secret_write_method of stdin or native-provider, and secret reads report only presence and source.

What are the limitations of the generated fallback facade?▼

The Python fallback directly supports env, dotenv, and JSON bindings only. Adapters such as toml, database, remote, or dotnet-options require native integration or a declared custom adapter, and generation reports which bindings the selected platform pack implements.