Submit distributed data analysis and ML tasks to the aegis Ray cluster. Use when the user wants to analyze datapacks at scale, filter/score/aggregate parquet data across many injections, run ML training or inference on cluster, or asks about "分析数据", "跑分析", "ray submit", "datapack analysis", "batch analysis", "parquet分析", "筛选数据", "数据分析任务". Also use when the user asks how to connect to Ray, what the Ray cluster looks like, or how to read datapacks programmatically.
How to push a seed / helm-value / chart change from a merged PR into the live byte-cluster so backend RP picks it up. Covers CM apply, worker restart, reseed, helm release teardown, kubectl set image (instead of helm upgrade for backend), drift recovery via direct SQL, and the foot-guns that broke us today (helm --set [0] array replace, YAML float coercion, multi-arch image push, LB EIP churn). Trigger when user merges a `chore(byte-cluster/seed)` / `fix(byte-cluster/seed)` / `chore(byte-cluster): bump rcabench image` PR and asks "apply", "更新", "reseed", "推到集群", "更新流程", "怎么生效", or wants to know why a merged seed change isn't visible in fresh ts/hs/otel-demo namespaces.
Author and run fault-injection rounds against an aegis-deployed benchmark, framed as the adversarial puzzle setter against an RCA agent. Trigger on anything fault-injection-related — "故障注入 / inject fault / 出题给 RCA / 对抗性故障注入 / red team RCA / 持续注入 / 自动选难度高的故障 / pick what to inject next / run an injection round / injection loop / inject campaign". The skill embodies a single mindset (pick faults that maximize RCA inference difficulty — fine granularity × user-visible SLO breach × long causal chain × blast radius) and a state convention (per-system memory under `~/.aegisctl/injection-author/<system>/`) so judgments accumulate across runs. Use the `aegisctl` skill for CLI composition (NDJSON pipes, name-not-id filters); this skill decides *what* to inject and *why*.
How to (re)generate the chaos-point catalog from the NORMAL-phase raw traces of collected datapacks, instead of the legacy clickhouseanalyzer (which has no phase filter and keys endpoints by the caller). Covers collect → mine → render → merge-jvm → replace aegis-chaos/ → PR, and the traps (raw-vs-converted blob path, server-vs-caller attribution, infra/mq name resolution, jvm_mysql format, bridgeless tproxy, cold-service drops). Trigger when the user says "重新生成 / 更新 chaos point", "catalog 里好多无效点 / 不存在的点", "从 trace 生成 chaos point", "refresh / regenerate the chaos catalog", "mine chaos points", "observedgen", or asks why a catalog point targets a route a service doesn't host.
Methodology for making the aegis control plane aware of a newly added microservice benchmark — what layers of the platform (systemconfig registry, etcd dynamic config, DB seed, helm chart config, OTel pipeline) must be told about the new system, and what fails silently if any layer is skipped. Use whenever the user wants to "add a new benchmark", "register a new system", "support X workload in aegis", "做一个新的 benchmark", "加一个新的微服务", or is debugging why a freshly-deployed workload isn't selectable in the guided inject flow, returns 500 on submit, or goes to `0 enabled` after backend restart. Complements `onboard-benchmark-system` (which covers deploying the workload and wiring OTLP); this skill covers the aegis-side registration that most new-benchmark failures trace back to.
Triage frame for end-to-end (E2E) test, smoke test, regression, and fault-injection validation failures. Use when the user reports an E2E/smoke/regression run is broken, a fault-injection flow fails mid-pipeline, a previously-green test is now flaky, or asks to "triage", "debug the E2E", "why is the regression failing", "help me figure out what broke the smoke test". Produces a short hypothesis list and next inspection surfaces rather than a full runbook. Trigger words — e2e, end-to-end, regression, smoke test, fault injection validation, flaky test, test broke.
How to onboard a new microservice benchmark (Online Boutique, TrainTicket, Hotel Reservation, Social Network, otel-demo, etc.) onto the aegis kind cluster so it can be chaos-injected and observed via the OTLP → ClickHouse pipeline. Use this whenever the user asks to "add a new system", "run a demo", "onboard <benchmark>", "inject chaos on X service", or wants to gather fault-injection trace data on any workload that isn't already wired up. Also use when diagnosing why a newly deployed demo isn't emitting traces or why chaos isn't landing.
Methodology for making the aegis control plane aware of a newly added microservice benchmark — what layers of the platform (systemconfig registry, etcd dynamic config, DB seed, helm chart config, OTel pipeline) must be told about the new system, and what fails silently if any layer is skipped. Use whenever the user wants to "add a new benchmark", "register a new system", "support X workload in aegis", "做一个新的 benchmark", "加一个新的微服务", or is debugging why a freshly-deployed workload isn't selectable in the guided inject flow, returns 500 on submit, or goes to `0 enabled` after backend restart. Complements `onboard-benchmark-system` (which covers deploying the workload and wiring OTLP); this skill covers the aegis-side registration that most new-benchmark failures trace back to.