agent-plugins

Use when a task involves Tsuga CLI commands, TQL log or trace search, aggregation bodies, metric temporality math, resource lookup or CRUD planning, service ownership, reliability posture, quality reports, monitor or dashboard context, notification rules, retention/tag policies, ingestion keys, docs lookup, command help, skeleton payloads, or Tsuga app deep links.

Use when asked to create, update, validate, delete, or review a Tsuga dashboard; add or fix widgets; correct layout; build a monitoring view for a service, team, system, SLO, capacity, latency, throughput, or error-rate question; verify dashboard payloads, widget queries, graph schemas, normalizers, formulas, table grouping, time presets, or layout rules.

One-shot procedure for turning a live Tsuga account + codebase list + ambient docs into the `skills/knowledge-company/` tree: top-level COMPANY_GENERAL_KNOWLEDGE.md + COMPANY_TELEMETRY_KNOWLEDGE.md, per-team TEAM_KNOWLEDGE.md, per-service SERVICE_KNOWLEDGE.md dossiers with ready-to-run `tsuga` CLI queries. Trigger this skill when bootstrapping knowledge-company from scratch for a new customer / company, refreshing it after a major service taxonomy change, or after a CLI rename that invalidates the existing ready-to-run commands. Inputs: Tsuga MCP / CLI access, list of GitHub codebases, optional `inputs/raw-docs/` for architecture notes. Outputs: populated `skills/knowledge-company/` ready for the runtime agent to load.

Primary entry point for active-incident investigation, post-incident RCA, or recurring-degradation triage. Use when a monitor fires, a customer reports slow / errored / missing telemetry, an incident is declared (P1–P5), or someone asks 'what's wrong with X right now?'. Coordinates parallel evidence branches — telemetry sweep (`tsuga` CLI), change correlation (git / gh), analogue search, codebase-grep, challenger review — tracking hypotheses behind evidence gates, and produces an operator-ready verdict with cited evidence plus two durable deliverables by default: a Tsuga investigation record and a proofs dashboard.

Use when choosing an OpenTelemetry signal, instrument, or telemetry name: metric vs span vs log, counter vs histogram vs gauge, span event vs child span, resource/span/log/metric attribute naming, semantic convention checks, deployment.environment migration, bounded dimensions, cardinality estimates, high-cardinality risk, or whether an observation belongs in traces, metrics, logs, or resource attributes.

One-shot procedure for turning a raw incident dump (Slack threads, incident reports, GitHub PRs, Tsuga CLI output) into a populated `skills/incident-history/references/incidents/` archive with one folder per incident, each containing a SUMMARY.md with a validated `## Diagnostic path` section. Trigger this skill when bootstrapping `incident-history` from scratch for a new deployment, refreshing an existing archive with new incidents, or reformatting an incident tracker's export into the shape your investigation runtime expects. Inputs: `inputs/incidents/<INC-id>/` directories holding raw material per incident. Outputs: `skills/incident-history/references/incidents/<INC-id>/SUMMARY.md` + `_inventory.csv`.

Use when linting Tsuga skill bundles after editing runtime skills, generated incident-history or knowledge-company archives, or skill references; use when checking frontmatter, SKILL.md length, forbidden Tsuga CLI patterns, cross-links, required sections, generated dossier structure, sampled read-only command shape, local reference validation, release readiness, or whether a skill tree is ready for review.

Use when asked about slow requests, high latency, latency spikes, p95 or p99 trace duration, slow spans, top slow operations, peak latency windows, sustained vs transient latency degradation, trace-log correlation, span count by operation, downstream latency suspicion, which operations are slow for a specific service, or whether latency correlates with errors.

Use when asked to check monitor coverage, services without monitors, alerting gaps, notification routing, notification-rules, silences, stale team references, PagerDuty or Slack routing destinations, teams without configured alerts, monitor ownership, monitor filters, log-error-pattern coverage, active/inactive routing rules, coverage summaries, routing gaps, coverage percentages, or whether alert configuration covers a service/team scope.

Use when asked about service errors, error spikes, exception patterns, what is failing, new error patterns, anomalous error volume, dominant log error structures, service-specific error counts, error samples, error pattern increases, failed requests, exception clusters, error windows, affected files, targets, or whether log evidence is consistent with an error hypothesis.

Use when investigating active incidents, on-call response, first-response triage, service health checks, degraded service reports, latency spikes, error spikes, unhealthy service symptoms, monitor context, current signal status, multi-signal service triage, service ownership, service counters, service env scope, error counters, or what is wrong with a specific service right now, urgently.

Use when auditing telemetry quality for logs, metrics, traces, or resource identity: log structure/correlation, metric naming/units/temporality/instrument type/cardinality, span naming/status/kind/links/noisy spans, semantic naming/cardinality, telemetry quality reviews, quality reports, downstream metric usage, noisy signals, missing labels, malformed attributes, resource drift, source labels, broken correlation, or recommendations to rename metrics or right-size high-cardinality attributes.

Use when telemetry is missing, sparse, delayed, or not visible in Tsuga: verify arrival after deploy, service not visible, missing logs/traces/metrics, OTLP endpoint/protocol/auth/export failures, redacted config state, Collector accepts data but Tsuga does not show it, broken trace propagation, orphan spans, multiple trace IDs, HTTP/gRPC propagation, or messaging propagation issues.

Use when Collector YAML, Helm values, Kubernetes manifests, existing Collectors, OTLP exporters, receiver binding, receiver exposure, pipeline topology, processors, OTTL expressions, transform/filter/routing processors, redaction, enrichment, batching, memory limiting, structured log parsing, Collector-to-Tsuga export issues, configuration review, rollout planning, or missing telemetry after Collector rollout need to be written, reviewed, or debugged.

Use when adding, fixing, generating, or auditing OpenTelemetry app SDK setup in C++, .NET, Go, Java/JVM, Node.js/TypeScript, PHP, Python, Ruby, Rust, or an unknown runtime; also use for automatic instrumentation, custom spans, metrics, logs, log correlation, resource attributes, propagation, messaging, local testing, sensitive data/redaction, instrumentation audits, or SDK code snippets.

Per-technology reference bundles with exact Tsuga metric names, incident shapes, derived signals, and log patterns for ~35 techs (postgres, mysql, redis, kafka, rabbitmq, cassandra, kubernetes, nginx, haproxy, envoy, istio, jvm, otel-collector, quickwit, aws-rds, aws-lambda, aws-ecs, aws-sqs, aws-dynamodb, aws-elasticache, gcp-pubsub, gcp-storage, …). Trigger before composing any `tsuga aggregation / tsuga logs / tsuga traces` query, or when an incident scope / error log / monitor name mentions a covered tech or a classic symptom (OOMKilled, CrashLoopBackOff, connection pool, deadlock, queue lag, compaction, throttle, replication lag, cold start, 5xx). Source-system metric names (CloudWatch CPUUtilization, etc.) do NOT work in Tsuga — use the `tsuga_metric_name` column in each tech's `metrics.csv` (AWS metrics register as `aws_rds_cpu_utilization`, `aws_lambda_errors`, …).

GitHub CLI for inspecting workflow runs, PRs, commits, releases, and deployments. Use to correlate an incident window with what changed, verify whether a merged PR actually deployed, inspect a specific commit, list recent releases, or check workflow run status. Read-only by default.