Kansodata Grafana Authoring Operations

Gestiona de forma segura la inspección, diagnóstico, propuesta y aplicación controlada de cambios en dashboards y alertas de Grafana usando tooling habilitado.

Security Scan

The skill's instructions align with its stated purpose (read/diagnose/propose/apply Grafana changes) and are conservative about writes, but it assumes platform-provided grafana_* tooling and does not declare how Grafana credentials or tooling are supplied — verify that before installing.

Purpose & Capability

The SKILL.md describes read-only inspection, diagnosis, JSON generation/refactor, and gated apply flows using a set of grafana_* tools (e.g., grafana_get_dashboard, grafana_list_dashboards, grafana_export_dashboard_json). That capability set matches the name/description. However, the skill declares no required env vars, binaries, or install steps — it therefore assumes the host/agent runtime provides those grafana_* tools and any necessary credentials. Confirm how those tools and credentials are provisioned; otherwise there is an information gap.

Instruction Scope

Instructions stay on-topic: they instruct the agent to read Grafana state before proposing changes, avoid inventing resources, degrade to drafts when context is lacking, and require a write tool/gate before applying. The SKILL.md does not instruct the agent to read unrelated files, environment variables, or exfiltrate data to unknown endpoints.

Install Mechanism

No install spec and no code files (instruction-only). This is the lowest-risk pattern: nothing is downloaded or written by the skill itself. Any execution risk depends on the platform-provided grafana_* tooling, not on this skill's package.

Credentials

The skill lists no required environment variables or credentials. Practically, Grafana operations normally require an API URL and token (or similar auth). The absence of declared credentials is acceptable if the platform supplies and controls the grafana_* tools and their secrets, but you should verify where Grafana API credentials live, what scopes they have, and that the agent isn't granted broader secrets than necessary.

Persistence & Privilege

always is false and the skill does not request persistent or elevated platform presence. The SKILL.md explicitly gates write operations and requires tooling/gates to be enabled before applying changes, which limits autonomous destructive capability.

Scan Findings in Context

[no_findings] expected: The package is instruction-only and contains no code files; the regex-based scanner had nothing to analyze. This is expected for a pure SKILL.md.

Assessment

This skill appears coherent for inspecting and proposing Grafana dashboard/alert changes and sensibly restricts write actions, but you should: (1) confirm how the grafana_* tools are provided by your agent/runtime and who controls them; (2) verify where Grafana API credentials live, what scopes they have, and that only minimal read/write scopes are granted; (3) keep write/apply gates disabled until a human review workflow is in place; (4) test in read-only mode first and review any generated JSON/diffs before enabling apply operations. If you cannot confirm how credentials/tooling are provisioned, treat the skill as potentially risky and require additional review.

Skill: kansodata-grafana-authoring-operations

Propósito

Esta skill guía al agente para:

• inspeccionar estado real de Grafana,
• diagnosticar dashboards y alerting,
• generar/refactorizar JSON de dashboard,
• proponer cambios seguros,
• aplicar cambios solo cuando la herramienta write exista y esté habilitada.

Modos operativos

1. inspect_grafana

• Objetivo: estado base de salud, dashboards, datasources, folders y alert rules.
• Herramientas: grafana_health_check, grafana_list_dashboards, grafana_list_datasources, grafana_list_alert_rules, grafana_list_folders.

2. diagnose_dashboard

• Objetivo: analizar dashboard por UID y detectar señales de rotura o deuda técnica.
• Herramientas: grafana_get_dashboard, grafana_export_dashboard_json.

3. generate_dashboard_json

• Objetivo: producir propuesta JSON para nuevo dashboard (sin aplicar en v1).
• Regla: marcar salida como draft o review_ready según contexto disponible.

4. refactor_dashboard_json

• Objetivo: proponer refactor lógico de dashboard existente.
• Regla: usar estado actual leído desde Grafana antes de proponer.

5. propose_alert_rule

• Objetivo: proponer reglas de alerta con justificación y riesgo.
• Regla: no afirmar aplicabilidad sin verificar datasource/queries/contexto.

6. apply_dashboard_change

• Objetivo: aplicar cambios en dashboard.
• Estado v1: restringido; requiere herramienta write habilitada y gate activo.

7. apply_alerting_change

• Objetivo: aplicar cambios de alerting.
• Estado v1: restringido; requiere herramienta write habilitada y gate activo.

Niveles de confianza del contexto

• grafana_state_confirmed: datos actuales obtenidos por tools read-only.
• grafana_state_partial: parte del estado verificado, parte inferido.
• grafana_state_assumed: no hay evidencia reciente del entorno.

Estados de madurez de salida

• draft: propuesta preliminar; contexto insuficiente o ambiguo.
• review_ready: propuesta consistente para revisión humana.
• apply_ready: aplicable técnicamente con tooling/gates habilitados.
• human_review_required: cambio sensible o riesgo no mitigado.

Reglas de comportamiento obligatorias

• Leer estado actual antes de proponer cambios.
• No inventar dashboards, folders, datasources ni alert rules.
• No borrar recursos en v1.
• No afirmar compatibilidad/viabilidad sin verificación real.
• Proponer cambios como diff lógico cuando aplique.
• Pedir operación write solo si existe tool habilitada y contexto suficiente.
• Si falta contexto real, degradar salida a draft.

Degradación segura

• Si falla una tool de lectura: reportar bloqueo y continuar con lo verificable.
• Si el estado es parcial: marcar explícitamente incertidumbre.
• Si se requiere write y no hay gate o tool habilitada: detener y emitir human_review_required.

Casos de uso

1. Listar dashboards disponibles.
2. Revisar dashboard por UID.
3. Exportar JSON para respaldo o versionado lógico.
4. Detectar dashboard roto (queries/panels inválidos observables en JSON).
5. Revisar alert rules existentes.
6. Proponer nueva alerta con justificación.
7. Preparar clon de dashboard como propuesta (sin aplicar en v1).