Mirrord Configuration Skill

Purpose

mirrord.json

• 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

references/

1. references/schema.json

   - Authoritative JSON Schema

2. references/configuration.md

   - Configuration reference

**/mirrord-config/references/*

# 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

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

• 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

• Parse strictly (catch trailing commas, comments, invalid syntax)
• Validate against schema
• List issues by severity: Errors → Warnings → Suggestions
• Provide corrected version

Modify existing config

• Validate first, then apply requested changes
• Ensure modifications maintain schema conformance

Response Format

For generation or fixes:

1. Brief summary (1-2 sentences)
2. Valid JSON config in code block
3. Validation output from

   mirrord verify-config

   :

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

1. Short explanation of key sections (if validation passed)

For validation:

1. Errors (schema violations - will cause failures)
2. Warnings (valid but potentially wrong behavior)
3. Suggestions (optional improvements)
4. Corrected JSON config

Configuration Guidelines

Common patterns (verify exact keys in schema):

• "target": "pod/name"

  or

  {"path": "pod/name", "namespace": "staging"}

• Set

  operator

  if using operator mode
• Specify

  kube_context

  if needed

• "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

• Check schema for valid

  incoming.mode

  values (e.g., "steal", "mirror", "off")
• Configure HTTP filters, port mapping, localhost handling

• mirrord uses Tera templates
• Example:

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

• Templates must remain valid JSON

Validation Rules

• 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

/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)

• Target identity (pod name, namespace)
• Incoming network behavior (steal vs mirror)
• Operator usage (yes/no)
• Specific ports to map/ignore

Automatic Validation Workflow

1. Save config to temporary file
2. Run

   mirrord verify-config <file>

3. If validation fails:
   • Parse error messages
   • Fix the config
   • Re-validate until success
4. Present config with validation output

Quality Requirements

schema.json

Example Scenarios