Chaos Dr Test

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 for establishing org/project scope before calling harness_list, harness_get, harness_create, harness_update, or harness_execute in this skill:

• Parse org / project from the user's message or a pasted Harness UI URL first.
• Ask only for what is missing — do not re-ask for values already known.
• Restate the active scope before the first mutating call.
• Never invent a default org/project. If either is missing, ask the user to select it before calling a project-scoped resource; do not fall back to account scope silently.

Instructions

YAML Output Conventions

Output style — always emit block-style YAML for pipeline manifests (each key on its own line, list items on their own line with -, children indented). The YAML examples shown in references/components.md (Series + Parallel Steps, Full DRTest Pipeline, Chaos step) appear as minified JSON purely for token efficiency — JSON parses identically to YAML, so the examples remain authoritative for field names and structure, but the pipeline YAML you produce MUST be block-style matching the canonical scaffold below. Never put JSON in the request body for harness_create or harness_update pipeline YAML.

DR Test Pipeline Rules

Identifying a DR Test Pipeline

Two ways to verify a pipeline is a DR Test:

1. Check pipeline tags — DR Test pipelines have module: drtest in their top-level tags. Additionally, stages within the pipeline have type: DRTest.
2. List via MCP — Call harness_list(resource_type="chaos_dr_test", org_id="<org_id>", project_id="<project_id>") to get all DR Test pipelines in the project. If the pipeline appears in this list, it is a DR Test. Pass org_id/project_id using the active scope (see Scope Rules above).

DRTest Stage and Steps

Chaos-related steps (ChaosFault, ChaosProbe, ChaosAction, Chaos) can ONLY be added to a stage with type: DRTest. They are not valid in any other stage type.

DRTest Pipeline — Created via MCP with Empty Steps

When a user creates a DR Test via harness_create(resource_type="chaos_dr_test", org_id="<org_id>", project_id="<project_id>", body={"name": "...", "identifier": "..."}), the pipeline is generated with steps: []. The create response returns metadata only — fetch the full YAML with harness_get(resource_type="pipeline", resource_id="<identifier>_pipeline", org_id="<org_id>", project_id="<project_id>") (pass org_id/project_id using the active scope on both calls):

pipeline:
  description: ""                          # optional, user can update later
  identifier: test_new_dr_test_pipeline    # auto: <identifier>_pipeline, does NOT change
  name: test new dr test pipeline          # auto: <name> Pipeline, user can update
  orgIdentifier: default                   # from account context, does NOT change
  projectIdentifier: ChaosDev1             # from account context, does NOT change
  stages:
    - stage:
        description: Optional Description  # optional, user can set at create or update later
        identifier: test_new_dr_test       # auto-derived from name, does NOT change
        name: test new dr test             # user-provided name, user can update
        objective: Optional Objective      # optional, user can set at create or update later
        spec:
          execution:
            steps: []                      # EMPTY — agent must populate with chaos steps
        tags:
          someTag: value                   # optional, user can add at create or update later
        type: DRTest                       # fixed, set at stage creation — do NOT remove
  tags:
    module: drtest                         # fixed, auto-set by MCP — do NOT remove

Note: The example above shows the minimal structure. A real pipeline may contain additional fields (e.g., allowStageExecutions, notificationRules, flowControl, timeout, etc.) — preserve any extra fields present in the fetched YAML as-is. Do not remove or overwrite them.

The stage-level environment block is NOT used by DRTest pipelines. It may appear in fetched YAML but is ignored by the backend:

environment:
  environmentRef: demo
  deployToAll: false
  infrastructureDefinitions:
    - identifier: qaauto1

Do not ask the user to provide stage-level environment or infrastructure — each chaos step has its own infraReference field instead (see references/components.md Step 1). If this block already exists in fetched YAML, preserve it as-is — do not remove it.

The agent's job is to populate steps: [] with chaos steps (ChaosFault, ChaosProbe, ChaosAction, Chaos) using the workflow described in references/components.md. Only these chaos step types are valid inside a DRTest stage.

Naming convention: if user creates a DR Test with name test new dr test (identifier auto-derived as test_new_dr_test):

• Pipeline identifier = test_new_dr_test_pipeline (auto: <identifier>_pipeline)
• Pipeline name = test new dr test pipeline (auto: <name> Pipeline)
• Stage identifier = test_new_dr_test (auto-derived from name)
• Stage name = test new dr test (= the name provided by the user)

Optional stage fields: description, objective, tags, runMode, variables, delegateSelectors, failureStrategies, when, timeout.

Intent Routing