agentsclimarketplace

Managing overrides

Skill pvnarp/harness-agentic-skills/skills/harness/managing-overrides

Manage Harness service overrides via MCP - environment-scoped, infra-scoped, and cluster-scoped overrides for service variables, manifests, config files, and Azure application settings. Supports ENV_GLOBAL_OVERRIDE, ENV_SERVICE_OVERRIDE, INFRA_GLOBAL_OVERRIDE, INFRA_SERVICE_OVERRIDE, CLUSTER_GLOBAL_OVERRIDE, and CLUSTER_SERVICE_OVERRIDE types. Use when asked to override service config per environment, set environment-specific variables, override Helm values per cluster, or manage env-specific config files. Trigger phrases: service override, env override, environment variable override, cluster override, infra override, override variable, override manifest, override config file.From its SKILL.md

Install
npx -y skills add pvnarp/harness-agentic-skills --skill managing-overrides

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

8.8 KB, as published. Nobody here has run it

Manage Service Overrides

What this skill uses

Harness MCP tools: harness:harness_create, harness:harness_delete, harness:harness_describe, harness:harness_get, harness:harness_list, harness:harness_update Resource types: service_override

Service overrides let you adjust service-level configuration (variables, manifests, config files, Azure app settings, connection strings) per environment, infrastructure, or cluster - without forking the service definition.

Override types

TypeScopeWhen to use
ENV_GLOBAL_OVERRIDEAll services in an environment"All staging deployments use this Slack webhook"
ENV_SERVICE_OVERRIDEOne service in one environment"checkout-service in prod uses these flags"
INFRA_GLOBAL_OVERRIDEAll services on a specific infrastructure"Anything on the EU cluster uses GDPR config"
INFRA_SERVICE_OVERRIDEOne service on one infrastructure"platform-api on cluster-east uses regional DB"
CLUSTER_GLOBAL_OVERRIDEAll services on a GitOps cluster"All apps on prod-cluster use cluster-wide values"
CLUSTER_SERVICE_OVERRIDEOne service on one GitOps cluster"specific app + cluster combo"

Instructions

Step 1: List overrides for an environment

environment_id is required on list.

Call MCP tool: harness:harness_list
Parameters:
  resource_type: "service_override"
  org_id: "<org>"
  project_id: "<project>"
  filters:
    environment_id: "<env_id>"
    service_id: "<service_id>"   # optional - narrow to one service

Step 2: Get an override

Call MCP tool: harness:harness_get
Parameters:
  resource_type: "service_override"
  resource_id: "<override_id>"
  org_id: "<org>"
  project_id: "<project>"

Returns the full YAML configuration plus details about the impacted service, environment, and infrastructure.

Step 3: Create an override

environmentRef and type are always required. Other identifiers depend on the override type.

Environment-global override (variables)

Apply to all services in an environment:

Call MCP tool: harness:harness_create
Parameters:
  resource_type: "service_override"
  org_id: "<org>"
  project_id: "<project>"
  body:
    environmentRef: "staging"
    type: "ENV_GLOBAL_OVERRIDE"
    spec:
      variables:
        - name: SLACK_WEBHOOK_URL
          type: Secret
          value: <+secrets.getValue("staging_slack_webhook")>
        - name: LOG_LEVEL
          type: String
          value: "DEBUG"

Environment-service override (per-service variables)

Call MCP tool: harness:harness_create
Parameters:
  resource_type: "service_override"
  org_id: "<org>"
  project_id: "<project>"
  body:
    environmentRef: "prod"
    type: "ENV_SERVICE_OVERRIDE"
    serviceRef: "checkout_service"
    spec:
      variables:
        - name: FEATURE_FLAGS
          type: String
          value: "experimental_checkout=false"

Infra-service override (manifest override)

Call MCP tool: harness:harness_create
Parameters:
  resource_type: "service_override"
  org_id: "<org>"
  project_id: "<project>"
  body:
    environmentRef: "prod"
    type: "INFRA_SERVICE_OVERRIDE"
    serviceRef: "platform_api"
    infraIdentifier: "cluster_east"
    spec:
      manifests:
        - manifest:
            identifier: regional_overrides
            type: Values
            spec:
              store:
                type: Github
                spec:
                  connectorRef: github_connector
                  paths: ["values/east-region.yaml"]
                  branch: main

Cluster-service override (GitOps)

Call MCP tool: harness:harness_create
Parameters:
  resource_type: "service_override"
  org_id: "<org>"
  project_id: "<project>"
  body:
    environmentRef: "prod"
    type: "CLUSTER_SERVICE_OVERRIDE"
    serviceRef: "ai_inference"
    clusterIdentifier: "prod_gpu_cluster"
    spec:
      configFiles:
        - configFile:
            identifier: model_config
            spec:
              file: "configs/gpu-tuned.json"

YAML alternative

For complex overrides, pass yaml instead of spec:

Call MCP tool: harness:harness_create
Parameters:
  resource_type: "service_override"
  body:
    environmentRef: "prod"
    type: "ENV_SERVICE_OVERRIDE"
    serviceRef: "checkout_service"
    yaml: |
      overrides:
        variables:
          - name: API_TIMEOUT
            type: Number
            value: 30
        manifests:
          - manifest:
              identifier: tuning
              type: Values
              spec:
                store:
                  type: Github
                  spec:
                    connectorRef: gh
                    paths: ["overrides/checkout.yaml"]
                    branch: main

Step 4: Update an override

Same body shape as create. identifier is auto-injected from resource_id if missing.

Call MCP tool: harness:harness_update
Parameters:
  resource_type: "service_override"
  resource_id: "<override_id>"
  body:
    environmentRef: "prod"
    type: "ENV_SERVICE_OVERRIDE"
    serviceRef: "checkout_service"
    spec:
      variables:
        - name: FEATURE_FLAGS
          type: String
          value: "experimental_checkout=true"

Step 5: Delete an override

Call MCP tool: harness:harness_delete
Parameters:
  resource_type: "service_override"
  resource_id: "<override_id>"
  org_id: "<org>"
  project_id: "<project>"

Override spec fields

The spec object can contain any combination:

FieldPurpose
variables[]Variable overrides [{name, type, value}]. Type is String / Number / Secret.
manifests[]Manifest overrides (full ManifestConfigWrapper shape)
configFiles[]Config file overrides (full ConfigFileWrapper shape)
applicationSettingsAzure App Service application settings
connectionStringsAzure App Service connection strings

Examples

  • "Set LOG_LEVEL=DEBUG for all staging services" -> ENV_GLOBAL_OVERRIDE on staging with spec.variables
  • "Override checkout-service feature flags in prod" -> ENV_SERVICE_OVERRIDE with serviceRef
  • "Use east-region values when deploying to cluster-east" -> INFRA_SERVICE_OVERRIDE with infraIdentifier
  • "All services on prod-gpu-cluster need a custom CUDA config" -> CLUSTER_GLOBAL_OVERRIDE with clusterIdentifier
  • "Show me what overrides apply to checkout-service in prod" -> harness:harness_list service_override filters.environment_id=prod filters.service_id=checkout_service

Related skills

Prerequisites (skills typically run before this one):

Composes with (skills commonly invoked together):

Follow-ups (skills commonly chained after this one):

Performance Notes

  • List operations require environment_id - they don't paginate over all overrides at once.
  • Override evaluation order at deploy time: service spec -> ENV_GLOBAL -> ENV_SERVICE -> INFRA_GLOBAL -> INFRA_SERVICE -> CLUSTER_GLOBAL -> CLUSTER_SERVICE. More-specific overrides win.
  • Use harness:harness_describe(resource_type='service_override') for the live schema if any field is unclear.

Troubleshooting

  • "environment_id required" on list - service overrides are always scoped to an environment for listing.
  • type mismatch with required identifier - ENV_SERVICE_OVERRIDE requires serviceRef. INFRA_*_OVERRIDE requires infraIdentifier. CLUSTER_*_OVERRIDE requires clusterIdentifier. Service-specific types also need serviceRef.
  • Variable override not applying - check evaluation order; a more-specific override may be winning.
  • spec and yaml both passed - they're alternatives. The server may pick one inconsistently. Use one or the other, not both.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.