Mirrord Configuration Skill

Purpose

Generate and validate mirrord.json configuration files:

• Generate valid configs from natural language descriptions

• Validate user-provided configs against schema

• Fix invalid configurations with explanations

• Explain configuration options and patterns

Critical First Steps

Step 1: Load references Use the view tool to read BOTH reference files:

• /mnt/skills/user/mirrord/references/schema.json

• Authoritative JSON Schema

• /mnt/skills/user/mirrord/references/configuration.md

• Configuration reference

Step 2: Install mirrord CLI (if not present)

Check if installed

which mirrord || brew install metalbear-co/mirrord/mirrord || curl -fsSL https://raw.githubusercontent.com/metalbear-co/mirrord/main/scripts/install.sh | bash

Step 3: Validate before presenting After generating any config, ALWAYS run:

mirrord verify-config /path/to/config.json

• If validation fails, fix the config and re-validate

• Only present configs that pass validation

• Include validation output in your response

Request Types

Generate new config

User describes what they want without providing JSON.

• Extract target (pod/deployment), namespace, features needed

• Create minimal valid config using only schema-defined keys

• Default to minimal configs; mirrord has sensible defaults

Validate existing config

User provides JSON to check.

• Parse strictly (catch trailing commas, comments, invalid syntax)

• Validate against schema

• List issues by severity: Errors → Warnings → Suggestions

• Provide corrected version

Modify existing config

User wants changes to their config.

• Validate first, then apply requested changes

• Ensure modifications maintain schema conformance

Response Format

For generation or fixes:

• Brief summary (1-2 sentences)

• Valid JSON config in code block

• Validation output from mirrord verify-config :

{ "type": "Success", "warnings": [], "compatible_target_types": [...] }

• Short explanation of key sections (if validation passed)

For validation:

• Errors (schema violations - will cause failures)

• Warnings (valid but potentially wrong behavior)

• Suggestions (optional improvements)

• Corrected JSON config

Configuration Guidelines

Common patterns (verify exact keys in schema):

Target selection:

• "target": "pod/name" or {"path": "pod/name", "namespace": "staging"}

• Set operator if using operator mode

• Specify kube_context if needed

Features:

• "env": true

• Mirror environment variables

• "env": {"include": "VAR1;VAR2"}

• Selective inclusion

• "fs": "read"

• Read-only filesystem access

• "network": true

• Enable network mirroring

• "network": {"incoming": {"mode": "steal"}}

• Steal incoming traffic

Network modes:

• Check schema for valid incoming.mode values (e.g., "steal", "mirror", "off")

• Configure HTTP filters, port mapping, localhost handling

Templating:

• mirrord uses Tera templates

• Example: "target": "{{ get_env(name="TARGET", default="pod/fallback") }}"

• Templates must remain valid JSON

Validation Rules

Must enforce:

• Strict JSON parsing (no comments, no trailing commas)

• All keys must exist in schema

• Correct types (string vs object, enums, etc.)

• Required fields present

• No additionalProperties where schema forbids them

Path notation for errors: Use JSON Pointer style: /feature/network/incoming/mode

Common Pitfalls

• User pastes YAML/TOML → Explain JSON required, offer to convert structure

• User requests unsupported key → Say it's not in schema, suggest alternatives

• Overly complex configs → Prefer minimal configs with only requested settings

• Conflicting settings → Identify based on configuration.md semantics

What to Ask (only if critical)

If request is under-specified, ask for ONE detail:

• Target identity (pod name, namespace)

• Incoming network behavior (steal vs mirror)

• Operator usage (yes/no)

• Specific ports to map/ignore

Otherwise provide safe defaults and note assumptions.

Automatic Validation Workflow

Every generated or modified config MUST be validated before presentation:

• Save config to temporary file

• Run mirrord verify-config <file>

• If validation fails:

• Parse error messages

• Fix the config

• Re-validate until success

• Present config with validation output

Never skip validation - it catches schema errors we might miss manually.

Quality Requirements

✓ Schema-first: Output must conform to schema.json

✓ No hallucination: Only use documented keys

✓ Valid JSON: Always parseable, no comments

✓ Actionable feedback: Clear explanations of what to fix and why

✓ Minimal configs: Don't set unnecessary options

Example Scenarios

"Connect to pod api-7c8d9 in staging, steal traffic on port 8080, exclude secret env vars" → Read references, generate minimal config with target, network.incoming, env.exclude

User provides invalid JSON with trailing comma → Parse error → Fix syntax → Validate against schema → Explain issues → Provide corrected config

"Is my config valid?" + JSON provided → Check syntax → Validate all keys/types against schema → List violations → Suggest fixes