ark-chainsaw-testing
Manage and execute E2E tests for Ark resources using Chainsaw and mock-llm configs.
Install
mkdir -p .claude/skills/ark-chainsaw-testing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4373" && unzip -o skill.zip -d .claude/skills/ark-chainsaw-testing && rm skill.zipInstalls to .claude/skills/ark-chainsaw-testing
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Run and write Ark Chainsaw tests with mock-llm. Use for running tests, debugging failures, or creating new e2e tests.Key capabilities
- →Run Ark Chainsaw e2e tests
- →Validate resource state with JMESPath assertions
- →Debug test failures with pause-on-failure mode
- →Manage mock LLM configurations
How it works
It uses declarative assertions and wait conditions to poll for resource states, avoiding brittle shell scripts and standard Kubernetes wait commands.
Inputs & outputs
When to use ark-chainsaw-testing
- →Run chainsaw tests
- →Write e2e test
- →Debug test failure
About this skill
Ark Chainsaw Testing
Run and write Chainsaw e2e tests for Ark resources.
Running Tests
# Run all standard tests
(cd tests && chainsaw test --selector 'standard')
# Run specific test
chainsaw test ./tests/query-parameter-ref --fail-fast
# Debug mode - keep resources on failure
chainsaw test ./tests/query-parameter-ref --skip-delete --pause-on-failure
Writing Tests
Reference tests/CLAUDE.md for comprehensive patterns.
For a complete working example that shows the correct patterns for writing tests, see examples.md.
Test Structure
tests/my-test/
├── chainsaw-test.yaml # Test definition
├── mock-llm-values.yaml # Mock LLM config (if needed)
├── README.md # Required documentation
└── manifests/
├── a03-model.yaml # Model before Agent
├── a04-agent.yaml # Agent before Query
└── a05-query.yaml # Query last
Antipatterns
kubectl wait for CRD conditions
Never use kubectl wait --for=condition=Established to check CRD readiness. This command crashes with a type error when .status.conditions is nil (a known kubectl bug: kubernetes/kubernetes#66439):
error: .status.conditions accessor error: <nil> is of the type <nil>, expected []interface{}
Use a chainsaw assert with JMESPath instead — it polls gracefully and waits for the field to appear:
# Bad - crashes if .status.conditions is nil
- script:
content: |
kubectl apply -f my-crd.yaml
kubectl wait --for=condition=Established crd/my-crd.example.com --timeout=60s
# Good - polls until condition appears, no nil crash
- script:
content: |
kubectl apply -f my-crd.yaml
- assert:
resource:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: my-crd.example.com
status:
(conditions[?type == 'Established']):
- status: "True"
This pattern converts a brittle timeout into an explicit condition check. The same applies to any resource whose .status.conditions may start as nil.
assert instead of wait for Query completion
Never use assert to wait for a Query to complete. assert polls the API server repeatedly; wait uses a Kubernetes watch (event-driven), which is faster and cheaper:
# Bad - polls every few seconds, hammers the API server
- assert:
resource:
apiVersion: ark.mckinsey.com/v1alpha1
kind: Query
metadata:
name: test-query
status:
phase: done
# Good - uses a watch, fires once the condition is set
- wait:
apiVersion: ark.mckinsey.com/v1alpha1
kind: Query
name: test-query
timeout: 4m
for:
condition:
name: Completed
value: 'True'
Use assert only after wait has confirmed the query is done — i.e., for post-completion validation of response fields. Keep these as separate steps so timing is explicit:
- name: wait-for-query-completion
try:
- wait:
apiVersion: ark.mckinsey.com/v1alpha1
kind: Query
name: test-query
timeout: 4m
for:
condition:
name: Completed
value: 'True'
- name: validate-response
try:
- assert:
resource:
apiVersion: ark.mckinsey.com/v1alpha1
kind: Query
metadata:
name: test-query
status:
(response != null): true
phase: done
Shell scripts for condition checking
Avoid using shell scripts with kubectl get + jq to validate resource state when chainsaw assertions can express the check declaratively. Shell scripts fail immediately on unexpected nil values; assertions retry until the condition is met or the timeout expires.
# Bad - fails immediately if field is absent
- script:
content: |
val=$(kubectl get myresource foo -o jsonpath='{.status.phase}')
[ "$val" = "Ready" ] || exit 1
# Good - retries until condition is true
- assert:
resource:
apiVersion: example.com/v1
kind: MyResource
metadata:
name: foo
status:
phase: Ready
Environment Variables
For real LLM tests (not mock-llm):
export E2E_TEST_AZURE_OPENAI_KEY="your-key"
export E2E_TEST_AZURE_OPENAI_BASE_URL="your-endpoint"
When not to use it
- →When testing non-Ark resources
- →When using kubectl wait for CRD readiness
Prerequisites
Limitations
- →Cannot use kubectl wait for CRD conditions
- →Requires specific test directory structure
How it compares
It uses event-driven watches for faster completion checks and avoids common kubectl nil-pointer crashes.
Compared to similar skills
ark-chainsaw-testing side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| ark-chainsaw-testing (this skill) | 1 | 4mo | Review | Intermediate |
| storage-networking | 6 | 7mo | Review | Advanced |
| kubernetes-architect | 6 | 4mo | No flags | Advanced |
| senior-devops | 7 | 7mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by mckinsey
View all by mckinsey →You might also like
storage-networking
pluginagentmarketplace
Master Kubernetes storage management and networking architecture. Learn persistent storage, network policies, service discovery, and ingress routing.
kubernetes-architect
sickn33
Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration. Masters EKS/AKS/GKE, service mesh (Istio/Linkerd), progressive delivery, multi-tenancy, and platform engineering. Handles security, observability, cost optimization, and developer experience. Use PROACTIVELY for K8s architecture, GitOps implementation, or cloud-native platform design.
senior-devops
davila7
Comprehensive DevOps skill for CI/CD, infrastructure automation, containerization, and cloud platforms (AWS, GCP, Azure). Includes pipeline setup, infrastructure as code, deployment automation, and monitoring. Use when setting up pipelines, deploying applications, managing infrastructure, implementing monitoring, or optimizing deployment processes.
gitops-workflow
sickn33
Implement GitOps workflows with ArgoCD and Flux for automated, declarative Kubernetes deployments with continuous reconciliation. Use when implementing GitOps practices, automating Kubernetes deployments, or setting up declarative infrastructure management.
helm-chart-scaffolding
wshobson
Design, organize, and manage Helm charts for templating and packaging Kubernetes applications with reusable configurations. Use when creating Helm charts, packaging Kubernetes applications, or implementing templated deployments.
devops-iac-engineer
davila7
Implements infrastructure as code using Terraform, Kubernetes, and cloud platforms. Designs scalable architectures, CI/CD pipelines, and observability solutions. Provides security-first DevOps practices and site reliability engineering guidance.