Where this fits

You have an agent that needs to tweak a game module, update an automation, or switch an Agent profile — but the config lives in JSON files you never want it to edit directly. Every change risks a corrupted file or an invalid value. The config-manager skill solves this by giving agents two stable tools, config_read and config_apply, that handle discovery, validation, and revision tracking for all Denova configuration resources.

Why agents benefit

• Safe, read-first workflow: Agents follow a required sequence — describe, list, get, then apply — so they never guess a shape or overwrite a resource without knowing its exact ID and revision.
• Cursor-aware pagination: When resources exceed one page, agents continue with the provided next_cursor until truncated=false, making bulk operations reliable.
• Resource-specific contracts: Each configuration kind (presets, modules, automations, Skills, Agent profiles) has its own reference file that agents must read before mutating, preventing cross-resource schema mistakes.
• No direct file access: The agent never touches storage internals; all changes go through validated config_apply calls.
• Revision consistency: Agents fetch the latest revision before an update, avoiding conflicts from stale reads.

Practical scenarios

Enabling a new game module on a live server

An agent receives a request to turn on a new game module. It first calls config_read with operation=describe to confirm the module contract, lists all modules to find the exact ID and scope, then reads the module reference, gets the current revision, and applies the change with the revision token to ensure the update only lands if the data hasn't shifted.

Auditing all automations before a holiday

A platform operator asks the agent to list every automation across all scopes. The agent uses config_read(operation=list) and follows the cursor chain until truncated=false, producing a complete catalog. Because it respects pagination, no automation is missed — critical for compliance checks.

Reverting a mistaken profile update

An agent updates an Agent profile but later is told the change broke another service. It calls config_read(operation=get) for that profile, reads the profile reference, and applies the previous values using the revision it retained. The rollback is atomic and doesn't require manual file edits.

Add it to your agent workflow

Install the skill into your agent environment:

npx skills add alfredxw/denova --skill config-manager

Then, in your agent's prompt, instruct it to use the Config Manager Agent whenever it needs to read or change any Denova configuration. The skill enforces the correct tool sequence automatically. For example, a simple discovery query:

{
  "tool": "config_read",
  "params": {
    "operation": "describe"
  }
}

You can also browse the full skill documentation and community context on OpenAgentSkill before adding it.

Compare before adopting

Before integrating, compare against your current configuration approach. Check if the skill's resource definitions match your Denova version. Look at how actively the repo is maintained (commits, issues, release cadence). Compare with alternative skills that offer similar read/apply patterns, and verify that config-manager fits your agent's permission model — especially if you need fine-grained scoping across multiple environments.

Why it is worth tracking

With 646 stars and a focused README that spells out a strict workflow, config-manager shows real discipline. The author, alfredxw, has designed it to prevent the most common agent failure modes: guessing schemas and overwriting data. It's worth tracking because configuration drift is a silent killer in agent systems, and a skill that enforces revision-safe, catalog-aware reads is a strong pattern to adopt or emulate. Re-evaluate it when your agent needs to manage more than one type of configuration resource, or when you notice your team resorting to manual JSON edits.