Data interchange

Bring data in from any structured format, normalize through JSON as the universal pivot, merge with overrides, audit the diff, flatten for downstream systems, and emit to whatever format the next stage actually consumes — CSV for spreadsheets, YAML for config systems, JSON for everything else. The deterministic universal-format-bridge workflow.

When to use this pack

A common ops/integration pattern: base config lives in YAML (12-factor / k8s convention), environment-specific overrides arrive as JSON (from a vault, an env API, a feature-flag service), and the downstream system that consumes the result wants either a CSV (for an audit spreadsheet), a flattened key=value envelope (for env-var injection), or the canonical YAML back (for committing to git). Doing this by hand involves three format-conversion utilities, a merge tool, and a diff to prove what changed — this pack chains them in one pass and produces every output format at once.

Tools in this pack

Workflow

  1. Parse the base YAML with yaml-to-json. YAML is the most config-friendly source format (comments, anchors, multi-line strings) but JSON is the only sensible pivot — every downstream merge/diff/flatten tool takes JSON in and returns JSON out. Catch the silent failure here: YAML with tabs (forbidden), inconsistent indentation, or unquoted strings that look like booleans ('yes'/'no'/'on'/'off' all become actual booleans in YAML 1.1) — surface these as parse warnings rather than letting the override merge inherit a wrong type.
  2. Apply the overrides with json-merge. Deep-merge is the right primitive for config: scalar values get replaced, objects get recursively merged, arrays get concatenated (this is the json-merge tool's contract — see the source). For environment overrides this is exactly right: the base ships defaults, the env supplies the specifics. Reject any override key in {__proto__, constructor, prototype} as the tool's prototype-pollution guard, which gives you 'safe to load from arbitrary user-controlled JSON' as a free property.
  3. Audit the merge with json-diff against the original base. Returns a structured diff (added / removed / changed paths). This is the most important step for production rollouts: 'we changed server.host and enabled features.betaApi — was that intentional?' is the compliance question, and json-diff produces the artifact that answers it. Generate this diff at deploy time and ship it to your audit log so the next outage post-mortem can pin a config change to a moment in time.
  4. Flatten the merged document with json-flatten. Nested {server: {host: 'x', port: 8080}} collapses to {'server.host': 'x', 'server.port': 8080} — the exact shape an env-var emitter or a Vault writer or a k8s ConfigMap data-block expects. This is the bridge between human-friendly nested structure and machine-friendly key=value transport. Note that the json-flatten tool also supports the reverse direction (unflatten) when you need to round-trip from key=value back to nested.
  5. Emit CSV with json-to-csv. Two-column shape (key,value) is what stakeholders want when reviewing config in a spreadsheet: filterable by key prefix, sortable, easy to diff in a code-review tool that doesn't natively render YAML. For a more report-y form, the csv-to-md tool can render the same data as a markdown table — but CSV is the right primary export because every downstream tool consumes it.
  6. Emit YAML with json-to-yaml. Round-trips the merged document back to YAML for git commit, ConfigMap creation, or human review — closing the loop and giving you a canonical 'this is the effective config at this version' artifact. Note that comments in the original YAML do NOT survive the JSON pivot (JSON has no comment grammar) — call this out in the prompt so the user knows to either inline comments as $comment-style keys, maintain them out-of-band, or accept that the round-tripped YAML is reformatted.

Run it in Claude

claude mcp add agent402 -s user -- npx -y agent402-mcp@latest

Then paste this prompt into Claude:

Merge and re-emit this config using Agent402.

Base YAML:
server:
  host: localhost
  port: 8080
  tls: false
database:
  pool: 10
  timeout: 30
features:
  betaApi: false

Overrides JSON: {"server":{"host":"api.production.example.com","tls":true},"features":{"betaApi":true}}

(1) yaml-to-json on the base. Confirm parsed structure (server/database/features). Flag any of the YAML 1.1 boolean-coercion traps (yes/no/on/off) if present. (2) json-merge — deep-merge the parsed base with the overrides JSON. Result should show server.host = production hostname, server.tls = true, features.betaApi = true, all other keys unchanged. (3) json-diff between the parsed base and the merged result. Surface the change set as a list: [{path, op, before, after}]. This is the audit artifact — log it and attach it to the deploy record. (4) json-flatten on the merged document. Emit the key=value envelope: SERVER_HOST=… / SERVER_PORT=… / SERVER_TLS=… etc. Convention: dot-separated keys map to underscore-separated UPPER_SNAKE env vars; describe the convention in the writeup. (5) json-to-csv on the flattened map. Two columns: key,value. This is the stakeholder-friendly export. (6) json-to-yaml on the merged document. This is the canonical 'effective config' YAML — call out that comments from the input YAML did NOT survive the JSON pivot. Final return: {parsedBase, merged, changeAudit: [{path, op, before, after}], envVars: {…}, csvExport, canonicalYaml, oneLineSummary: 'merged N override keys onto base; M paths changed; ready for deploy'}. All six tools are pure-CPU (PoW-eligible / free tier). Budget ≤ $0.01 even paid.

← All skill packs