dynacat-dashboard-discovery

name	dynacat-dashboard-discovery
description	Discover requirements for Glance or Dynacat homelab dashboards before architecture or code generation. Use when a user wants to create a dashboard from scratch, rebuild an existing dashboard, choose between Glance and Dynacat, analyze dashboard pain points, or provide Docker, Kubernetes, monitoring, auth, AI, media, or self-hosted service context.

Dynacat Dashboard Discovery

Purpose

Run the human-in-the-loop discovery phase for a Glance or Dynacat dashboard. Classify the project, ask only high-signal questions, identify platform fit, and produce a concise discovery summary that can feed $dynacat-dashboard-planning.

Source References

Use official and project references as source-of-truth. In a repo checkout, load the shared references/source-of-truth.md when exact URLs or scope are needed. If this skill was installed standalone with npx skills, use the official Glance, community-widgets, and Dynacat repositories/docs named in the user prompt or AGENTS.md. Prefer documented Glance and Dynacat patterns over invented configuration structures.

Workflow

Progress:

• Classify project type.
• Confirm target platform or mark undecided.
• Ask blocking questions only.
• Capture assumptions, constraints, non-goals, and risks.
• Produce discovery summary.

1. Determine whether this is a brand-new setup, existing dashboard, migration, or platform-selection request.
2. Ask which platform will actually be deployed: Glance, Dynacat, or undecided.
3. If undecided, compare Glance and Dynacat against the user's requirements.
4. Ask scenario-specific questions based on mentioned services.
5. Request existing configs, screenshots, repository structure, compose files, and widget YAMLs only when they are relevant.
6. Produce a discovery summary with requirements, assumptions, constraints, non-goals, risks, open questions, and recommended next phase.

Defaults

Default to Glance for small, mostly static dashboards unless the user needs dynamic layouts, custom UX composition, or richer modularity.

Default to Dynacat for advanced dynamic layouts, modular UX, and future expansion.

Default to asking for existing config files before screenshots when reviewing an existing dashboard.

Question Control

Keep discovery useful and bounded:

• ask blocking questions first
• group optional questions separately
• avoid asking for information already present in files or configs
• explain why a question matters when it affects platform choice, security, maintainability, or cost
• document assumptions when the user does not know an answer
• do not generate implementation code during discovery

Scenario Triggers

If the user mentions Docker, ask about Portainer, Docker Socket Proxy, cAdvisor, node-exporter, Grafana, Loki, Prometheus, and Uptime Kuma.

If the user mentions Kubernetes, ask about ArgoCD, Lens, Prometheus stack, cert-manager, ingress controllers, cluster metrics, and namespaces.

If the user mentions authentication, ask about Authentik, Authelia, OAuth2 Proxy, Keycloak, LDAP, SSO providers, session expectations, and exposed routes.

If the user mentions AI, ask about Ollama, OpenWebUI, GPU metrics, model monitoring, inference statistics, and active sessions.

If the user mentions media, ask about Plex or Jellyfin plus Sonarr, Radarr, Bazarr, Prowlarr, Overseerr, and Tdarr.

If the user mentions monitoring, ask about Grafana, Prometheus, Loki, Tempo, Alertmanager, Uptime Kuma, Netdata, VictoriaMetrics, alert routing, and retention.

Gotchas

• Do not turn scenario triggers into a full questionnaire. Ask only questions that change platform choice, plan shape, or implementation risk.
• Do not recommend a platform until deployment target, dashboard size, and dynamic-layout needs are clear enough.
• Do not assume Grafana, Prometheus, Loki, or Kubernetes are acceptable dependencies; ask or preserve user constraints.
• Treat screenshots as UX evidence, not as a substitute for config review.

Platform Recommendation

Recommend Glance when the user needs a simple, lightweight, mostly static dashboard with documented widgets and straightforward YAML.

Recommend Dynacat when the user needs more dynamic layouts, modular UX, advanced page composition, richer customization, or stronger future expansion.

If the selected platform does not fit the requirements, explain why and recommend switching before planning.

Discovery Summary Format

Return a compact Markdown summary:

## Discovery Summary

### Project Type
Brand-new | Existing | Migration | Platform selection

### Platform Direction
Glance | Dynacat | Undecided, with recommendation

### Requirements
- ...

### Current Problems
- ...

### Constraints and Non-Goals
- ...

### Assumptions
- ...

### Risks
- ...

### Open Questions
- Blocking:
- Optional:

### Recommended Next Step
Use $dynacat-dashboard-planning after the blocking questions are answered.