harness/harness-skills

# Manage Roles Skill

Manage Harness RBAC (Role-Based Access Control) via MCP v2 tools.

## MCP v2 Tools Used

| Tool | Resource Type | Operations |
|------|--------------|------------|
| `harness_list` | `role` | List all roles |
| `harness_get` | `role` | Get role details |
| `harness_create` | `role` | Create custom role |
| `harness_update` | `role` | Update custom role |
| `harness_delete` | `role` | Delete custom role |
| `harness_list` | `role_assignment` | List role assignments |

# Manage Users

Manage users, user groups, and service accounts via MCP.

## Instructions

### Step 1: List Users

```
Call MCP tool: harness_list
Parameters:
  resource_type: "user"
  search_term: "<name or email>"
```

# Custom AI Agents

Create and update Harness AI agent instances - standalone templates used as building blocks in pipelines for automated code, agentic workflows, and infrastructure tasks.

## Instructions

Follow this workflow to create or update an agent. **This is INTERACTIVE — show YAML for review and wait for confirmation before creating/updating the agent.**

### Phase 1: Check Existing Solutions First

**IMPORTANT: Before creating a new agent, check if an existing one can solve the use case.**

1. **List existing agents** — Call `harness_list` with `resource_type="agent"` (include `org_id` and `project_id` if scoped to a project)
   - Check if any system or custom agents already exist that can handle this task

# Create Agent Template Skill

Generate Harness Agent Template files for AI-powered automation agents.

## Instructions

1. **Identify the agent's purpose** - What task should the agent automate (code review, security scanning, test generation, documentation)?
2. **Define inputs and configuration** - What parameters does the agent need (repo, branch, connector, secrets)?
3. **Generate three files** - metadata.json (template metadata), pipeline.yaml (v1 syntax), and wiki.MD (user documentation)
4. **Validate consistency** - Ensure input references in pipeline.yaml match definitions in metadata.json

## Overview

Agent templates are modular pipeline definitions that encapsulate AI-powered automation. Each template produces three files:

# DBOPS Changeset Generation

Generate Liquibase database changesets from natural language descriptions,
anchored to a real schema and instance from the Harness DBOPS service.

## When to Use

When the user asks to:

- Create, add, modify, or drop tables, columns, indexes, constraints, or views as Liquibase changeset operations
- Generate a database migration or changeset
- Fix a failed migration or update an existing changeset
- Apply schema changes as Liquibase YAML

# Choose Metric

Recommend metrics for an FME experiment or feature-flag rollout: which is primary, which are guardrails/supporting, and which existing candidates are healthy enough to trust, judged against [what makes a good metric](../../../references/fme/metric-design.md#what-makes-a-good-metric). Related: `/manage-experiments` attaches metrics to experiments; `/create-metric` creates new metrics; `/instrument-metric` adds tracking calls.

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| Get flag | `harness_get` · `fme_feature_flag` · `params: { feature_flag_name }` | `harness get feature_flag <name> --json` |
| Get experiment | `harness_get` · `fme_experiment` · `params: { experiment_id }` | `harness get experiment <id> --json` |
| List metrics | `harness_list` · `fme_metric` · `filters: { traffic_type_id?, name?, limit }` · `compact: false` | `harness list metric --traffic-type-id <id> --name <substring> --json` |
| List traffic types | `harness_list` · `fme_traffic_type` · `compact: false` | `harness list traffic_type --json` |

# Cleanup Feature Flags

Remove one launched FME flag from application code and keep the branch FME serves today. The work ends with a PR. FME is read-only here; archive happens later in `manage-flag-lifecycle`.

Related: `discover-feature-flags` finds candidates (stale audit); `manage-flag-lifecycle` archives after the change deploys.

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| List environments | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| Get flag | `harness_get` · `fme_feature_flag` · `params: { feature_flag_name }` | `harness get feature_flag <flag> --json` |

# Create Experiment

Compatibility entrypoint kept for direct `/create-experiment` invocation. This
skill does not duplicate any workflow - it hands the entire creation flow to
[manage-experiments](../manage-experiments/SKILL.md)'s **Create experiment**
section and returns once that flow completes.

## Tools

Performs no operations of its own; it uses the operations of manage-experiments'
Create experiment flow, named in [tool-map.md](../../../references/fme/tool-map.md).

## Instructions

# Create Feature Flag

Create a new Harness FME feature flag and optionally its per-environment definitions with safe defaults, following the project's existing conventions. Related: `update-flag-targeting` (ramp), `manage-experiments` (A/B test).

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| List flags | `harness_list` · `fme_feature_flag` · `size: 50` · `compact: false` | `harness list feature_flag --json --limit 50` |
| Get flag | `harness_get` · `fme_feature_flag` · `params.feature_flag_name` | `harness get feature_flag <name> --json` |
| List environments | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| List traffic types | `harness_list` · `fme_traffic_type` · `compact: false` | `harness list traffic_type --json` |

# Create Metric

Create an FME metric definition, with guidance on what makes a good metric and what to measure. Resolves traffic types and events against real data and asks the user to select an owner instead of guessing IDs. Owner existence is validated by the API on creation/readback; the declared tools do not provide an owner-directory lookup. Design guidance lives in [metric-design.md](../../../references/fme/metric-design.md). Related: `/manage-experiments` attaches metrics; `/instrument-metric` adds tracking calls.

For every phase marked **Stop condition**, see [stop-conditions.md](references/stop-conditions.md) before improvising.

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| List metrics | `harness_list` · `fme_metric` · `filters: { name?, traffic_type_id?, limit }` · `compact: false` | `harness list metric --name <substring> --traffic-type-id <id> --json` |
| List traffic types | `harness_list` · `fme_traffic_type` · `compact: false` | `harness list traffic_type --json` |

# Discover Feature Flags

Audit Harness FME feature flags across a project: list all flags with metadata, show rollout status per environment, find stale flags, or search rule conditions structurally. Read-only. Never writes. Related: `explain-flag` (single flag), `cleanup-feature-flags` (code removal), `manage-flag-lifecycle` (archive).

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| List environments | `harness_list` · `fme_environment` · `filters: { offset: 0, limit: 100 }` · `compact: false` | `harness list fme_environment --json` |
| List rollout statuses | `harness_list` · `fme_rollout_status` · `filters: { offset: 0, limit: 100 }` · `compact: false` | `harness list rollout_status --json` |
| List flags | `harness_list` · `fme_feature_flag` · `size: 50` · `filters: { name?, tags?, rollout_status_id?, offset? }` · `compact: false` | `harness list feature_flag [--search <name>] [--status <ACTIVE\|ARCHIVED>] --limit 50 --json` |
| Get flag | `harness_get` · `fme_feature_flag` · `params.feature_flag_name` | `harness get feature_flag <name> --json` |

# Explain Flag

Answer "what does this flag do right now" for one named flag: its purpose, what serves by default, and how targeting differs (or doesn't) across environments - without touching anything.

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| List environments | `harness_list` · `fme_environment` · `filters: { offset: 0, limit: 100 }` · `compact: false` | `harness list fme_environment --json` |
| List flags | `harness_list` · `fme_feature_flag` · `size: 50` · `filters: { name, offset: 0 }` · `compact: false` | `harness list feature_flag --search <substring> --json` |
| Get flag | `harness_get` · `fme_feature_flag` · `params: { feature_flag_name }` | `harness get feature_flag <name> --json` |
| Get definition | `harness_get` · `fme_feature_flag_definition` · `params: { feature_flag_name, environment_id }` | `harness get feature_flag:definition <flag> --env <env-id> --json` |

# Feature Flag Onboarding

Orchestrate a new application's first end-to-end FME setup: confirm scope, pick a safe environment, detect the codebase, delegate code integration, then prove two distinct treatments actually run live. This skill sequences and verifies; it does not re-implement flag creation, code wiring, or targeting changes — those live in `/create-feature-flag`, `/instrument-feature-flag`, and `/update-flag-targeting`.

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md). All writes are delegated to the linked skills — this skill only reads.

| Operation | MCP | CLI |
|-----------|-----|-----|
| List environments | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| List flags | `harness_list` · `fme_feature_flag` · `size: 50` · `compact: false` | `harness list feature_flag --json --limit 50` |
| Get flag | `harness_get` · `fme_feature_flag` · `params.feature_flag_name` | `harness get feature_flag <name> --json` |
| Get definition | `harness_get` · `fme_feature_flag_definition` · `params: { feature_flag_name, environment_id }` | `harness get feature_flag:definition <flag> --env <env-id> --json` |

# FME Pipeline

Compose Harness pipelines with FmeFlag* / FmeSegment* steps for flag rollout scenarios. Generates tailored pipelines — progressive ramp, multi-environment promotion, beta cohorts, config promotion, bootstrap, retirement, segment sync, and test targeting — rather than a single fixed template.

**Related:** Direct flag operations → `/update-flag-targeting`. Experiments → `/manage-experiments`, `/review-experiment-results`. Flag creation → `/create-feature-flag`. Lifecycle → `/manage-flag-lifecycle`. Segments → `/manage-segments`. State → `/explain-flag`. Discovery → `/discover-feature-flags`. Code removal → `/cleanup-feature-flags`. Running → `/run-pipeline`. Triggers → `/create-trigger`.

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| **List environments** | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| **Get flag** | `harness_get` · `fme_feature_flag` · `params: { feature_flag_name }` | `harness get feature_flag <name> --json` |

# Instrument Feature Flag

Skill identifier: `instrument-feature-flag`. Gate application code behind an existing FME flag: inspect the real app first, prefer or design a small customer-extensible wrapper, get it approved, implement the minimal edits, and test at the wrapper and call-site boundary. Related: `/create-feature-flag` (new flag), `/update-flag-targeting` (missing/insufficient targeting), `/feature-flag-onboarding` (first-time setup, which delegates here for code).

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md). This skill only reads Harness flag state for the selected environment — flag/definition writes are delegated to `/create-feature-flag` and `/update-flag-targeting`.

| Operation | MCP | CLI |
|-----------|-----|-----|
| List flags | `harness_list` · `fme_feature_flag` · `size: 50` · `compact: false` | `harness list feature_flag --json --limit 50` |
| Get flag | `harness_get` · `fme_feature_flag` · `params.feature_flag_name` | `harness get feature_flag <name> --json` |
| List environments | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| List traffic types | `harness_list` · `fme_traffic_type` · `compact: false` | `harness list traffic_type --json` |

# Instrument Metric

Wire up the `track()` call an FME metric needs, then verify the event is actually arriving — don't declare success on code changes alone. Key = the same key `getTreatment` uses (attribution fact); value units must match the metric's `format` (ms vs s, dollars vs cents) — a wrong unit gives silently wrong results. Related: `/create-metric` creates metrics; `/choose-metric` recommends which metrics to use.

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| Get metric | `harness_get` · `fme_metric` · `params: { metric_id }` | `harness get metric <id> --json` |
| Get event type | `harness_get` · `fme_event_type` · `params: { event_type_id }` | `harness get event_type <event-name> --json` |

## Instructions

# Manage Experiments

Create, update, or delete FEATURE_FLAG experiments. AI_CONFIG mutation workflows are not implemented here; use read-only results inspection or a separately supported workflow. Orchestrates decisions and delegates
metric selection, flag setup, and results interpretation to specialist skills.

Related: [choose-metric](../choose-metric/SKILL.md) (metric selection),
[create-metric](../create-metric/SKILL.md) (metric creation),
[instrument-metric](../instrument-metric/SKILL.md) (event wiring),
[review-experiment-results](../review-experiment-results/SKILL.md) (results),
[create-feature-flag](../create-feature-flag/SKILL.md),
[update-flag-targeting](../update-flag-targeting/SKILL.md).

## Tools

# Manage Flag Lifecycle

Manage metadata, archive readiness, archive/unarchive, and deletion for Harness FME feature flags. Related: `update-flag-targeting` (targeting), `discover-feature-flags` (stale flags), `cleanup-feature-flags` (code removal).

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| List environments | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| List flags | `harness_list` · `fme_feature_flag` · `size: 50` · `filters: { name?, tags?, rollout_status_id?, offset? }` · `compact: false` | `harness list feature_flag --search <name> --status <ACTIVE\|ARCHIVED> --json` (CLI has no `--tags`/`--rollout-status-id`; filter client-side on the full JSON, which MCP's `tags`/`rollout_status_id` filters do server-side) |
| Get flag | `harness_get` · `fme_feature_flag` · `params.feature_flag_name` | `harness get feature_flag <name> --json` |
| Update flag | `harness_update` · `fme_feature_flag` · `params.feature_flag_name` · `body: { description?, tags?, owners?, rolloutStatus? }` | `harness update feature_flag <name> --set description="..." --set rollout_status=<uuid>` (CLI field id is `rollout_status`; `--set rolloutStatus.id=` doesn't match the spec's mutable field id and fails) |

# Manage Segments

Manage metadata for **STANDARD**, **LARGE**, and **RULE_BASED** segments, STANDARD membership, and approved RULE_BASED editor changes. Every mutation requires a complete reference-impact check and explicit approval. LARGE bulk membership operations are outside this skill's scope.

## Tools

Works through Harness MCP or CLI with equivalent scope, confirmation and verification requirements. Discover exact CLI action syntax through command help; use [tool-map.md](../../../references/fme/tool-map.md#segment-type-capabilities) for mappings. `STANDARD` in metadata examples stands for the selected type; definition/key rows apply only to STANDARD.

| Operation | MCP | CLI |
|-----------|-----|-----|
| List traffic types | `harness_list` · `fme_traffic_type` · `compact: false` | `harness list traffic_type --json` |
| List environments | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| List flags | `harness_list` · `fme_feature_flag` · `size: 50` · `compact: false` | `harness list feature_flag --json --limit 50` |
| List experiments | `harness_list` · `fme_experiment` · `filters: { parent_type: "FEATURE_FLAG", parent_name, environment_id, status: ["ACTIVE", "PAUSED"], offset: 0, limit: 100 }` · `compact: false` | `harness list experiment --parent-type FEATURE_FLAG --parent-name <flag> --env <env-id> --status ACTIVE --json`, then PAUSED; fully paginate both |

# Review Experiment Results

Explain an FME experiment's outcome in plain language: whether there's a winner,
why or why not, how guardrail metrics were affected, and any data-quality
caveats - with underlying statistics available on request.

Related: [manage-experiments](../manage-experiments/SKILL.md) (experiment
changes), [choose-metric](../choose-metric/SKILL.md) (metric selection).

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |

# Update Flag Targeting

Change how an existing Harness FME feature flag serves traffic in one or more environments. **Always read the current definition first**, then merge-patch only what changes. Show a diff of just what changed and use plain-language before/after to describe who gets what.

Related: Segment membership changes are `/manage-segments`; deep flag analysis (impact, dependencies, single-flag state) is `/explain-flag`. Reverse-lookup scans (dependents, segment usage) are in [tool-map.md](../../../references/fme/tool-map.md#reverse-lookup-scans).

## Tools

Works through the Harness MCP server or the Harness CLI; names are from [tool-map.md](../../../references/fme/tool-map.md).

| Operation | MCP | CLI |
|-----------|-----|-----|
| List environments | `harness_list` · `fme_environment` · `compact: false` | `harness list fme_environment --json` |
| List flag definitions | `harness_list` · `fme_feature_flag_definition` · `params: { feature_flag_name }` · `filters: { offset: 0, limit: 100 }` · `compact: false` | `harness list feature_flag:definition <flag> --json` |

# Create Connector

Generate Harness Connector YAML and create/test via MCP.

## Instructions

1. **Identify connector type** - Determine what service to connect (Git provider, cloud provider, container registry, Kubernetes cluster)
2. **Generate YAML** using the templates below, filling in credentials and endpoint details
3. **Create via MCP** using `harness_create` with resource_type `connector`
4. **Test connection** using `harness_execute` with action `test_connection` to verify

## Git Connectors

### GitHub

# Create Environment

Generate Harness Environment YAML and push to Harness via MCP.

## Instructions

1. **Determine environment type** - `PreProduction` for dev/staging/QA, `Production` for live environments
2. **Define variables and overrides** - Environment-specific config values and manifest overrides
3. **Generate YAML** using the structure below
4. **Create via MCP** using `harness_create` with resource_type `environment`

## Environment Structure

```yaml

# Create Infrastructure

Generate Harness Infrastructure Definition YAML and push via MCP.

## Instructions

1. **Identify infrastructure type** - KubernetesDirect, KubernetesGcp (GKE), KubernetesAzure (AKS), ECS, or ServerlessAwsLambda
2. **Ensure prerequisites exist** - The environment and cloud/cluster connector must be created first
3. **Generate YAML** using the templates below, referencing the correct connector and environment
4. **Create via MCP** using `harness_create` with resource_type `infrastructure`

## Infrastructure Types

### KubernetesDirect

# Create Secret Skill

Generate Harness Secret definitions and manage secrets via MCP v2 tools.

## MCP v2 Tools Used

| Tool | Resource Type | Purpose |
|------|--------------|---------|
| `harness_list` | `secret` | List existing secrets |
| `harness_get` | `secret` | Get secret metadata (not the value) |
| `harness_create` | `secret` | Create a new secret |
| `harness_update` | `secret` | Update secret metadata or value |
| `harness_delete` | `secret` | Delete a secret |
| `harness_describe` | `secret` | Discover secret resource schema |

# Create Service

Generate Harness Service YAML and push to Harness via MCP.

## Instructions

1. **Detect service type from codebase** (if source code is available) - Scan the project for deployment manifests to auto-select the correct `serviceDefinition.type` and manifest configuration:
   - `k8s/`, `kubernetes/`, `manifests/` with YAML files → `Kubernetes` with `K8sManifest`
   - `kustomization.yaml` → `Kubernetes` with `Kustomize`
   - `Chart.yaml`, `charts/`, `helm/` → `NativeHelm` with `HelmChart`
   - `task-definition.json` → `ECS` with `EcsTaskDefinition`
   - `serverless.yml` / `template.yaml` (SAM) → `ServerlessAwsLambda`
   - `function.json` (Azure) → `AzureWebApp`
   - `.NET` + Windows → `WinRm`

# AI Operations

Configure AI-powered predictive failure analysis and intelligent alert correlation using Harness AIDA.

## Instructions

### Step 1: Establish Scope

Confirm the user's org, project, service, and observability stack.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "project"

# Analyze Costs

Analyze cloud costs and identify savings using Harness Cloud Cost Management (CCM) via MCP.

## Instructions

### Step 1: Get Cost Overview

```
Call MCP tool: harness_get
Parameters:
  resource_type: "cost_account_overview"
```

# Audit Report Skill

Generate audit reports and compliance trails using Harness MCP v2 tools.

## MCP v2 Tools Used

- `harness_list` with `resource_type: "audit_event"` -- list audit events with filters
- `harness_describe` with `resource_type: "audit_event"` -- discover available filters and fields

Audit events are **read-only**. You can list and filter them but cannot create, update, or delete them.

## Instructions

### Step 1: Discover Available Filters

# Chaos Code Risk Scan

Find resilience risks in a repository that a chaos experiment can turn into a
pass/fail result, and send them to Harness as a `CodeRepository` risk scan.
Harness then scores them, adds them to the scan report and, for modules linked
to a chaos service, recommends experiments.

The work is split so evidence cannot be invented: scripts extract facts and
verify snippets; you only map verified facts to rules and write the
explanation; the server re-validates everything.

One prompt runs the whole flow. Do not ask the user to choose an org, project, module,
service, rule, or to approve a create or a submit. The only stops are a missing
`origin` remote, or a tool error that a single retry does not clear. Report those

# Chaos DR Test

Create and edit Harness DR Test pipelines — pipelines with a `DRTest` stage
containing `ChaosFault`, `ChaosProbe`, `ChaosAction`, and `Chaos` steps — via MCP.

MANDATORY — Tool Result Verification:
- NEVER claim a tool call succeeded without an explicit success response from the tool.
- NEVER fabricate, assume, or pre-empt tool results. If you called a tool and did not receive a confirmed result, say so and retry.
- When a tool returns a review/elicitation prompt (e.g., "Waiting for user to review before update..."), the user's approval does NOT mean the operation completed. You MUST wait for the follow-up tool response confirming execution before reporting success.
- If the tool response is ambiguous or missing, tell the user honestly and offer to retry.

## Scope Rules

Follow [`references/scope-establishment.md`](../../../references/scope-establishment.md) for establishing org/project scope before calling `harness_list`, `harness_get`, `harness_create`, `harness_update`, or `harness_execute` in this skill:

# Chaos Experiment

Create, edit, and answer reference questions about Harness Chaos Experiments — faults,
probes, actions, and the underlying `ChaosExperiment` manifest — via MCP.

MANDATORY — Tool Result Verification:
- NEVER claim a tool call succeeded without an explicit success response from the tool.
- NEVER fabricate, assume, or pre-empt tool results. If you called a tool and did not receive a confirmed result, say so and retry.
- When a tool returns a review/elicitation prompt (e.g., "Waiting for user to review before update..."), the user's approval does NOT mean the operation completed. You MUST wait for the follow-up tool response confirming execution before reporting success.
- If the tool response is ambiguous or missing, tell the user honestly and offer to retry.

## Instructions

### Step 1: Establish scope

# Create Policy

Create OPA governance policies for Harness Software Supply Chain Assurance (SCS) via MCP.

## Instructions

### Step 1: Identify Policy Requirements

Determine what the policy should enforce:
- What entity type is the policy targeting? (pipeline, service, environment, feature flag, etc.)
- What is the enforcement action (warn, deny)?
- What scope should the policy apply to?
- What action triggers the policy? (onrun, onsave, onstep, etc.)

# Deployment Readiness

Assess deployment readiness, analyze environment drift, and make data-driven canary rollout decisions using Harness MCP.

## Instructions

### Step 1: Establish Scope

Confirm the service, target environment, and deployment type.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "service"

# DORA Metrics

Generate DORA metrics reports using Harness Software Engineering Insights (SEI) via MCP.

## Instructions

All DORA metrics are served by a single resource type: `sei_dora_metric`. Pass the `metric` parameter to select the variant:

- `deployment_frequency`
- `deployment_frequency_drilldown`
- `lead_time`
- `change_failure_rate`
- `change_failure_rate_drilldown`
- `mttr`

# GitOps Status

Monitor GitOps application health and manage sync operations via MCP.

## Instructions

### Step 1: Overview Dashboard

```
Call MCP tool: harness_get
Parameters:
  resource_type: "gitops_dashboard"
```

# Incident Response

Correlate incidents with deployments, assess blast radius, and generate postmortem documents using Harness MCP.

## Instructions

### Step 1: Establish Scope

Confirm the affected service, environment, and incident details.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "service"

# Manage IDP

Create service catalog templates, self-service workflows, documentation, ADRs, and developer onboarding flows in Harness Internal Developer Portal.

## Instructions

### Step 1: Establish Scope

Confirm the user's org and project context.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "project"

# Manage SLOs / SRM

> **Limitation:** The MCP server does not currently expose `slo`, `slo_alert`, or
> `monitored_service` resource types. SLO definitions, burn-rate alerts, and monitored-service
> configuration must be created and edited via the Harness UI under
> **Service Reliability Management**. This skill covers the parts of the SRM workflow that
> *are* supported via MCP: deployment correlation, on-call handover reports, and operational
> runbooks.

## What this skill can do via MCP

| Workflow | Supported today |
|---|---|
| Define an SLO or SLI | ❌ Use the Harness UI |

# Optimize Pipeline

Analyze and optimize Harness CI/CD pipeline performance through parallel testing, caching, bottleneck analysis, and monorepo strategies.

## Instructions

### Step 1: Establish Scope

Confirm the service, pipeline, and current performance baseline.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "pipeline"

# PR Analysis

Analyze pull request pipeline impact, run security-focused reviews, and track PRs from merge to production deployment.

## Instructions

### Step 1: Establish Scope

Confirm the service, repository, and PR details.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "pipeline"

# Scorecard Review

Review service maturity and compliance scorecards using Harness Internal Developer Portal (IDP) via MCP.

## Instructions

### Step 1: List Catalog Entities

```
Call MCP tool: harness_list
Parameters:
  resource_type: "idp_entity"
  org_id: "<organization>"
  project_id: "<project>"

# Security Report

Generate security compliance reports using Harness Software Supply Chain (SCS) and Security Testing Orchestration (STO) via MCP.

## Instructions

### Step 1: List Vulnerabilities

```
Call MCP tool: harness_list
Parameters:
  resource_type: "security_issue"
  org_id: "<organization>"
  project_id: "<project>"

# SEI Analytics

Configure sprint analytics, investment allocation, capacity forecasting, and release readiness assessments in Harness Software Engineering Insights.

## Instructions

### Step 1: Establish Scope

Confirm the user's org, team, and tracking period.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "project"

# Template Usage Skill

Track template dependencies and usage across Harness via MCP v2 tools.

## MCP v2 Tools Used

| Tool | Resource Type | Purpose |
|------|--------------|---------|
| `harness_search` | `template` | Find templates by keyword across orgs/projects |
| `harness_list` | `template` | List templates, filter by scope |
| `harness_get` | `template` | Get template details, versions, and usage references |
| `harness_describe` | `template` | Discover template resource schema and fields |

Templates are managed via `harness_list` and `harness_get` only. For creating or updating templates, use the `/create-template` skill.

# Create Pipeline

Generate Harness v0 Pipeline YAML and optionally push to Harness via MCP.

## Instructions

1. **Analyze codebase** (if source code is available) - Scan the project to auto-detect language, build tools, test frameworks, containerization, deployment manifests, and target infrastructure. Use the detection tables and decision tree in `references/codebase-analysis.md` to determine:
   - Language and runtime version (package.json → Node.js, go.mod → Go, pom.xml → Java, etc.)
   - Build commands and base images
   - Test framework and report format (Jest → JUnit, pytest → JUnit XML, etc.)
   - Linter and formatter (ESLint, Prettier, Ruff, etc.)
   - Dockerfile presence and registry type (Docker Hub, ECR, GCR, ACR)
   - Deployment manifests → Harness service/deployment type (k8s manifests → Kubernetes, Chart.yaml → NativeHelm, task-definition.json → ECS, serverless.yml → ServerlessAwsLambda)
   - Existing CI/CD configs for migration (GitHub Actions, Jenkins, GitLab CI, etc.)

# Create Pipeline v1

Generate Harness v1 simplified Pipeline YAML and optionally push to Harness via MCP.

**Alpha: This skill is currently in internal testing only.**

## Instructions

1. **Confirm v1 format** - User must specifically want v1 syntax. Default to v0 (`/create-pipeline`) if unclear.
2. **Clarify requirements** - Pipeline type (CI, CD, or both), language/framework, deployment target
3. **Consult the spec reference** - Use `references/v1-spec-schema.md` for the complete v1 schema, step types, action catalog, and examples
4. **Select native actions** - Always prefer native action and template steps over `run:` steps. Consult `references/native-actions.md` for the full mapping. Key rules:
   - Docker build/push → use `template: uses: buildAndPushToDocker` / `buildAndPushToECR` / `buildAndPushToGAR` (never `run: docker build && docker push`)
   - K8s deploy → use `action: uses: kubernetes-rolling-deploy` or `template: uses: k8sRollingDeployStep` (never `run: kubectl apply`)

# Create Template

Generate Harness v0 Template YAML for reusable components and push via MCP.

## Instructions

1. **Determine template type** - Step, Stage, Pipeline, or StepGroup
2. **Identify reusable parameters** - Mark configurable fields with `<+input>` for runtime inputs
3. **Generate YAML** using the structure below with a unique `versionLabel`
4. **Create via MCP** using `harness_create` with resource_type `template`
5. **Verify creation** using `harness_list` with resource_type `template`

## Template Types

# Create Trigger

Generate Harness Trigger YAML and push to Harness via MCP.

## Instructions

1. **Identify trigger type** - Webhook (Git events), Scheduled (cron), Artifact (registry updates), or Manifest (Helm chart updates)
2. **Configure conditions** - Branch filters, payload conditions, cron expression, or artifact path
3. **Generate YAML** using the templates below, referencing the target pipeline
4. **Create via MCP** using `harness_create` with resource_type `trigger`
5. **Verify webhook registration** - For webhook triggers, confirm the webhook is registered in the Git provider

## Trigger Types

# Debug Pipeline

Diagnose pipeline executions and suggest fixes via MCP.

## Instructions

### Step 1: Diagnose Execution (Preferred)

Use the dedicated diagnosis tool. It accepts an execution_id, pipeline_id (auto-fetches latest execution), or a Harness URL:

```
Call MCP tool: harness_diagnose
Parameters:
  pipeline_id: "<pipeline_identifier>"   # or execution_id or url

# Manage Freeze Windows

Create and toggle Harness deployment freeze windows via MCP. A freeze window blocks pipeline executions within a time window so you can enforce change freezes for releases, holidays, or maintenance.

## MCP Tools Used

| Tool | Resource Type | Purpose |
|------|---------------|---------|
| `harness_list` | `freeze_window` | List project freeze windows, filter by status / time / keyword |
| `harness_get` | `freeze_window` | Get a single freeze window by identifier |
| `harness_create` | `freeze_window` | Create a freeze window from YAML |
| `harness_update` | `freeze_window` | Replace an existing freeze window's YAML definition |
| `harness_delete` | `freeze_window` | Delete a freeze window |
| `harness_execute` (action: `toggle_status`) | `freeze_window` | Enable / disable one or more freeze windows in bulk |

# Migrate Pipeline

Convert Harness pipelines from v0 to v1 simplified format via MCP.

## Instructions

### Step 1: Fetch Current v0 Pipeline

```
Call MCP tool: harness_get
Parameters:
  resource_type: "pipeline"
  resource_id: "<pipeline_identifier>"
  org_id: "<organization>"

# Run Pipeline

Execute and monitor Harness pipeline runs via MCP.

## Instructions

### Step 1: Find the Pipeline

```
Call MCP tool: harness_search
Parameters:
  query: "<user's pipeline name or keyword>"
  resource_types: ["pipeline"]
  compact: true

# Create SBOM

Add an **SBOM Orchestration** (`SscaOrchestration`) step to an existing Harness pipeline for a
container image or code repository. This skill only works with **existing pipelines** — do not
create standalone SBOM pipelines.

**Supported stages:** SBOM Orchestration runs in **CI**, **CD** (`Deployment`), and **Security**
(`Security`) stages. Show stage type in Phase 2 and offer placement options that match the stage
type (see `references/interactive-wizard-flow.md`).

Guide the user through a **step-by-step interactive wizard** (same UX as `/configure-repo-scan`):
one decision per turn, recommended options marked, pipeline structure
shown after fetch, then confirm before `harness_update`.

# Enforce SBOM

Add an **SBOM Policy Enforcement** (`SscaEnforcement` / `CdSscaEnforcement`) step to an existing
Harness pipeline. The step verifies SBOM attestations (when enabled) and evaluates SBOM OPA policy
sets against the artifact's bill of materials.

This skill only works with **existing pipelines** — do not create standalone enforcement-only pipelines.

**Prerequisites:** An SBOM must already exist for the artifact (typically from `SscaOrchestration` via
`/create-sbom` or SBOM ingestion). SBOM **policy sets** must exist (`/create-policy`).

**Supported stages:** CI, CD (`Deployment`), and Security — same as SBOM Orchestration. CD requires a
**containerized step group** with container-based execution.

# Manage Artifacts

Configure private artifact registries, security scanning policies, and cross-region replication in Harness Artifact Registry.

## Instructions

### Step 1: Establish Scope

Confirm the user's org, project, and artifact format requirements.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "project"

# Manage CDE

Configure on-demand Cloud Development Environments with workspace templates, auto-hibernation, and cost controls in Harness.

## Instructions

### Step 1: Establish Scope

Confirm the user's org, project, team, and technology stack.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "project"

# Manage Delegates

Monitor delegate health and manage registration tokens via MCP.

## Instructions

### Step 1: List Delegates

List all delegates in the account to check health and connectivity:

```
Call MCP tool: harness_list
Parameters:
  resource_type: "delegate"

# Manage IaCM

Configure Terraform workspaces, drift detection, change approval workflows, and cost estimation in Harness Infrastructure as Code Management.

## Instructions

### Step 1: Establish Scope

Confirm the user's org, project, cloud provider, and environments.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "project"

# Manage Pull Requests

Manage Harness Code pull requests, reviewers, comments, checks, and activity via MCP.

## MCP Tools Used

| Tool | Resource Type | Purpose |
|------|---------------|---------|
| `harness_list` | `pull_request` | List PRs in a repo, filter by state |
| `harness_get` | `pull_request` | Get PR details by number |
| `harness_create` | `pull_request` | Open a new PR |
| `harness_update` | `pull_request` | Update PR title / description / state |
| `harness_execute` (action: `merge`) | `pull_request` | Merge a PR (merge/squash/rebase/fast-forward) |
| `harness_list` | `pr_reviewer` | List reviewers on a PR |

# Manage Supply Chain

Configure SBOM generation, artifact signing, supply chain policy enforcement, and SLSA provenance tracking in Harness SSCA.

## Instructions

### Step 1: Establish Scope

Confirm the user's org, project, service, and build tool.

```
Call MCP tool: harness_list
Parameters:
  resource_type: "project"

# Approve Exemption

Approve one or more **Pending** STO security exemptions. This skill covers the approval
workflow after someone has requested an exemption (see `/exempt-vuln` for creation).

**Pending scope is only `PROJECT`, `PIPELINE`, or `TARGET`.** Exemptions are *requested* at
project, pipeline, or target scope only (All Issues → project; Vulnerabilities tab → project,
pipeline, or target). STO does not create pending requests at org or account scope — those
wider scopes exist only **after** elevation on approve (`body.scope` `ORG` or `ACCOUNT`). You
will not see `scope: ORG` or `scope: ACCOUNT` on rows from `status: Pending` in normal flows.
If a list row shows `ORG`/`ACCOUNT`, it is already approved/widened (re-approve or a different
workflow), not a fresh pending request this skill targets.

Harness exposes two different "scope" ideas — do not mix them up:

# Configure Agent PR Attestation

Sets up a `PostToolUse` hook that signs and uploads an in-toto attestation
to the Harness Evidence Vault every time an AI coding agent creates a PR/MR.

## Instructions

Follow these steps in exact order. Do NOT skip steps or reorder them.

### Step 1: Check Prerequisites

Run these checks and report what's missing. Do not proceed until all are installed.

```bash

# Configure Container Scan

Add a container image scanning step to an existing Harness pipeline using the native `HarnessSCA` STO scanner.

## Instructions

### Step 1: Establish Scope and Pipeline Context

Ask for org, project, and pipeline identifier if not already known. This skill only works with existing pipelines.

```
Call MCP tool: harness_get
Parameters:
  resource_type: "pipeline"

# Configure DAST Scan

Add a Dynamic Application Security Testing (DAST) step to an existing Harness pipeline using Harness STO scanners. DAST scanners test running application instances for security vulnerabilities at runtime.

## Instructions

### Step 1: Establish Scope and Pipeline Context

Ask for org, project, and pipeline identifier if not already known. This skill only works with existing pipelines.

```
Call MCP tool: harness_get
Parameters:
  resource_type: "pipeline"

# Configure Repo Scan

Add code scanning steps to existing Harness pipelines using STO security scanners.

## Instructions

### Step 1: Establish Scope and Pipeline Context

Ask the user for the organization, project, and pipeline identifier if not already known. This skill only works with existing pipelines.

Once you have the identifiers, fetch the pipeline definition:

```
Call MCP tool: harness_get

# Configure Secret Scan

Add secret detection scanning steps to existing Harness pipelines using Harness STO. Scans code repositories for exposed credentials, API keys, tokens, and other sensitive information.

## Instructions

### Step 1: Establish Scope and Pipeline Context

Ask the user for the organization, project, and pipeline identifier if not already known. This skill only works with existing pipelines.

```
Call MCP tool: harness_get
Parameters:
  resource_type: "pipeline"

# Enforce SLSA

Add an **SLSA Verification** (`SlsaVerification`) step to an existing Harness pipeline. The step
verifies SLSA provenance attestations (when enabled) and optionally evaluates OPA policy sets against
provenance data.

This skill only works with **existing pipelines** — do not create standalone verification-only pipelines.

**Prerequisites:** SLSA provenance must already exist for the artifact (typically from a `provenance`
step via `/generate-slsa` — UI label SLSA Generation). Optional **policy sets** for provenance
enforcement (`/create-policy`, `harness_list` `policy_set`).

**Supported stages:** CI, CD (`Deployment`), and Security. CD requires a **containerized step group**.
Unlike SBOM enforcement, CI and CD both use **`SlsaVerification`** (no separate CD step type).

# Exempt Vulnerability

Create a security exemption (waiver) for one or more Harness STO vulnerabilities. STO has two
places a user can request an exemption from, and each one allows a different set of scopes:

| Where the user is in the Harness UI | Scopes they can request |
|---|---|
| **Vulnerabilities tab** of a specific pipeline execution | This Project, This Pipeline, This Target |
| **All Issues** page (the project-wide baseline) | This Project only |

The reason for the difference is simple: rows on the All Issues page are aggregated across
executions and don't carry an `execution_id`, so the backend has no pipeline or target context
to attach a narrower scope to. Org- and Account-scoped exemptions are not created here at all;
they're produced later by approving an existing exemption at a higher scope (via

# Generate SLSA

Add a **SLSA Generation** step to an existing Harness pipeline to generate SLSA provenance and
optionally attest/sign the `.att` file in the container registry. Pipeline YAML uses
`type: provenance` (UI label: SLSA Generation; do not use `SlsaGeneration` — API rejects it).

This skill only works with **existing pipelines** — do not create standalone SLSA-only pipelines.

**Prerequisites:** Image must be built and pushed (or available in registry) before SLSA runs.
Key-based attestation requires Cosign key pair secrets (`/create-secret`). Harness Cloud builds
enable SLSA Level 3 provenance when using hosted infrastructure.

Guide the user through a **step-by-step interactive wizard** (same UX as `/configure-repo-scan`):

# Sign Artifact

Add an **Artifact Signing** (`SscaArtifactSigning`) step to an existing Harness pipeline. The step
retrieves an artifact from a registry or local workspace, signs it with Cosign, and optionally pushes
the `.sig` signature file back to the registry.

This skill only works with **existing pipelines** — do not create standalone signing-only pipelines.

**Prerequisites:** Container images must be built and pushed (or available in registry) before signing.
Key-based signing requires Cosign key pair file secrets (`/create-secret`). Harness docs note that
**Deploy-stage signing is not yet supported** — prefer CI or Security stages.

Guide the user through a **step-by-step interactive wizard** (same UX as `/verify-sign`):

# Verify Sign

Add an **Artifact Verification** (`SscaArtifactVerification`) step to an existing Harness pipeline.
The step verifies Cosign signatures on artifacts — typically immediately after `SscaArtifactSigning`.

This skill only works with **existing pipelines** — do not create standalone verification-only pipelines.

**Prerequisites:** Artifact must already be signed (typically via `/sign-artifact` /
`SscaArtifactSigning`). Key-based verify requires the Cosign **public** key file secret matching the
signing private key (`/create-secret`). If signing did not upload `.sig` to the registry, Harness
pulls the signature from its database during verification.

**Supported stages:** CI, Security, and CD (`Deployment` in containerized step group before deploy).

# Write HQL

Write, validate, and run HQL queries against Harness data, primarily for dashboard widget creation. This skill teaches the query language, the type discovery workflow, and the validation loop. For non-dashboard multi-query analysis (overview, drill-down, synthesis), also follow [analysis-workflow.md](references/analysis-workflow.md).

## Instructions

### Step 0: Learn HQL syntax

Read the companion files in this skill directory before writing any queries:
- **`reference.md`** — practical examples, type casting rules, JOIN syntax, anti-patterns.
- **`references/patterns/*.md`** — worked query patterns per question shape (failure-diagnosis, build-time-analysis, bottleneck-analysis, flakiness, retry-signals, intermittent-vs-consistent, lint-first, batch).
- **`references/entity-reference/ci.md`** — CI-native field discipline (`stage_build_time` vs `duration`, `start_timestamp` vs `start_ts`).

Fetch the live grammar via `harness_get(resource_type='kg_grammar')` only when the reference files do not cover the syntax you need.