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.